All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: virtualization@lists.linux-foundation.org
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	KVM list <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: virtio PCI on KVM without IO BARs
Date: Tue, 05 Mar 2013 23:14:31 -0800	[thread overview]
Message-ID: <5136ECD7.3020501@zytor.com> (raw)
In-Reply-To: <5136882C.8040700@zytor.com>

On 03/05/2013 04:05 PM, H. Peter Anvin wrote:
> On 02/28/2013 07:24 AM, Michael S. Tsirkin wrote:
>>
>> 3. hypervisor assigned IO address
>> 	qemu can reserve IO addresses and assign to virtio devices.
>> 	2 bytes per device (for notification and ISR access) will be
>> 	enough. So we can reserve 4K and this gets us 2000 devices.
>>         From KVM perspective, nothing changes.
>> 	We'll want some capability in the device to let guest know
>> 	this is what it should do, and pass the io address.
>> 	One way to reserve the addresses is by using the bridge.
>> 	Pros: no need for host kernel support
>> 	Pros: regular PIO so fast
>> 	Cons: does not help assigned devices, breaks nested virt
>>
>> Simply counting pros/cons, option 3 seems best. It's also the
>> easiest to implement.
>>
> 
> The problem here is the 4K I/O window for IO device BARs in bridges.
> Why not simply add a (possibly proprietary) capability to the PCI bridge
> to allow a much narrower window?  That fits much more nicely into the
> device resource assignment on the guest side, and could even be
> implemented on a real hardware device -- we can offer it to the PCI-SIG
> for standardization, even.
> 

Just a correction: I'm of course not talking about BARs but of the
bridge windows.  The BARs are not a problem; an I/O BAR can cover as
little as four bytes.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

  reply	other threads:[~2013-03-06  7:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-28 15:24 virtio PCI on KVM without IO BARs Michael S. Tsirkin
2013-02-28 15:43 ` Jan Kiszka
2013-02-28 15:43 ` Jan Kiszka
2013-03-04 22:01 ` Marcelo Tosatti
2013-03-06  0:05 ` H. Peter Anvin
2013-03-06  7:14   ` H. Peter Anvin [this message]
2013-03-06  9:21     ` Michael S. Tsirkin
2013-03-06 11:15       ` H. Peter Anvin
2013-03-06 12:02         ` Michael S. Tsirkin
2013-04-29 14:48 ` Don Dutile
2013-04-29 23:03   ` H. Peter Anvin

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=5136ECD7.3020501@zytor.com \
    --to=hpa@zytor.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --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.