From: "Michael S. Tsirkin" <mst@redhat.com>
To: Venu Busireddy <venu.busireddy@oracle.com>
Cc: virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] [PATCH 0/1] Add "Group Identifier" to virtio PCI capabilities.
Date: Sat, 2 Jun 2018 00:10:31 +0300 [thread overview]
Message-ID: <20180602000956-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180602000506-mutt-send-email-mst@kernel.org>
On Sat, Jun 02, 2018 at 12:09:35AM +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2018 at 03:50:43PM -0500, Venu Busireddy wrote:
> > On 2018-06-01 23:03:16 +0300, Michael S. Tsirkin wrote:
> > > On Fri, Jun 01, 2018 at 12:01:26PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-01 18:42:06 +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, May 23, 2018 at 11:16:12AM -0400, Venu Busireddy wrote:
> > > > > > During live migration involving passthrough devices, the guest needs
> > > > > > to know which virtio device will be a fail-over device for a given
> > > > > > passthrough device.
> > > > > >
> > > > > > Extending the virtio specification with a new "Group Identifier"
> > > > > > capability allows qemu to set up the grouping at the time the guest
> > > > > > is created. The "Group Identifier" can be as simple as a number, or an
> > > > > > UUID. The driver can use the group identifier to pair the virtio device
> > > > > > with the passthrough device. The passthrough device can contain the
> > > > > > group identifier in the PCIe bridge to which it is attached.
> > > > > >
> > > > > > Venu Busireddy (1):
> > > > > > Add "Group Identifier" to virtio PCI capabilities.
> > > > > >
> > > > > > content.tex | 43 +++++++++++++++++++++++++++++++++++++++++++
> > > > > > 1 file changed, 43 insertions(+)
> > > > >
> > > > > Is this a PCI thing, or can this somehow be used with non-PCI
> > > >
> > > > This is applicable to all virtio PCI devices, but not to non-PCI
> > > > devices.
> > > >
> > > > > devices? If PCI, we can just add a PCI UUID capability to
> > > > > virtio without need to worry about the spec.
> > > >
> > > > What is a "PCI UUID capability?" "PCI Local Bus Specification
> > > > Revision 3.0, Appendix H" does not list any such capability.
> > > >
> > > > Regards,
> > > >
> > > > Venu
> > >
> > > Sorry that I'm unclear. What I meant is the
> > > PCI Express serial number capability (0003h).
> >
> > 0003h is the VPD capability.
>
> You are talking about the PCI capabilities.
> I'm talking about PCI Extended capabilities.
>
> These are not the same thing.
>
> > Serial Number ("SN") is part of the VPD. QEMU
> > does not support VPD, and adding the VPD capability to QEMU is lot more
> > involved than storing the UUID in Vendor-Specific capability.
>
> Formatting VPD is not so hard really. Another question would be how hard
> is it to parse VPD in guests? It might be hard e.g. for windows drivers.
>
> > Do you strongly believe that adding VPD is required? Or, can we live
> > with using Vendor-Specific capability? The bridge device is going to be
> > QEMU specific device anyway, so there should be no ambiguity of mixing
> > up with other bridges.
> >
> > Thanks,
> >
> > Venu
>
> I'm inclined to say use the serial number extended capability.
> If not, I'd look at how hard it is to parse VPD.
>
> Standard cap is better in that guests will be able to show it more
> easily.
But yes, it's not a very strong preference. If you strongly
believe we must use a vendor specific cap, I can live with
that decision.
> --
> MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2018-06-01 21:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 15:16 [virtio-dev] [PATCH 0/1] Add "Group Identifier" to virtio PCI capabilities Venu Busireddy
2018-05-23 15:16 ` [virtio-dev] [PATCH 1/1] " Venu Busireddy
2018-06-01 15:42 ` [virtio-dev] [PATCH 0/1] " Michael S. Tsirkin
2018-06-01 17:01 ` Venu Busireddy
2018-06-01 20:03 ` Michael S. Tsirkin
2018-06-01 20:36 ` Siwei Liu
2018-06-01 21:03 ` Michael S. Tsirkin
2018-06-01 21:29 ` Siwei Liu
2018-06-01 20:50 ` Venu Busireddy
2018-06-01 21:09 ` Michael S. Tsirkin
2018-06-01 21:10 ` Michael S. Tsirkin [this message]
2018-06-04 16:44 ` Venu Busireddy
2018-06-04 17:42 ` Michael S. Tsirkin
2018-06-04 18:13 ` Venu Busireddy
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=20180602000956-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=venu.busireddy@oracle.com \
--cc=virtio-dev@lists.oasis-open.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.