From: Rusty Russell <rusty@rustcorp.com.au>
To: Anthony Liguori <aliguori@us.ibm.com>, Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org,
qemu-devel <qemu-devel@nongnu.org>,
kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] Using PCI config space to indicate config location
Date: Tue, 09 Oct 2012 10:26:12 +1030 [thread overview]
Message-ID: <87sj9o8qn7.fsf@rustcorp.com.au> (raw)
In-Reply-To: <874nm4u1in.fsf@codemonkey.ws>
Anthony Liguori <aliguori@us.ibm.com> writes:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>> Hi,
>>
>>>> So we could have for virtio something like this:
>>>>
>>>> Capabilities: [??] virtio-regs:
>>>> legacy: BAR=0 offset=0
>>>> virtio-pci: BAR=1 offset=1000
>>>> virtio-cfg: BAR=1 offset=1800
>>>
>>> This would be a vendor specific PCI capability so lspci wouldn't
>>> automatically know how to parse it.
>>
>> Sure, would need a patch to actually parse+print the cap,
>> /me was just trying to make my point clear in a simple way.
>>
>>>>>> 2) ISTR an argument about mapping the ISR register separately, for
>>>>>> performance, but I can't find a reference to it.
>>>>>
>>>>> I think the rationale is that ISR really needs to be PIO but everything
>>>>> else doesn't. PIO is much faster on x86 because it doesn't require
>>>>> walking page tables or instruction emulation to handle the exit.
>>>>
>>>> Is this still a pressing issue? With MSI-X enabled ISR isn't needed,
>>>> correct? Which would imply that pretty much only old guests without
>>>> MSI-X support need this, and we don't need to worry that much when
>>>> designing something new ...
>>>
>>> It wasn't that long ago that MSI-X wasn't supported.. I think we should
>>> continue to keep ISR as PIO as it is a fast path.
>>
>> No problem if we allow to have both legacy layout and new layout at the
>> same time. Guests can continue to use ISR @ BAR0 in PIO space for
>> existing virtio devices, even in case they want use mmio for other
>> registers -> all fine.
>>
>> New virtio devices can support MSI-X from day one and decide to not
>> expose a legacy layout PIO bar.
>
> I think having BAR1 be an MMIO mirror of the registers + a BAR2 for
> virtio configuration space is probably not that bad of a solution.
Well, we also want to clean up the registers, so how about:
BAR0: legacy, as is. If you access this, don't use the others.
BAR1: new format virtio-pci layout. If you use this, don't use BAR0.
BAR2: virtio-cfg. If you use this, don't use BAR0.
BAR3: ISR. If you use this, don't use BAR0.
I prefer the cases exclusive (ie. use one or the other) as a clear path
to remove the legacy layout; and leaving the ISR in BAR0 leaves us with
an ugly corner case in future (ISR is BAR0 + 19? WTF?).
As to MMIO vs PIO, the BARs are self-describing, so we should explicitly
endorse that and leave it to the devices.
The detection is simple: if BAR1 has non-zero length, it's new-style,
otherwise legacy.
Thoughts?
Rusty.
next prev parent reply other threads:[~2012-10-08 23:56 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 0:29 Proposal for virtio standardization Rusty Russell
2012-09-27 0:29 ` [Qemu-devel] " Rusty Russell
2012-09-27 0:29 ` Rusty Russell
2012-10-04 18:49 ` [Qemu-devel] " Anthony Liguori
2012-10-04 18:49 ` Anthony Liguori
2012-10-08 2:21 ` Using PCI config space to indicate config location Rusty Russell
2012-10-08 2:21 ` Rusty Russell
2012-10-08 2:21 ` [Qemu-devel] " Rusty Russell
2012-10-08 13:58 ` Anthony Liguori
2012-10-08 13:58 ` Anthony Liguori
2012-10-08 14:58 ` Gerd Hoffmann
2012-10-08 14:58 ` Gerd Hoffmann
2012-10-08 15:09 ` Anthony Liguori
2012-10-08 15:09 ` Anthony Liguori
2012-10-08 20:13 ` Gerd Hoffmann
2012-10-08 20:13 ` Gerd Hoffmann
2012-10-08 20:55 ` Anthony Liguori
2012-10-08 20:55 ` Anthony Liguori
2012-10-08 23:56 ` Rusty Russell [this message]
2012-10-09 1:51 ` Anthony Liguori
2012-10-09 3:16 ` Rusty Russell
2012-10-09 3:16 ` Rusty Russell
2012-10-09 10:17 ` Avi Kivity
2012-10-09 10:17 ` Avi Kivity
2012-10-09 14:03 ` Anthony Liguori
2012-10-09 14:03 ` Anthony Liguori
2012-10-09 13:56 ` Anthony Liguori
2012-10-09 13:56 ` Anthony Liguori
2012-10-09 13:56 ` Anthony Liguori
2012-10-10 3:44 ` Rusty Russell
2012-10-10 3:44 ` Rusty Russell
2012-10-10 11:37 ` Michael S. Tsirkin
2012-10-10 11:37 ` Michael S. Tsirkin
2012-10-09 21:09 ` Jamie Lokier
2012-10-09 21:09 ` [Qemu-devel] " Jamie Lokier
2012-10-10 3:44 ` Rusty Russell
2012-10-10 3:44 ` Rusty Russell
2012-10-11 0:08 ` Rusty Russell
2012-10-11 0:08 ` Rusty Russell
2012-10-11 0:08 ` Rusty Russell
2012-10-09 21:09 ` Jamie Lokier
2012-10-09 3:16 ` Rusty Russell
2012-10-09 6:33 ` Gerd Hoffmann
2012-10-09 6:33 ` Gerd Hoffmann
2012-10-09 15:26 ` Anthony Liguori
2012-10-09 15:26 ` Anthony Liguori
2012-10-09 20:24 ` Gerd Hoffmann
2012-10-09 20:24 ` Gerd Hoffmann
2012-10-10 2:54 ` Rusty Russell
2012-10-10 2:54 ` Rusty Russell
2012-10-10 2:54 ` Rusty Russell
2012-10-10 13:36 ` Anthony Liguori
2012-10-10 13:41 ` Michael S. Tsirkin
2012-10-10 13:41 ` Michael S. Tsirkin
2012-10-11 0:43 ` Rusty Russell
2012-10-11 0:43 ` Rusty Russell
2012-10-11 0:43 ` [Qemu-devel] " Rusty Russell
2012-10-09 15:26 ` Anthony Liguori
2012-10-10 8:34 ` Michael S. Tsirkin
2012-10-10 8:34 ` Michael S. Tsirkin
2012-10-08 13:58 ` Anthony Liguori
2012-10-10 8:30 ` Michael S. Tsirkin
2012-10-10 8:30 ` [Qemu-devel] " Michael S. Tsirkin
2012-10-11 1:18 ` Rusty Russell
2012-10-11 1:18 ` [Qemu-devel] " Rusty Russell
2012-10-11 10:23 ` Michael S. Tsirkin
2012-10-11 10:23 ` [Qemu-devel] " Michael S. Tsirkin
2012-10-11 22:29 ` Rusty Russell
2012-10-11 22:29 ` [Qemu-devel] " Rusty Russell
2012-10-12 9:33 ` Michael S. Tsirkin
2012-10-12 9:33 ` [Qemu-devel] " Michael S. Tsirkin
2012-10-12 9:51 ` Rusty Russell
2012-10-12 9:51 ` [Qemu-devel] " Rusty Russell
2012-10-12 10:02 ` Michael S. Tsirkin
2012-10-12 10:02 ` [Qemu-devel] " Michael S. Tsirkin
2012-10-16 13:15 ` Rusty Russell
2012-10-16 13:15 ` Rusty Russell
2012-10-16 13:15 ` [Qemu-devel] " Rusty Russell
2012-10-16 13:30 ` Michael S. Tsirkin
2012-10-16 13:30 ` [Qemu-devel] " Michael S. Tsirkin
2012-10-16 13:52 ` Rusty Russell
2012-10-16 13:52 ` Rusty Russell
2012-10-16 13:52 ` [Qemu-devel] " Rusty Russell
2012-10-11 22:29 ` Rusty Russell
2012-10-04 18:49 ` [Qemu-devel] Proposal for virtio standardization Anthony Liguori
2012-10-09 14:02 ` Cornelia Huck
2012-10-09 14:02 ` Cornelia Huck
2012-10-09 14:02 ` [Qemu-devel] " Cornelia Huck
2012-10-10 3:46 ` Rusty Russell
2012-10-10 3:46 ` [Qemu-devel] " Rusty Russell
2012-10-10 3:46 ` Rusty Russell
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=87sj9o8qn7.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=aliguori@us.ibm.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtualization@lists.linux-foundation.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.