Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 19 Feb 2021 12:24, Jean-Philippe Brucker wrote: > On Thu, Feb 18, 2021 at 04:39:43PM -0700, Al Stone wrote: > > As of today, the proposal has been approved for inclusion in the next > > release of the ACPI spec (whatever version gets released post the 6.4 > > version that just came out). > > > > Congratulations ?!? :) > > > > And thanks to all for their patience during this process. You now > > have the dubious disctinction of being the very first table added > > to the spec that _started_ as open source. > > That is great news! Thanks again for your help with this :) > > Just to confirm, we don't need to wait for the release of the 6.5 version > of the spec before upstreaming support for the table? Correct. This is why the UEFI community-first process exists -- so the work can be done in the open instead of having to wait for the next spec release. > Another question that might come up at some point, is how to add new > subtables. Is the process documented somewhere? We would do essentially the same thing: there would be a discussion on a list somewhere, a conclusion would be drawn, and an ECR put together to send to the ASWG group (any UEFI member can do that, like Yinghan, for example). All discussion of changes would occur in the open -- ASWG is really just monitoring progress in these cases. Once it is clear that the proposed change is stable and essentially finalized by the community, there would be a final vote in the ASWG on whether to include it or not. > For the moment I sent a -poorly numbered- pull request for acpica: > https://github.com/acpica/acpica/pull/666 That's hilarious :-D. I'm sure it will be just fine :-) I'll put a tag on that PR to track it. > Thanks, > Jean > -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On Thu, Feb 18, 2021 at 04:39:43PM -0700, Al Stone wrote: > As of today, the proposal has been approved for inclusion in the next > release of the ACPI spec (whatever version gets released post the 6.4 > version that just came out). > > Congratulations ?!? :) > > And thanks to all for their patience during this process. You now > have the dubious disctinction of being the very first table added > to the spec that _started_ as open source. That is great news! Thanks again for your help with this :) Just to confirm, we don't need to wait for the release of the 6.5 version of the spec before upstreaming support for the table? Another question that might come up at some point, is how to add new subtables. Is the process documented somewhere? For the moment I sent a -poorly numbered- pull request for acpica: https://github.com/acpica/acpica/pull/666 Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 17 Feb 2021 10:37, Jean-Philippe Brucker wrote: > On Tue, Feb 16, 2021 at 02:31:03PM -0700, Al Stone wrote: > > Would you believe last week's meeting was canceled, too? Not sure > > why the chair/co-chair are doing this but I'm finding it a little > > frustrating. > > > > We'll try again this week ... again, apologies for the delays. I'd > > recommend going with the last version posted just so progress can be > > made. The spec can always be fixed later. > > Thanks, I'll send the acpica changes for review and follow with QEMU and > Linux patches. These things also take time so I might as well start in > parallel. > > Thanks, > Jean As of today, the proposal has been approved for inclusion in the next release of the ACPI spec (whatever version gets released post the 6.4 version that just came out). Congratulations ?!? :) And thanks to all for their patience during this process. You now have the dubious disctinction of being the very first table added to the spec that _started_ as open source. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On Tue, Feb 16, 2021 at 02:31:03PM -0700, Al Stone wrote: > Would you believe last week's meeting was canceled, too? Not sure > why the chair/co-chair are doing this but I'm finding it a little > frustrating. > > We'll try again this week ... again, apologies for the delays. I'd > recommend going with the last version posted just so progress can be > made. The spec can always be fixed later. Thanks, I'll send the acpica changes for review and follow with QEMU and Linux patches. These things also take time so I might as well start in parallel. Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 04 Feb 2021 13:25, Al Stone wrote: > On 03 Feb 2021 09:46, Jean-Philippe Brucker wrote: > > On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > > > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > > > Hi Al, > > > > > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > > > I updated the doc: > > > > > > https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > > > You can incorporate it into the ASWG proposal. > > > > > > Changes since v8: > > > > > > * One typo (s/programing/programming/) > > > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > > > > > Thanks again for helping with this > > > > > > > > > > > > Jean > > > > > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > > > > > Has there been any more feedback on the VIOT specification? I'm > > > > wondering > > > > when we can start upstreaming support for it. > > > > > > > > Thanks, > > > > Jean > > > > > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > > > > > The latest version that resulted from the discussion with Yinghan of > > > Microsoft is the one in front the ASWG; I think if you upstream that > > > version, it should be identical to the spec when it is next published > > > (post ACPI 6.4). > > > > > > The process is: (1) propose the change, (2) review it in committee, > > > (3) give people more time to think about it, then (4) have a finale > > > vote. We've been iterating over (1), (2) and (3). Since there was > > > no new discussion at the last meeting, we should have the final vote > > > on this (4) in the next meeting. I had hoped we could do that last > > > week but the meeting was canceled at the last minute. I hope to have > > > the final vote this Thursday and will let you know as soon as it has > > > been decided. > > > > > > My apologies for the delays; getting things done by committee always > > > takes a bazillion times longer than one would think. > > > > No worries, thanks a lot for the update! > > > > Thanks, > > Jean > > Sigh. Just got a note that today's meeting has been canceled :(. > > So, next week for the final vote. OTOH, there have been no comments > of any sort on the proposal -- and silence is good, in this case. Would you believe last week's meeting was canceled, too? Not sure why the chair/co-chair are doing this but I'm finding it a little frustrating. We'll try again this week ... again, apologies for the delays. I'd recommend going with the last version posted just so progress can be made. The spec can always be fixed later. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 03 Feb 2021 09:46, Jean-Philippe Brucker wrote: > On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > > Hi Al, > > > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > > You can incorporate it into the ASWG proposal. > > > > > Changes since v8: > > > > > * One typo (s/programing/programming/) > > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > > > Thanks again for helping with this > > > > > > > > > > Jean > > > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > > > Has there been any more feedback on the VIOT specification? I'm wondering > > > when we can start upstreaming support for it. > > > > > > Thanks, > > > Jean > > > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > > > The latest version that resulted from the discussion with Yinghan of > > Microsoft is the one in front the ASWG; I think if you upstream that > > version, it should be identical to the spec when it is next published > > (post ACPI 6.4). > > > > The process is: (1) propose the change, (2) review it in committee, > > (3) give people more time to think about it, then (4) have a finale > > vote. We've been iterating over (1), (2) and (3). Since there was > > no new discussion at the last meeting, we should have the final vote > > on this (4) in the next meeting. I had hoped we could do that last > > week but the meeting was canceled at the last minute. I hope to have > > the final vote this Thursday and will let you know as soon as it has > > been decided. > > > > My apologies for the delays; getting things done by committee always > > takes a bazillion times longer than one would think. > > No worries, thanks a lot for the update! > > Thanks, > Jean Sigh. Just got a note that today's meeting has been canceled :(. So, next week for the final vote. OTOH, there have been no comments of any sort on the proposal -- and silence is good, in this case. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > Hi Al, > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > You can incorporate it into the ASWG proposal. > > > > Changes since v8: > > > > * One typo (s/programing/programming/) > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > Thanks again for helping with this > > > > > > > > Jean > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > Has there been any more feedback on the VIOT specification? I'm wondering > > when we can start upstreaming support for it. > > > > Thanks, > > Jean > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > The latest version that resulted from the discussion with Yinghan of > Microsoft is the one in front the ASWG; I think if you upstream that > version, it should be identical to the spec when it is next published > (post ACPI 6.4). > > The process is: (1) propose the change, (2) review it in committee, > (3) give people more time to think about it, then (4) have a finale > vote. We've been iterating over (1), (2) and (3). Since there was > no new discussion at the last meeting, we should have the final vote > on this (4) in the next meeting. I had hoped we could do that last > week but the meeting was canceled at the last minute. I hope to have > the final vote this Thursday and will let you know as soon as it has > been decided. > > My apologies for the delays; getting things done by committee always > takes a bazillion times longer than one would think. No worries, thanks a lot for the update! Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > Hi Al, > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > You can incorporate it into the ASWG proposal. > > > Changes since v8: > > > * One typo (s/programing/programming/) > > > * Modified the PCI Range node to include a segment range. > > > > > > I also updated the Linux and QEMU implementations on branch > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > https://jpbrucker.net/git/qemu/ > > > > > > Thanks again for helping with this > > > > > > Jean > > > > Perfect. Thanks. I'll update the ASWG info right away. > > Has there been any more feedback on the VIOT specification? I'm wondering > when we can start upstreaming support for it. > > Thanks, > Jean Ah, sorry, Jean. I meant to get back to you sooner. My apologies. The latest version that resulted from the discussion with Yinghan of Microsoft is the one in front the ASWG; I think if you upstream that version, it should be identical to the spec when it is next published (post ACPI 6.4). The process is: (1) propose the change, (2) review it in committee, (3) give people more time to think about it, then (4) have a finale vote. We've been iterating over (1), (2) and (3). Since there was no new discussion at the last meeting, we should have the final vote on this (4) in the next meeting. I had hoped we could do that last week but the meeting was canceled at the last minute. I hope to have the final vote this Thursday and will let you know as soon as it has been decided. My apologies for the delays; getting things done by committee always takes a bazillion times longer than one would think. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
Hi Al, On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > You can incorporate it into the ASWG proposal. > > Changes since v8: > > * One typo (s/programing/programming/) > > * Modified the PCI Range node to include a segment range. > > > > I also updated the Linux and QEMU implementations on branch > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > https://jpbrucker.net/git/qemu/ > > > > Thanks again for helping with this > > > > Jean > > Perfect. Thanks. I'll update the ASWG info right away. Has there been any more feedback on the VIOT specification? I'm wondering when we can start upstreaming support for it. Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [EXTERNAL] Re: Question regarding VIOT proposal
Thank you Jean. Yinghan -Original Message- From: Jean-Philippe Brucker Sent: Friday, December 4, 2020 10:09 AM To: Al Stone Cc: Yinghan Yang ; iommu@lists.linux-foundation.org; Alexander Grest ; eric.au...@redhat.com; j...@8bytes.org; kevin.t...@intel.com; lorenzo.pieral...@arm.com; m...@redhat.com; Boeuf, Sebastien Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal Hi, On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote: > On 03 Dec 2020 22:21, Yinghan Yang wrote: > > Hi Jean, > > > > I'm sorry for the delayed response. I think the new "PCI range node" > > description makes sense. Could you please make this change in the proposal? > > > > Other than that, the proposal looks good to go. Thanks for the feedback, I made the change > > > > Thanks, > > Yinghan > > Jean, were you going to update your existing doc first? If you do > that, then I can cut and paste the changes into the existing ASWG > proposal. Or do you need to send out an RFC to the mailing list first > and finalize it there? I updated the doc: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fvirtio-iommu%2Fviot%2Fviot-v9.pdf&data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uB0xVHvFdF1wkb2D4KJFW8JMGNtiT3tAsoNVU%2FdLlLA%3D&reserved=0 You can incorporate it into the ASWG proposal. Changes since v8: * One typo (s/programing/programming/) * Modified the PCI Range node to include a segment range. I also updated the Linux and QEMU implementations on branch virtio-iommu/devel in https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fgit%2Flinux%2F&data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8OS6A%2Bw1r77hiWIhUWGiUU1rZTXh0Qmx%2Fu7LzIIOalo%3D&reserved=0 and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fgit%2Fqemu%2F&data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qAX7dTxzkA%2FcqUg2urWipPv%2BCdu5yxuWGt3ndBYlQKU%3D&reserved=0 Thanks again for helping with this Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 04 Dec 2020 19:09, Jean-Philippe Brucker wrote: > Hi, > > On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote: > > On 03 Dec 2020 22:21, Yinghan Yang wrote: > > > Hi Jean, > > > > > > I'm sorry for the delayed response. I think the new "PCI range node" > > > description makes sense. Could you please make this change in the > > > proposal? > > > > > > Other than that, the proposal looks good to go. > > Thanks for the feedback, I made the change > > > > > > > Thanks, > > > Yinghan > > > > Jean, were you going to update your existing doc first? If you > > do that, then I can cut and paste the changes into the existing > > ASWG proposal. Or do you need to send out an RFC to the mailing > > list first and finalize it there? > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > You can incorporate it into the ASWG proposal. > Changes since v8: > * One typo (s/programing/programming/) > * Modified the PCI Range node to include a segment range. > > I also updated the Linux and QEMU implementations on branch > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > https://jpbrucker.net/git/qemu/ > > Thanks again for helping with this > > Jean Perfect. Thanks. I'll update the ASWG info right away. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
Hi, On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote: > On 03 Dec 2020 22:21, Yinghan Yang wrote: > > Hi Jean, > > > > I'm sorry for the delayed response. I think the new "PCI range node" > > description makes sense. Could you please make this change in the proposal? > > > > Other than that, the proposal looks good to go. Thanks for the feedback, I made the change > > > > Thanks, > > Yinghan > > Jean, were you going to update your existing doc first? If you > do that, then I can cut and paste the changes into the existing > ASWG proposal. Or do you need to send out an RFC to the mailing > list first and finalize it there? I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf You can incorporate it into the ASWG proposal. Changes since v8: * One typo (s/programing/programming/) * Modified the PCI Range node to include a segment range. I also updated the Linux and QEMU implementations on branch virtio-iommu/devel in https://jpbrucker.net/git/linux/ and https://jpbrucker.net/git/qemu/ Thanks again for helping with this Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On 03 Dec 2020 22:21, Yinghan Yang wrote: > Hi Jean, > > I'm sorry for the delayed response. I think the new "PCI range node" > description makes sense. Could you please make this change in the proposal? > > Other than that, the proposal looks good to go. > > Thanks, > Yinghan Jean, were you going to update your existing doc first? If you do that, then I can cut and paste the changes into the existing ASWG proposal. Or do you need to send out an RFC to the mailing list first and finalize it there? Thanks for all the help. > -Original Message- > From: Jean-Philippe Brucker > Sent: Friday, November 6, 2020 5:58 AM > To: Yinghan Yang > Cc: iommu@lists.linux-foundation.org; Alexander Grest > ; eric.au...@redhat.com; j...@8bytes.org; > kevin.t...@intel.com; lorenzo.pieral...@arm.com; m...@redhat.com; Boeuf, > Sebastien ; a...@redhat.com > Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal > > Hi Yinghan, > > On Thu, Nov 05, 2020 at 10:05:28PM +, Yinghan Yang wrote: > > Thank you for the clarifications. In cases where a large range of PCI > > segments may be assigned to guest, would it make sense to describe this > > configuration as base + count. Currently, one would have to describe them > > individually. > > Yes, I've been wondering whether that would be useful. It would also allow > hotplugging new segments, if that's ever needed. It requires changing the > enumeration rule that derives an endpoint ID from segment + BDF number. > > First, when describing a range of segments, are BFD start and end still > valid? Do they only apply to first and last segment respectively? To keep > things simple I think BDF start/end should keep the same meaning: > valid regardless of segment range, and apply to all segments in the range. > > So the new PCI Range node could be: > > Field Length Offset Description > --- > Type1 0 1 – PCI range > Reserved1 1 0. > Length 2 2 Length of the node in bytes. > Endpoint start 4 4 First endpoint ID. > PCI Segment start 2 8 First PCI Segment number in the range. > PCI Segment end 2 10 Last PCI Segment number in the range. > PCI BDF start 2 12 First Bus-Device-Function number in > the range. > PCI BDF end 2 14 Last Bus-Device-Function number in > the range. > Output node 2 16 Offset from the start of the table to > the next translation element. > Reserved6 18 0. > > A PCI device is affected by the node if its segment is in [Segment start, > Segment end], and if its BDF is in [BPF start, BDF end]. Its endpoint ID will > be: > > ((Segment - Segment start) << 16) + BDF - BDF start + Endpoint start > > Does that sound OK? > > Thanks, > Jean > -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [EXTERNAL] Re: Question regarding VIOT proposal
Hi Jean, I'm sorry for the delayed response. I think the new "PCI range node" description makes sense. Could you please make this change in the proposal? Other than that, the proposal looks good to go. Thanks, Yinghan -Original Message- From: Jean-Philippe Brucker Sent: Friday, November 6, 2020 5:58 AM To: Yinghan Yang Cc: iommu@lists.linux-foundation.org; Alexander Grest ; eric.au...@redhat.com; j...@8bytes.org; kevin.t...@intel.com; lorenzo.pieral...@arm.com; m...@redhat.com; Boeuf, Sebastien ; a...@redhat.com Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal Hi Yinghan, On Thu, Nov 05, 2020 at 10:05:28PM +, Yinghan Yang wrote: > Thank you for the clarifications. In cases where a large range of PCI > segments may be assigned to guest, would it make sense to describe this > configuration as base + count. Currently, one would have to describe them > individually. Yes, I've been wondering whether that would be useful. It would also allow hotplugging new segments, if that's ever needed. It requires changing the enumeration rule that derives an endpoint ID from segment + BDF number. First, when describing a range of segments, are BFD start and end still valid? Do they only apply to first and last segment respectively? To keep things simple I think BDF start/end should keep the same meaning: valid regardless of segment range, and apply to all segments in the range. So the new PCI Range node could be: Field Length Offset Description --- Type1 0 1 – PCI range Reserved1 1 0. Length 2 2 Length of the node in bytes. Endpoint start 4 4 First endpoint ID. PCI Segment start 2 8 First PCI Segment number in the range. PCI Segment end 2 10 Last PCI Segment number in the range. PCI BDF start 2 12 First Bus-Device-Function number in the range. PCI BDF end 2 14 Last Bus-Device-Function number in the range. Output node 2 16 Offset from the start of the table to the next translation element. Reserved6 18 0. A PCI device is affected by the node if its segment is in [Segment start, Segment end], and if its BDF is in [BPF start, BDF end]. Its endpoint ID will be: ((Segment - Segment start) << 16) + BDF - BDF start + Endpoint start Does that sound OK? Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
Hi Yinghan, On Thu, Nov 05, 2020 at 10:05:28PM +, Yinghan Yang wrote: > Thank you for the clarifications. In cases where a large range of PCI > segments may be assigned to guest, would it make sense to describe this > configuration as base + count. Currently, one would have to describe them > individually. Yes, I've been wondering whether that would be useful. It would also allow hotplugging new segments, if that's ever needed. It requires changing the enumeration rule that derives an endpoint ID from segment + BDF number. First, when describing a range of segments, are BFD start and end still valid? Do they only apply to first and last segment respectively? To keep things simple I think BDF start/end should keep the same meaning: valid regardless of segment range, and apply to all segments in the range. So the new PCI Range node could be: Field Length Offset Description --- Type1 0 1 – PCI range Reserved1 1 0. Length 2 2 Length of the node in bytes. Endpoint start 4 4 First endpoint ID. PCI Segment start 2 8 First PCI Segment number in the range. PCI Segment end 2 10 Last PCI Segment number in the range. PCI BDF start 2 12 First Bus-Device-Function number in the range. PCI BDF end 2 14 Last Bus-Device-Function number in the range. Output node 2 16 Offset from the start of the table to the next translation element. Reserved6 18 0. A PCI device is affected by the node if its segment is in [Segment start, Segment end], and if its BDF is in [BPF start, BDF end]. Its endpoint ID will be: ((Segment - Segment start) << 16) + BDF - BDF start + Endpoint start Does that sound OK? Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [EXTERNAL] Re: Question regarding VIOT proposal
Hi Jean, Thank you for the clarifications. In cases where a large range of PCI segments may be assigned to guest, would it make sense to describe this configuration as base + count. Currently, one would have to describe them individually. Yinghan -Original Message- From: Jean-Philippe Brucker Sent: Thursday, November 5, 2020 5:45 AM To: Yinghan Yang Cc: iommu@lists.linux-foundation.org; Alexander Grest ; eric.au...@redhat.com; jean-phili...@linaro.org; j...@8bytes.org; kevin.t...@intel.com; lorenzo.pieral...@arm.com; m...@redhat.com; Boeuf, Sebastien ; a...@redhat.com Subject: [EXTERNAL] Re: Question regarding VIOT proposal Hi, On Thu, Nov 05, 2020 at 12:13:53AM +, Yinghan Yang via iommu wrote: > Hi iommu developers, > > > > I have a question regarding the recent VIOT submission for supporting > paravirtualized IOMMU in guests. The spec defines PCI Range Node > Structure > (5.2.30.3) that maps to a single PCI segment. (To provide some context for other readers, a description of the node is available at https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fvirtio-iommu%2Fviot%2Fviot-v8.pdf&data=04%7C01%7CYinghan.Yang%40microsoft.com%7Cc52e42b3eb63495ed28708d881910b6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401807671941922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YiZLS6kKMqe58vPsJFYIfA3nVICc3G44E6bziD3cC94%3D&reserved=0) > > > > Is it possible for the new table to express that an IOMMU covers all > PCI segments? This could help support scenarios where: > > > > 1. Devices are dynamically assigned to guests during runtime 2. > Devices in the same guests are assigned to different segments. This is possible with the current descriptor, assuming the PCI segments are static. The platform can provide a PCI Range Node for each segment, with a BDF range 0 - 0x. For example a table could describe: * PCI Range Node * PCI Segment: 0 * BDF start: 0 * BDF end: 0x * Endpoint start: 0 * Output node: &viommu * PCI Range Node * PCI Segment: 1 * BDF start: 0 * BDF end: 0x * Endpoint start: 0x1 * Output node: &viommu * viommu Node Then the IOMMU covers all PCI devices on the two segments. To identify a device when configuring DMA translation, the IOMMU driver builds a 32-bit endpoint ID = Endpoint start + BDF. Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu