virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: kvm@vger.kernel.org, will.deacon@arm.com,
	virtualization@lists.linux-foundation.org,
	Stefan Fritsch <sf@sfritsch.de>,
	penberg@iki.fi
Subject: Re: [PATCH RFC] virtio-pci: share config interrupt between virtio devices
Date: Sun, 21 Sep 2014 18:02:59 +0300	[thread overview]
Message-ID: <20140921150259.GA27059@redhat.com> (raw)
In-Reply-To: <541ED707.4050100@oracle.com>

On Sun, Sep 21, 2014 at 09:47:51AM -0400, Sasha Levin wrote:
> On 09/21/2014 04:09 AM, Michael S. Tsirkin wrote:
> >> The virtio 0.9.5 spec says that ISR is "unused" when in MSI-X mode. I 
> >> > don't think that you can depend on the device to set the configuration 
> >> > changed bit.
> >> > The virtio 1.0 spec seems to have fixed that.
> > Yes, virtio 0.9.5 has this bug. But in practice qemu always set this
> > bit, so for qemu we could do that unconditionally.  Pekka's lkvm tool
> > doesn't unfortunately.  It's easy to fix that, but it would be nicer to
> > additionally probe for old versions of the tool, and disable IRQF_SHARED
> > in that case.
> >
> > To complicate things, lkvm does not use a distinct subsystem vendor ID,
> > in spite of the fact the virtio spec always required this explicitly.
> 
> I think I may be a bit confused here, but AFAIK we do set subsystem vendor
> ID properly for our virtio-pci devices?
> 
>         vpci->pci_hdr = (struct pci_device_header) {
>                 .vendor_id              = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET),
>                 .device_id              = cpu_to_le16(device_id),
> 		[...]
>                 .subsys_vendor_id       = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET),
> 
> 
> Thanks,
> Sasha


Yes but the spec says:
	The Subsystem Vendor ID should reflect the PCI Vendor ID of the environment.

IOW lkvm shouldn't reuse the ID from qemu, it should have its own
(qemu and lkvm hypervisors being a different environment).

virtio 1.0 have weakened this requirement:
	The PCI Subsystem Vendor ID and the PCI Subsystem Device ID MAY
	reflect the PCI Vendor and Device
	ID of the environment (for informational purposes by the driver).

I reasoned that since it's for informational purposes only, there's no
reason to make it a SHOULD.

It might or might not be a good idea to change it back, worth
considering.


-- 
MST

  reply	other threads:[~2014-09-21 15:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01  5:41 [PATCH RFC] virtio-pci: share config interrupt between virtio devices Amos Kong
2014-09-01  6:37 ` Michael S. Tsirkin
2014-09-01  7:58   ` Amos Kong
2014-09-01  8:12     ` Michael S. Tsirkin
2014-09-18 19:18   ` Stefan Fritsch
     [not found]   ` <11860049.kd4R4PIiz4@k>
2014-09-21  8:09     ` Michael S. Tsirkin
2014-09-21  9:36       ` Stefan Fritsch
2014-09-21 10:21         ` Michael S. Tsirkin
2014-09-23 20:47           ` Stefan Fritsch
2014-09-21 13:47       ` Sasha Levin
2014-09-21 15:02         ` Michael S. Tsirkin [this message]
2014-09-21 15:19           ` Sasha Levin
2014-09-21 17:53             ` Michael S. Tsirkin

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=20140921150259.GA27059@redhat.com \
    --to=mst@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=penberg@iki.fi \
    --cc=sasha.levin@oracle.com \
    --cc=sf@sfritsch.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will.deacon@arm.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: 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;
as well as URLs for NNTP newsgroup(s).