From: Jason Wang <jasowang@redhat.com> To: Parav Pandit <parav@nvidia.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, "virtio-dev@lists.oasis-open.org" <virtio-dev@lists.oasis-open.org>, "cohuck@redhat.com" <cohuck@redhat.com>, "virtio-comment@lists.oasis-open.org" <virtio-comment@lists.oasis-open.org>, Shahaf Shuler <shahafs@nvidia.com>, Satananda Burla <sburla@marvell.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Yan Vugenfirer <yan@daynix.com> Subject: [virtio-dev] Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers Date: Thu, 13 Apr 2023 09:48:15 +0800 [thread overview] Message-ID: <CACGkMEuNOYOxvcSzrs0UFEyk+xOkGUpOfhK8rOy_Mebz5b5wdg@mail.gmail.com> (raw) In-Reply-To: <PH0PR12MB5481F0CF5A555A6BB2CE856CDC9B9@PH0PR12MB5481.namprd12.prod.outlook.com> On Wed, Apr 12, 2023 at 10:23 PM Parav Pandit <parav@nvidia.com> wrote: > > > > > From: Jason Wang <jasowang@redhat.com> > > Sent: Wednesday, April 12, 2023 2:15 AM > > > > On Wed, Apr 12, 2023 at 1:55 PM Parav Pandit <parav@nvidia.com> wrote: > > > > > > > > > > > > > From: Jason Wang <jasowang@redhat.com> > > > > Sent: Wednesday, April 12, 2023 1:38 AM > > > > > > > > Modern device says FEAETURE_1 must be offered and must be > > > > > negotiated by > > > > driver. > > > > > Legacy has Mac as RW area. (hypervisor can do it). > > > > > Reset flow is difference between the legacy and modern. > > > > > > > > Just to make sure we're at the same page. We're talking in the > > > > context of mediation. Without mediation, your proposal can't work. > > > > > > > Right. > > > > > > > So in this case, the guest driver is not talking with the device > > > > directly. Qemu needs to traps whatever it wants to achieve the > > > > mediation: > > > > > > > I prefer to avoid picking specific sw component here, but yes. QEMU can trap. > > > > > > > 1) It's perfectly fine that Qemu negotiated VERSION_1 but presented > > > > a mediated legacy device to guests. > > > Right but if VERSION_1 is negotiated, device will work as V_1 with 12B > > virtio_net_hdr. > > > > Shadow virtqueue could be used here. And we have much more issues without > > shadow virtqueue, more below. > > > > > > > > > 2) For MAC and Reset, Qemu can trap and do anything it wants. > > > > > > > The idea is not to poke in the fields even though such sw can. > > > MAC is RW in legacy. > > > Mac ia RO in 1.x. > > > > > > So QEMU cannot make RO register into RW. > > > > It can be done via using the control vq. Trap the MAC write and forward it via > > control virtqueue. > > > This proposal Is not implementing about vdpa mediator that requires far higher understanding in hypervisor. It's not related to vDPA, it's about a common technology that is used in virtualization. You do a trap and emulate the status, why can't you do that for others? > Such mediation works fine for vdpa and it is upto vdpa layer to do. Not relevant here. > > > > > > > The proposed solution in this series enables it and avoid per field sw > > interpretation and mediation in parsing values etc. > > > > I don't think it's possible. See the discussion about ORDER_PLATFORM and > > ACCESS_PLATFORM in previous threads. > > > I have read the previous thread. > Hypervisor will be limiting to those platforms where ORDER_PLATFORM is not needed. So you introduce a bunch of new facilities that only work on some specific archs. This breaks the architecture independence of virtio since 1.0. The root cause is legacy is not fit for hardware implementation, any kind of hardware that tries to offer legacy function will finally run into those corner cases which require extra interfaces which may finally end up with a (partial) duplication of the modern interface. > And this is a pci transitional device that uses the standard platform dma anyway so ACCESS_PLATFORM is not related. So which type of transactions did this device use when it is used via legacy MMIO BAR? Translated request or not? > > > > > > > What is proposed here, that > > > a. legacy registers are emulated as MMIO in a BAR. > > > b. This can be either be BAR0 or some other BAR > > > > > > Your question was why this flexibility? > > > > Yes. > > > > > > > > The reason is: > > > a. if device prefers to implement only two BARs, it can do so and have window > > for this 60+ config registers in an existing BAR. > > > b. if device prefers to implement a new BAR dedicated for legacy registers > > emulation, it is fine too. > > > > > > A mediating sw will be able to forward them regardless. > > > > I'm not sure I fully understand this. The only difference is that for b, it can only > > use BAR0. > Why do say it can use only BAR 0? Because: 1) It's the way current transitional device works 2) it's simple, a small extension to the transitional device instead of a brunch of facilities that is can do much less than this 3) it works for legacy drivers on some OSes such as Linux and DPDK, it means it works for bare metal which can't be achieved by your proposal here > > For example, a device may have implemented say only BAR2, and small portion of the BAR2 is pointing to legacy MMIO config registers. We're discussing spec changes, not a specific implementation here. Why is the device can't use BAR0, do you see any restriction in the spec? > A mediator hypervisor sw will be able to read/write to it when BAR0 is exposed towards the guest VM as IOBAR 0. So I don't think it can work: 1) This is very dangerous unless the spec mandates the size (this is also tricky since page size varies among arches) for any BAR/capability which is not what virtio wants, the spec leave those flexibility to the implementation: E.g """ The driver MUST accept a cap_len value which is larger than specified here. """ 2) A blocker for live migration (and compatibility), the hypervisor should not assume the size for any capability so for whatever case it should have a fallback for the case where the BAR can't be assigned. > > > Unless there's a new feature that mandates > > BAR0 (which I think is impossible since all the features are advertised via > > capabilities now). We're fine. > > > No new feature. Legacy BAR emulation is exposed via the extended capability we discussed providing the location. > > > > > > > > > Right, it doesn’t. But spec shouldn’t write BAR0 is only for > > > > > legacy MMIO > > > > emulation, that would prevent BAR0 usage. > > > > > > > > How can it be prevented? Can you give me an example? > > > > > > I mean to say, that say if we write a spec like below, > > > > > > A device exposes BAR 0 of size X bytes for supporting legacy configuration > > and device specific registers as memory mapped region. > > > > > > > Ok, it looks just a matter of how the spec is written. The problematic part is that > > it tries to enforce a size which is suboptimal. > > > > What's has been done is: > > > > " > > Transitional devices MUST expose the Legacy Interface in I/O space in BAR0. > > " > > > > Without mentioning the size. > > For new legacy MMIO registers can be implemented as BAR0 with same size. But better to not place such restriction like above wording. Let me summarize, we had three ways currently: 1) legacy MMIO BAR via capability: Pros: - allow some flexibility to place MMIO BAR other than 0 Cons: - new device ID - non trivial spec changes which ends up of the tricky cases that tries to workaround legacy to fit for a hardware implementation - work only for the case of virtualization with the help of meditation, can't work for bare metal - only work for some specific archs without SVQ 2) allow BAR0 to be MMIO for transitional device Pros: - very minor change for the spec - work for virtualization (and it work even without dedicated mediation for some setups) - work for bare metal for some setups (without mediation) Cons: - only work for some specific archs without SVQ - BAR0 is required 3) modern device mediation for legacy Pros: - no changes in the spec Cons: - require mediation layer in order to work in bare metal - require datapath mediation like SVQ to work for virtualization Compared to method 2) the only advantages of method 1) is the flexibility of BAR0 but it has too many disadvantages. If we only care about virtualization, modern devices are sufficient. Then why bother for that? Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com> To: Parav Pandit <parav@nvidia.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, "virtio-dev@lists.oasis-open.org" <virtio-dev@lists.oasis-open.org>, "cohuck@redhat.com" <cohuck@redhat.com>, "virtio-comment@lists.oasis-open.org" <virtio-comment@lists.oasis-open.org>, Shahaf Shuler <shahafs@nvidia.com>, Satananda Burla <sburla@marvell.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Yan Vugenfirer <yan@daynix.com> Subject: Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers Date: Thu, 13 Apr 2023 09:48:15 +0800 [thread overview] Message-ID: <CACGkMEuNOYOxvcSzrs0UFEyk+xOkGUpOfhK8rOy_Mebz5b5wdg@mail.gmail.com> (raw) In-Reply-To: <PH0PR12MB5481F0CF5A555A6BB2CE856CDC9B9@PH0PR12MB5481.namprd12.prod.outlook.com> On Wed, Apr 12, 2023 at 10:23 PM Parav Pandit <parav@nvidia.com> wrote: > > > > > From: Jason Wang <jasowang@redhat.com> > > Sent: Wednesday, April 12, 2023 2:15 AM > > > > On Wed, Apr 12, 2023 at 1:55 PM Parav Pandit <parav@nvidia.com> wrote: > > > > > > > > > > > > > From: Jason Wang <jasowang@redhat.com> > > > > Sent: Wednesday, April 12, 2023 1:38 AM > > > > > > > > Modern device says FEAETURE_1 must be offered and must be > > > > > negotiated by > > > > driver. > > > > > Legacy has Mac as RW area. (hypervisor can do it). > > > > > Reset flow is difference between the legacy and modern. > > > > > > > > Just to make sure we're at the same page. We're talking in the > > > > context of mediation. Without mediation, your proposal can't work. > > > > > > > Right. > > > > > > > So in this case, the guest driver is not talking with the device > > > > directly. Qemu needs to traps whatever it wants to achieve the > > > > mediation: > > > > > > > I prefer to avoid picking specific sw component here, but yes. QEMU can trap. > > > > > > > 1) It's perfectly fine that Qemu negotiated VERSION_1 but presented > > > > a mediated legacy device to guests. > > > Right but if VERSION_1 is negotiated, device will work as V_1 with 12B > > virtio_net_hdr. > > > > Shadow virtqueue could be used here. And we have much more issues without > > shadow virtqueue, more below. > > > > > > > > > 2) For MAC and Reset, Qemu can trap and do anything it wants. > > > > > > > The idea is not to poke in the fields even though such sw can. > > > MAC is RW in legacy. > > > Mac ia RO in 1.x. > > > > > > So QEMU cannot make RO register into RW. > > > > It can be done via using the control vq. Trap the MAC write and forward it via > > control virtqueue. > > > This proposal Is not implementing about vdpa mediator that requires far higher understanding in hypervisor. It's not related to vDPA, it's about a common technology that is used in virtualization. You do a trap and emulate the status, why can't you do that for others? > Such mediation works fine for vdpa and it is upto vdpa layer to do. Not relevant here. > > > > > > > The proposed solution in this series enables it and avoid per field sw > > interpretation and mediation in parsing values etc. > > > > I don't think it's possible. See the discussion about ORDER_PLATFORM and > > ACCESS_PLATFORM in previous threads. > > > I have read the previous thread. > Hypervisor will be limiting to those platforms where ORDER_PLATFORM is not needed. So you introduce a bunch of new facilities that only work on some specific archs. This breaks the architecture independence of virtio since 1.0. The root cause is legacy is not fit for hardware implementation, any kind of hardware that tries to offer legacy function will finally run into those corner cases which require extra interfaces which may finally end up with a (partial) duplication of the modern interface. > And this is a pci transitional device that uses the standard platform dma anyway so ACCESS_PLATFORM is not related. So which type of transactions did this device use when it is used via legacy MMIO BAR? Translated request or not? > > > > > > > What is proposed here, that > > > a. legacy registers are emulated as MMIO in a BAR. > > > b. This can be either be BAR0 or some other BAR > > > > > > Your question was why this flexibility? > > > > Yes. > > > > > > > > The reason is: > > > a. if device prefers to implement only two BARs, it can do so and have window > > for this 60+ config registers in an existing BAR. > > > b. if device prefers to implement a new BAR dedicated for legacy registers > > emulation, it is fine too. > > > > > > A mediating sw will be able to forward them regardless. > > > > I'm not sure I fully understand this. The only difference is that for b, it can only > > use BAR0. > Why do say it can use only BAR 0? Because: 1) It's the way current transitional device works 2) it's simple, a small extension to the transitional device instead of a brunch of facilities that is can do much less than this 3) it works for legacy drivers on some OSes such as Linux and DPDK, it means it works for bare metal which can't be achieved by your proposal here > > For example, a device may have implemented say only BAR2, and small portion of the BAR2 is pointing to legacy MMIO config registers. We're discussing spec changes, not a specific implementation here. Why is the device can't use BAR0, do you see any restriction in the spec? > A mediator hypervisor sw will be able to read/write to it when BAR0 is exposed towards the guest VM as IOBAR 0. So I don't think it can work: 1) This is very dangerous unless the spec mandates the size (this is also tricky since page size varies among arches) for any BAR/capability which is not what virtio wants, the spec leave those flexibility to the implementation: E.g """ The driver MUST accept a cap_len value which is larger than specified here. """ 2) A blocker for live migration (and compatibility), the hypervisor should not assume the size for any capability so for whatever case it should have a fallback for the case where the BAR can't be assigned. > > > Unless there's a new feature that mandates > > BAR0 (which I think is impossible since all the features are advertised via > > capabilities now). We're fine. > > > No new feature. Legacy BAR emulation is exposed via the extended capability we discussed providing the location. > > > > > > > > > Right, it doesn’t. But spec shouldn’t write BAR0 is only for > > > > > legacy MMIO > > > > emulation, that would prevent BAR0 usage. > > > > > > > > How can it be prevented? Can you give me an example? > > > > > > I mean to say, that say if we write a spec like below, > > > > > > A device exposes BAR 0 of size X bytes for supporting legacy configuration > > and device specific registers as memory mapped region. > > > > > > > Ok, it looks just a matter of how the spec is written. The problematic part is that > > it tries to enforce a size which is suboptimal. > > > > What's has been done is: > > > > " > > Transitional devices MUST expose the Legacy Interface in I/O space in BAR0. > > " > > > > Without mentioning the size. > > For new legacy MMIO registers can be implemented as BAR0 with same size. But better to not place such restriction like above wording. Let me summarize, we had three ways currently: 1) legacy MMIO BAR via capability: Pros: - allow some flexibility to place MMIO BAR other than 0 Cons: - new device ID - non trivial spec changes which ends up of the tricky cases that tries to workaround legacy to fit for a hardware implementation - work only for the case of virtualization with the help of meditation, can't work for bare metal - only work for some specific archs without SVQ 2) allow BAR0 to be MMIO for transitional device Pros: - very minor change for the spec - work for virtualization (and it work even without dedicated mediation for some setups) - work for bare metal for some setups (without mediation) Cons: - only work for some specific archs without SVQ - BAR0 is required 3) modern device mediation for legacy Pros: - no changes in the spec Cons: - require mediation layer in order to work in bare metal - require datapath mediation like SVQ to work for virtualization Compared to method 2) the only advantages of method 1) is the flexibility of BAR0 but it has too many disadvantages. If we only care about virtualization, modern devices are sufficient. Then why bother for that? Thanks This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2023-04-13 1:48 UTC|newest] Thread overview: 399+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-30 22:58 [virtio-dev] [PATCH 00/11] Introduce transitional mmr pci device Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-30 22:58 ` [virtio-dev] [PATCH 01/11] transport-pci: Use lowecase alphabets Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-30 22:58 ` [virtio-dev] [PATCH 02/11] transport-pci: Move transitional device id to legacy section Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-31 6:43 ` [virtio-dev] " Michael S. Tsirkin 2023-03-31 6:43 ` [virtio-comment] " Michael S. Tsirkin 2023-03-31 21:24 ` [virtio-dev] " Parav Pandit 2023-03-31 21:24 ` [virtio-comment] " Parav Pandit 2023-04-02 7:54 ` [virtio-dev] " Michael S. Tsirkin 2023-04-02 7:54 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 14:42 ` [virtio-dev] " Parav Pandit 2023-04-03 14:42 ` [virtio-comment] " Parav Pandit 2023-04-03 14:50 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 14:50 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 14:58 ` [virtio-dev] " Parav Pandit 2023-04-03 14:58 ` [virtio-comment] " Parav Pandit 2023-04-03 15:14 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 15:14 ` [virtio-comment] " Michael S. Tsirkin 2023-03-30 22:58 ` [virtio-dev] [PATCH 03/11] transport-pci: Split notes of PCI Device Layout Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-30 22:58 ` [virtio-dev] [PATCH 04/11] transport-pci: Rename and move legacy PCI Device layout section Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-30 22:58 ` [virtio-dev] [PATCH 05/11] introduction: Add missing helping verb Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-30 22:58 ` [virtio-dev] [PATCH 06/11] introduction: Introduce transitional MMR interface Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-04-07 9:17 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 9:17 ` [virtio-comment] " Michael S. Tsirkin 2023-03-30 22:58 ` [virtio-dev] [PATCH 07/11] transport-pci: Introduce transitional MMR device id Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-04-04 7:28 ` [virtio-dev] " Michael S. Tsirkin 2023-04-04 7:28 ` [virtio-comment] " Michael S. Tsirkin 2023-04-04 16:08 ` [virtio-dev] " Parav Pandit 2023-04-04 16:08 ` [virtio-comment] " Parav Pandit 2023-04-07 12:03 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 12:03 ` Michael S. Tsirkin 2023-04-07 15:18 ` Parav Pandit 2023-04-07 15:18 ` [virtio-dev] " Parav Pandit 2023-04-07 15:51 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 15:51 ` Michael S. Tsirkin 2023-04-09 3:15 ` [virtio-dev] " Parav Pandit 2023-04-09 3:15 ` Parav Pandit 2023-04-10 10:18 ` [virtio-dev] " Michael S. Tsirkin 2023-04-10 10:18 ` Michael S. Tsirkin 2023-04-10 14:34 ` [virtio-dev] " Parav Pandit 2023-04-10 14:34 ` Parav Pandit 2023-04-10 19:58 ` [virtio-dev] " Michael S. Tsirkin 2023-04-10 19:58 ` Michael S. Tsirkin 2023-04-10 20:16 ` [virtio-dev] " Parav Pandit 2023-04-10 20:16 ` Parav Pandit 2023-04-07 8:37 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 8:37 ` [virtio-comment] " Michael S. Tsirkin 2023-03-30 22:58 ` [virtio-dev] [PATCH 08/11] transport-pci: Introduce virtio extended capability Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-04-04 7:35 ` [virtio-dev] " Michael S. Tsirkin 2023-04-04 7:35 ` [virtio-comment] " Michael S. Tsirkin 2023-04-04 7:54 ` [virtio-dev] " Cornelia Huck 2023-04-04 7:54 ` [virtio-comment] " Cornelia Huck 2023-04-04 12:43 ` [virtio-dev] " Michael S. Tsirkin 2023-04-04 12:43 ` [virtio-comment] " Michael S. Tsirkin 2023-04-04 13:19 ` [virtio-dev] " Cornelia Huck 2023-04-04 13:19 ` [virtio-comment] " Cornelia Huck 2023-04-04 14:37 ` [virtio-dev] " Michael S. Tsirkin 2023-04-04 14:37 ` [virtio-comment] " Michael S. Tsirkin 2023-04-10 16:21 ` [virtio-dev] " Parav Pandit 2023-04-10 16:21 ` [virtio-comment] " Parav Pandit 2023-04-10 19:49 ` [virtio-dev] " Michael S. Tsirkin 2023-04-10 19:49 ` [virtio-comment] " Michael S. Tsirkin 2023-04-10 19:57 ` [virtio-dev] " Parav Pandit 2023-04-10 19:57 ` [virtio-comment] " Parav Pandit 2023-04-10 20:02 ` [virtio-dev] " Michael S. Tsirkin 2023-04-10 20:02 ` [virtio-comment] " Michael S. Tsirkin 2023-04-11 8:39 ` [virtio-dev] " Cornelia Huck 2023-04-11 8:39 ` [virtio-comment] " Cornelia Huck 2023-04-04 21:18 ` [virtio-dev] " Parav Pandit 2023-04-04 21:18 ` [virtio-comment] " Parav Pandit 2023-04-05 5:10 ` [virtio-dev] " Michael S. Tsirkin 2023-04-05 5:10 ` [virtio-comment] " Michael S. Tsirkin 2023-04-05 13:16 ` [virtio-dev] " Parav Pandit 2023-04-05 13:16 ` [virtio-comment] " Parav Pandit 2023-04-07 8:15 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 8:15 ` [virtio-comment] " Michael S. Tsirkin 2023-04-10 1:36 ` [virtio-dev] " Jason Wang 2023-04-10 1:36 ` [virtio-comment] " Jason Wang 2023-04-10 6:24 ` Michael S. Tsirkin 2023-04-10 6:24 ` [virtio-comment] " Michael S. Tsirkin 2023-04-10 7:16 ` Jason Wang 2023-04-10 7:16 ` [virtio-comment] " Jason Wang 2023-04-10 10:04 ` Michael S. Tsirkin 2023-04-10 10:04 ` [virtio-comment] " Michael S. Tsirkin 2023-04-11 2:19 ` Jason Wang 2023-04-11 2:19 ` [virtio-comment] " Jason Wang 2023-04-11 7:00 ` Michael S. Tsirkin 2023-04-11 7:00 ` [virtio-comment] " Michael S. Tsirkin 2023-04-11 9:07 ` Jason Wang 2023-04-11 9:07 ` [virtio-comment] " Jason Wang 2023-04-11 10:43 ` Michael S. Tsirkin 2023-04-11 10:43 ` [virtio-comment] " Michael S. Tsirkin 2023-04-11 13:59 ` Parav Pandit 2023-04-11 13:59 ` [virtio-comment] " Parav Pandit 2023-04-11 14:11 ` Michael S. Tsirkin 2023-04-11 14:11 ` [virtio-comment] " Michael S. Tsirkin 2023-04-11 13:47 ` Parav Pandit 2023-04-11 13:47 ` [virtio-comment] " Parav Pandit 2023-04-11 14:02 ` Michael S. Tsirkin 2023-04-11 14:02 ` [virtio-comment] " Michael S. Tsirkin 2023-04-11 14:07 ` [virtio-dev] " Parav Pandit 2023-04-11 14:07 ` Parav Pandit 2023-04-11 14:10 ` [virtio-dev] " Michael S. Tsirkin 2023-04-11 14:10 ` Michael S. Tsirkin 2023-04-11 14:30 ` [virtio-dev] " Parav Pandit 2023-04-11 14:30 ` Parav Pandit 2023-04-10 17:54 ` Parav Pandit 2023-04-10 17:54 ` [virtio-comment] " Parav Pandit 2023-04-10 17:58 ` [virtio-dev] " Parav Pandit 2023-04-10 17:58 ` Parav Pandit 2023-04-11 3:28 ` Jason Wang 2023-04-11 3:28 ` [virtio-comment] " Jason Wang 2023-04-11 19:01 ` Parav Pandit 2023-04-11 19:01 ` [virtio-comment] " Parav Pandit 2023-04-11 21:25 ` Michael S. Tsirkin 2023-04-11 21:25 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 0:40 ` Parav Pandit 2023-04-12 0:40 ` [virtio-comment] " Parav Pandit 2023-04-12 2:56 ` Michael S. Tsirkin 2023-04-12 2:56 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 4:07 ` Jason Wang 2023-04-12 4:07 ` [virtio-comment] " Jason Wang 2023-04-12 4:20 ` Michael S. Tsirkin 2023-04-12 4:20 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 4:53 ` [virtio-dev] " Jason Wang 2023-04-12 4:53 ` Jason Wang 2023-04-12 5:25 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 5:25 ` Michael S. Tsirkin 2023-04-12 5:37 ` [virtio-dev] " Jason Wang 2023-04-12 5:37 ` Jason Wang 2023-04-13 17:03 ` [virtio-dev] " Michael S. Tsirkin 2023-04-13 17:03 ` Michael S. Tsirkin 2023-04-12 4:04 ` Jason Wang 2023-04-12 4:04 ` [virtio-comment] " Jason Wang 2023-04-12 4:13 ` Parav Pandit 2023-04-12 4:13 ` [virtio-comment] " Parav Pandit 2023-04-12 4:20 ` Michael S. Tsirkin 2023-04-12 4:20 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 4:55 ` Jason Wang 2023-04-12 4:55 ` [virtio-comment] " Jason Wang 2023-05-19 6:10 ` [virtio-dev] " Michael S. Tsirkin 2023-05-19 6:10 ` [virtio-comment] " Michael S. Tsirkin 2023-05-19 21:02 ` [virtio-dev] " Parav Pandit 2023-05-19 21:02 ` [virtio-comment] " Parav Pandit 2023-05-21 5:57 ` [virtio-dev] " Michael S. Tsirkin 2023-05-21 5:57 ` [virtio-comment] " Michael S. Tsirkin 2023-05-21 13:24 ` [virtio-dev] " Parav Pandit 2023-05-21 13:24 ` [virtio-comment] " Parav Pandit 2023-05-21 14:34 ` [virtio-dev] " Michael S. Tsirkin 2023-05-21 14:34 ` [virtio-comment] " Michael S. Tsirkin 2023-03-30 22:58 ` [virtio-dev] [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-04-07 8:55 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 8:55 ` [virtio-comment] " Michael S. Tsirkin 2023-04-10 1:33 ` Jason Wang 2023-04-10 1:33 ` [virtio-dev] " Jason Wang 2023-04-10 6:14 ` Michael S. Tsirkin 2023-04-10 6:14 ` Michael S. Tsirkin 2023-04-10 6:20 ` [virtio-dev] " Jason Wang 2023-04-10 6:20 ` Jason Wang 2023-04-10 6:39 ` [virtio-dev] " Michael S. Tsirkin 2023-04-10 6:39 ` Michael S. Tsirkin 2023-04-10 7:20 ` [virtio-dev] " Jason Wang 2023-04-10 7:20 ` Jason Wang 2023-04-10 10:06 ` [virtio-dev] " Michael S. Tsirkin 2023-04-10 10:06 ` Michael S. Tsirkin 2023-04-11 2:13 ` [virtio-dev] " Jason Wang 2023-04-11 2:13 ` Jason Wang 2023-04-11 7:04 ` [virtio-dev] " Michael S. Tsirkin 2023-04-11 7:04 ` Michael S. Tsirkin 2023-04-11 9:01 ` [virtio-dev] " Jason Wang 2023-04-11 9:01 ` Jason Wang [not found] ` <CALBs2cXURMEzCGnULicXbsBfwnKE5cZOz=M-_hhFCXZ=Lqb9Nw@mail.gmail.com> 2023-04-11 10:39 ` [virtio-dev] " Michael S. Tsirkin 2023-04-11 10:39 ` Michael S. Tsirkin 2023-04-11 11:03 ` [virtio-dev] " Yan Vugenfirer 2023-04-11 10:42 ` Michael S. Tsirkin 2023-04-11 10:42 ` Michael S. Tsirkin 2023-04-12 3:58 ` [virtio-dev] " Jason Wang 2023-04-12 3:58 ` Jason Wang 2023-04-12 4:15 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 4:15 ` Michael S. Tsirkin 2023-04-12 4:51 ` [virtio-dev] " Jason Wang 2023-04-12 4:51 ` Jason Wang 2023-04-12 5:01 ` [virtio-dev] " Parav Pandit 2023-04-12 5:01 ` Parav Pandit 2023-04-12 5:14 ` [virtio-dev] " Jason Wang 2023-04-12 5:14 ` Jason Wang 2023-04-12 5:30 ` [virtio-dev] " Parav Pandit 2023-04-12 5:30 ` Parav Pandit 2023-04-12 5:38 ` [virtio-dev] " Jason Wang 2023-04-12 5:38 ` Jason Wang 2023-04-12 5:55 ` [virtio-dev] " Parav Pandit 2023-04-12 5:55 ` Parav Pandit 2023-04-12 6:15 ` [virtio-dev] " Jason Wang 2023-04-12 6:15 ` Jason Wang 2023-04-12 14:23 ` [virtio-dev] " Parav Pandit 2023-04-12 14:23 ` Parav Pandit 2023-04-13 1:48 ` Jason Wang [this message] 2023-04-13 1:48 ` Jason Wang 2023-04-13 3:31 ` [virtio-dev] " Parav Pandit 2023-04-13 3:31 ` Parav Pandit 2023-04-13 5:14 ` [virtio-dev] " Jason Wang 2023-04-13 5:14 ` Jason Wang 2023-04-13 17:19 ` [virtio-dev] " Michael S. Tsirkin 2023-04-13 17:19 ` Michael S. Tsirkin 2023-04-13 19:39 ` [virtio-dev] " Parav Pandit 2023-04-13 19:39 ` Parav Pandit 2023-04-14 3:09 ` [virtio-dev] " Jason Wang 2023-04-14 3:09 ` Jason Wang 2023-04-14 3:18 ` [virtio-dev] " Parav Pandit 2023-04-14 3:18 ` Parav Pandit 2023-04-14 3:37 ` [virtio-dev] " Jason Wang 2023-04-14 3:37 ` Jason Wang 2023-04-14 3:51 ` [virtio-dev] " Parav Pandit 2023-04-14 3:51 ` Parav Pandit 2023-04-14 7:05 ` [virtio-dev] " Michael S. Tsirkin 2023-04-14 7:05 ` Michael S. Tsirkin 2023-04-17 3:22 ` [virtio-dev] " Jason Wang 2023-04-17 3:22 ` Jason Wang 2023-04-17 17:23 ` [virtio-dev] " Parav Pandit 2023-04-17 17:23 ` Parav Pandit 2023-04-17 20:26 ` [virtio-dev] " Michael S. Tsirkin 2023-04-17 20:26 ` Michael S. Tsirkin 2023-04-17 20:28 ` [virtio-dev] " Parav Pandit 2023-04-17 20:28 ` Parav Pandit 2023-04-18 0:36 ` [virtio-dev] " Jason Wang 2023-04-18 0:36 ` Jason Wang 2023-04-18 1:30 ` [virtio-dev] " Parav Pandit 2023-04-18 1:30 ` Parav Pandit 2023-04-18 11:58 ` [virtio-dev] " Michael S. Tsirkin 2023-04-18 11:58 ` Michael S. Tsirkin 2023-04-18 12:09 ` [virtio-dev] " Parav Pandit 2023-04-18 12:09 ` Parav Pandit 2023-04-18 12:30 ` [virtio-dev] " Michael S. Tsirkin 2023-04-18 12:30 ` Michael S. Tsirkin 2023-04-18 12:36 ` [virtio-dev] " Parav Pandit 2023-04-18 12:36 ` Parav Pandit 2023-04-18 1:01 ` Jason Wang 2023-04-18 1:01 ` [virtio-dev] " Jason Wang 2023-04-18 1:48 ` [virtio-dev] " Parav Pandit 2023-04-18 1:48 ` Parav Pandit 2023-04-13 17:24 ` [virtio-dev] " Parav Pandit 2023-04-13 17:24 ` Parav Pandit 2023-04-13 21:02 ` [virtio-dev] " Michael S. Tsirkin 2023-04-13 21:02 ` Michael S. Tsirkin 2023-04-13 21:08 ` [virtio-dev] " Parav Pandit 2023-04-13 21:08 ` Parav Pandit 2023-04-14 2:36 ` [virtio-dev] " Jason Wang 2023-04-14 2:36 ` Jason Wang 2023-04-14 2:43 ` [virtio-dev] " Parav Pandit 2023-04-14 2:43 ` Parav Pandit 2023-04-14 6:57 ` [virtio-dev] " Michael S. Tsirkin 2023-04-14 6:57 ` Michael S. Tsirkin 2023-04-16 13:41 ` Parav Pandit 2023-04-16 13:41 ` [virtio-dev] " Parav Pandit 2023-04-16 20:44 ` [virtio-dev] " Michael S. Tsirkin 2023-04-16 20:44 ` Michael S. Tsirkin 2023-04-17 16:59 ` [virtio-dev] " Parav Pandit 2023-04-17 16:59 ` Parav Pandit 2023-04-18 1:09 ` [virtio-dev] " Jason Wang 2023-04-18 1:09 ` Jason Wang 2023-04-18 1:37 ` [virtio-dev] " Parav Pandit 2023-04-18 1:37 ` Parav Pandit 2023-04-14 6:58 ` [virtio-dev] " Michael S. Tsirkin 2023-04-14 6:58 ` Michael S. Tsirkin 2023-04-14 3:08 ` [virtio-dev] " Jason Wang 2023-04-14 3:08 ` Jason Wang 2023-04-14 3:13 ` [virtio-dev] " Parav Pandit 2023-04-14 3:13 ` Parav Pandit 2023-04-14 3:18 ` [virtio-dev] " Jason Wang 2023-04-14 3:18 ` Jason Wang 2023-04-14 3:22 ` [virtio-dev] " Parav Pandit 2023-04-14 3:22 ` Parav Pandit 2023-04-14 3:29 ` [virtio-dev] " Jason Wang 2023-04-14 3:29 ` Jason Wang 2023-04-11 13:57 ` [virtio-dev] " Parav Pandit 2023-04-11 13:57 ` Parav Pandit 2023-04-12 4:33 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 4:33 ` [virtio-comment] " Michael S. Tsirkin 2023-03-30 22:58 ` [virtio-dev] [PATCH 10/11] transport-pci: Use driver notification PCI capability Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-04-12 4:31 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 4:31 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 4:37 ` [virtio-dev] " Parav Pandit 2023-04-12 4:37 ` [virtio-comment] " Parav Pandit 2023-04-12 4:43 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 4:43 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 4:48 ` [virtio-dev] " Parav Pandit 2023-04-12 4:48 ` [virtio-comment] " Parav Pandit 2023-04-12 5:02 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 5:02 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 5:06 ` [virtio-dev] " Parav Pandit 2023-04-12 5:06 ` Parav Pandit 2023-04-12 5:17 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 5:17 ` Michael S. Tsirkin 2023-04-12 5:24 ` [virtio-dev] " Parav Pandit 2023-04-12 5:24 ` Parav Pandit 2023-04-12 5:27 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 5:27 ` Michael S. Tsirkin 2023-03-30 22:58 ` [virtio-dev] [PATCH 11/11] conformance: Add transitional MMR interface conformance Parav Pandit 2023-03-30 22:58 ` [virtio-comment] " Parav Pandit 2023-03-31 7:03 ` [virtio-dev] Re: [PATCH 00/11] Introduce transitional mmr pci device Michael S. Tsirkin 2023-03-31 7:03 ` [virtio-comment] " Michael S. Tsirkin 2023-03-31 21:43 ` [virtio-dev] " Parav Pandit 2023-03-31 21:43 ` [virtio-comment] " Parav Pandit 2023-04-03 14:53 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 14:53 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 14:57 ` [virtio-dev] " Parav Pandit 2023-04-03 14:57 ` [virtio-comment] " Parav Pandit 2023-04-03 15:06 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 15:06 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 15:16 ` [virtio-dev] " Parav Pandit 2023-04-03 15:16 ` [virtio-comment] " Parav Pandit 2023-04-03 15:23 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 15:23 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 15:34 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 15:34 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 15:47 ` [virtio-dev] " Parav Pandit 2023-04-03 15:47 ` [virtio-comment] " Parav Pandit 2023-04-03 17:28 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 17:28 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 17:35 ` [virtio-dev] " Parav Pandit 2023-04-03 17:35 ` [virtio-comment] " Parav Pandit 2023-04-03 17:39 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 17:39 ` [virtio-comment] " Michael S. Tsirkin 2023-04-03 15:36 ` [virtio-dev] " Parav Pandit 2023-04-03 15:36 ` Parav Pandit 2023-04-03 17:16 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 17:16 ` Michael S. Tsirkin 2023-04-03 17:29 ` [virtio-dev] " Parav Pandit 2023-04-03 17:29 ` Parav Pandit 2023-04-03 18:02 ` Michael S. Tsirkin 2023-04-03 18:02 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 20:25 ` [virtio-dev] " Parav Pandit 2023-04-03 20:25 ` Parav Pandit 2023-04-03 21:04 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 21:04 ` Michael S. Tsirkin 2023-04-03 22:00 ` [virtio-dev] " Parav Pandit 2023-04-03 22:00 ` Parav Pandit 2023-04-07 9:35 ` [virtio-dev] " Michael S. Tsirkin 2023-04-07 9:35 ` Michael S. Tsirkin 2023-04-10 1:52 ` [virtio-dev] " Jason Wang 2023-04-10 1:52 ` Jason Wang 2023-04-03 14:45 ` [virtio-dev] Re: [virtio-comment] " Stefan Hajnoczi 2023-04-03 14:45 ` Stefan Hajnoczi 2023-04-03 14:53 ` [virtio-dev] " Parav Pandit 2023-04-03 14:53 ` Parav Pandit 2023-04-03 17:48 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 17:48 ` Michael S. Tsirkin 2023-04-03 19:11 ` [virtio-dev] " Stefan Hajnoczi 2023-04-03 19:11 ` Stefan Hajnoczi 2023-04-03 20:03 ` Michael S. Tsirkin 2023-04-03 20:03 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 19:48 ` [virtio-dev] " Parav Pandit 2023-04-03 19:48 ` Parav Pandit 2023-04-03 20:02 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 20:02 ` Michael S. Tsirkin 2023-04-03 20:42 ` [virtio-dev] " Parav Pandit 2023-04-03 20:42 ` Parav Pandit 2023-04-03 21:14 ` [virtio-dev] " Michael S. Tsirkin 2023-04-03 21:14 ` Michael S. Tsirkin 2023-04-03 22:08 ` [virtio-dev] " Parav Pandit 2023-04-03 22:08 ` Parav Pandit 2023-04-03 19:10 ` [virtio-dev] " Stefan Hajnoczi 2023-04-03 19:10 ` Stefan Hajnoczi 2023-04-03 20:27 ` Parav Pandit 2023-04-03 20:27 ` [virtio-dev] " Parav Pandit 2023-04-04 14:30 ` [virtio-dev] " Stefan Hajnoczi 2023-04-04 14:30 ` Stefan Hajnoczi 2023-04-12 4:48 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 4:48 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 4:52 ` [virtio-dev] " Parav Pandit 2023-04-12 4:52 ` [virtio-comment] " Parav Pandit 2023-04-12 5:12 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 5:12 ` [virtio-comment] " Michael S. Tsirkin 2023-04-12 5:15 ` [virtio-dev] " Parav Pandit 2023-04-12 5:15 ` Parav Pandit 2023-04-12 5:23 ` [virtio-dev] " Michael S. Tsirkin 2023-04-12 5:23 ` Michael S. Tsirkin 2023-04-12 5:39 ` [virtio-dev] " Parav Pandit 2023-04-12 5:39 ` Parav Pandit 2023-04-12 6:02 ` [virtio-dev] " Parav Pandit 2023-04-12 6:02 ` Parav Pandit 2023-04-12 5:10 ` [virtio-dev] " Halil Pasic 2023-04-12 5:10 ` [virtio-comment] " Halil Pasic 2023-04-25 2:42 ` [virtio-dev] " Parav Pandit 2023-04-25 2:42 ` [virtio-comment] " Parav Pandit 2023-05-02 7:17 ` [virtio-dev] " David Edmondson 2023-05-02 7:17 ` David Edmondson 2023-05-02 13:54 ` [virtio-dev] " Parav Pandit 2023-05-02 13:54 ` Parav Pandit
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=CACGkMEuNOYOxvcSzrs0UFEyk+xOkGUpOfhK8rOy_Mebz5b5wdg@mail.gmail.com \ --to=jasowang@redhat.com \ --cc=cohuck@redhat.com \ --cc=maxime.coquelin@redhat.com \ --cc=mst@redhat.com \ --cc=parav@nvidia.com \ --cc=sburla@marvell.com \ --cc=shahafs@nvidia.com \ --cc=virtio-comment@lists.oasis-open.org \ --cc=virtio-dev@lists.oasis-open.org \ --cc=yan@daynix.com \ /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: linkBe 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.