Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox