From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?
Date: Thu, 10 Jun 2021 12:25:22 +0000 [thread overview]
Message-ID: <1bfb4b75-c70a-ea79-1cc7-f5543077c52e@epam.com> (raw)
In-Reply-To: <6b6142fa-3dc7-cd54-a40c-d4b9ef47afad@suse.com>
On 10.06.21 15:02, Jan Beulich wrote:
> On 10.06.2021 13:45, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 10.06.21 13:48, Jan Beulich wrote:
>>> On 10.06.2021 12:01, Oleksandr Andrushchenko wrote:
>>>> On 10.06.21 10:54, Roger Pau Monné wrote:
>>>>> OTOH if we properly trap accesses to the SR-IOV capability (like it
>>>>> was proposed in [1] from your references) we won't have to modify OSes
>>>>> that want to run as hardware domains in order to handle SR-IOV devices.
>>>> Out of curiosity, could you please name a few? I do understand that
>>>>
>>>> we do want to support unmodified OSes and this is indeed important.
>>>>
>>>> But, still what are the other OSes which do support Xen + PCI passthrough?
>>> I think Roger saying "want" meant to cover ones which currently don't,
>>> and which would have to undergo more extensive changes if they were to
>>> be enabled.
>> Fair enough. Do you think we would also need to re-work the existing code
>>
>> in Xen to support normal devices (not SR-IOV), e.g. we currently rely on
>>
>> PHYSDEVOP_XXX and other Linux specifics.
> Yes, work in that area would also be needed. For example we'd need to
> scan buses / segments as they become accessible. Right now we only scan
> segment 0, and even that's only possible because on x86 mmconfig is not
> the only way to access config space.
>
>> And even if SR-IOV is implemented
>>
>> in Xen this won't allow those OSes to stay unmodified, including FreeBSD.
> Of course, it's the nature of PVH (as opposed to HVM) that OSes need
> modification. The question is the scope thereof.
Ok, then it seems I need to get [1] back into the picture.
I have modified vPCI code a lot for ARM support, so [1] will not apply
as is anymore and needs to be re-worked. But, still it can mostly be re-used
> Jan
>
Thank you,
Oleksandr
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01494.html
next prev parent reply other threads:[~2021-06-10 12:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 6:37 SR-IOV: do we need to virtualize in Xen or rely on Dom0? Oleksandr Andrushchenko
2021-06-10 7:54 ` Roger Pau Monné
2021-06-10 10:01 ` Oleksandr Andrushchenko
2021-06-10 10:48 ` Jan Beulich
2021-06-10 11:45 ` Oleksandr Andrushchenko
2021-06-10 12:02 ` Jan Beulich
2021-06-10 12:25 ` Oleksandr Andrushchenko [this message]
2021-06-10 14:10 ` Roger Pau Monné
2021-06-10 15:33 ` Oleksandr Andrushchenko
2021-06-11 6:45 ` Jan Beulich
2021-06-11 6:53 ` Oleksandr Andrushchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1bfb4b75-c70a-ea79-1cc7-f5543077c52e@epam.com \
--to=oleksandr_andrushchenko@epam.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.