All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hollis Blanchard <hollisb@us.ibm.com>
To: kvm-ia64@vger.kernel.org
Subject: Re: dynamic virtio page size
Date: Thu, 06 Nov 2008 23:27:54 +0000	[thread overview]
Message-ID: <1226014074.8620.69.camel@localhost.localdomain> (raw)

On Thu, 2008-11-06 at 14:02 -0600, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > I wanted to make sure people on non-x86 architectures couldn't run into
> > vring-size related problems that didn't also appear on x86.
> >   
> 
> Having a VRING_SHIFT and a VRING_PAGE_SIZE where VRING_PAGE_SIZE != (1 
> << VRING_SHIFT) is almost certainly going to break things in unexpected 
> ways because it's going against common understanding of the relationship 
> between shift and page_size.

In the patch I sent, they are named VIRTIO_PFN_SHIFT and
VRING_PAGE_SIZE. In fact, the first could really be named
VIRTIO_PCI_PFN_SHIFT or even more specific, which hopefully would
alleviate the confusion.

Anyways, I've been trying to implement your other idea, which was to
advertise a "virtio page size" from the host to the guest. Since the
virtio IO space is only 20 bytes long, and it's full, we need to offer a
feature bit to notify the guest that the IO space has been expanded. 

       virtio's PCI IO resource
------------------------------------
|    20 bytes    |                 |
------------------------------------
   virtio-pci       virtio-<device>
    specific          specific
      data              data

If guests don't acknowledge the feature, the host pretends the
VIRTIO_PAGE_SIZE register (which would be the new IO offset 20) doesn't
exist, and reads to offset 20 instead return the device-specific config
data.

Problem: the guest has not yet acknowledged the advertised features
before accessing device-specific data. So in the virtio-blk/virtio-pci
case, virtio_dev_probe() calls virtblk_probe() *before*
vp_finalize_features(). virtblk_probe() uses virtio_config_val(), which
returns the wrong data because the new yet unknown feature flag is still
set. (Of course, we can't just fix the ordering guest-side, because that
breaks backwards compatibility.)

It seems to me that virtio-pci configuration is not very flexible. I
think I'm going to continue revising the hardcoded page size patches I
sent earlier...

-- 
Hollis Blanchard
IBM Linux Technology Center


WARNING: multiple messages have this Message-ID (diff)
From: Hollis Blanchard <hollisb@us.ibm.com>
To: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
Cc: rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: dynamic virtio page size
Date: Thu, 06 Nov 2008 23:27:54 +0000	[thread overview]
Message-ID: <1226014074.8620.69.camel@localhost.localdomain> (raw)
In-Reply-To: <49134D42.6080109-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>

On Thu, 2008-11-06 at 14:02 -0600, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > I wanted to make sure people on non-x86 architectures couldn't run into
> > vring-size related problems that didn't also appear on x86.
> >   
> 
> Having a VRING_SHIFT and a VRING_PAGE_SIZE where VRING_PAGE_SIZE != (1 
> << VRING_SHIFT) is almost certainly going to break things in unexpected 
> ways because it's going against common understanding of the relationship 
> between shift and page_size.

In the patch I sent, they are named VIRTIO_PFN_SHIFT and
VRING_PAGE_SIZE. In fact, the first could really be named
VIRTIO_PCI_PFN_SHIFT or even more specific, which hopefully would
alleviate the confusion.

Anyways, I've been trying to implement your other idea, which was to
advertise a "virtio page size" from the host to the guest. Since the
virtio IO space is only 20 bytes long, and it's full, we need to offer a
feature bit to notify the guest that the IO space has been expanded. 

       virtio's PCI IO resource
------------------------------------
|    20 bytes    |                 |
------------------------------------
   virtio-pci       virtio-<device>
    specific          specific
      data              data

If guests don't acknowledge the feature, the host pretends the
VIRTIO_PAGE_SIZE register (which would be the new IO offset 20) doesn't
exist, and reads to offset 20 instead return the device-specific config
data.

Problem: the guest has not yet acknowledged the advertised features
before accessing device-specific data. So in the virtio-blk/virtio-pci
case, virtio_dev_probe() calls virtblk_probe() *before*
vp_finalize_features(). virtblk_probe() uses virtio_config_val(), which
returns the wrong data because the new yet unknown feature flag is still
set. (Of course, we can't just fix the ordering guest-side, because that
breaks backwards compatibility.)

It seems to me that virtio-pci configuration is not very flexible. I
think I'm going to continue revising the hardcoded page size patches I
sent earlier...

-- 
Hollis Blanchard
IBM Linux Technology Center


WARNING: multiple messages have this Message-ID (diff)
From: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
Cc: rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: dynamic virtio page size
Date: Thu, 06 Nov 2008 17:27:54 -0600	[thread overview]
Message-ID: <1226014074.8620.69.camel@localhost.localdomain> (raw)
In-Reply-To: <49134D42.6080109-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>

On Thu, 2008-11-06 at 14:02 -0600, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > I wanted to make sure people on non-x86 architectures couldn't run into
> > vring-size related problems that didn't also appear on x86.
> >   
> 
> Having a VRING_SHIFT and a VRING_PAGE_SIZE where VRING_PAGE_SIZE != (1 
> << VRING_SHIFT) is almost certainly going to break things in unexpected 
> ways because it's going against common understanding of the relationship 
> between shift and page_size.

In the patch I sent, they are named VIRTIO_PFN_SHIFT and
VRING_PAGE_SIZE. In fact, the first could really be named
VIRTIO_PCI_PFN_SHIFT or even more specific, which hopefully would
alleviate the confusion.

Anyways, I've been trying to implement your other idea, which was to
advertise a "virtio page size" from the host to the guest. Since the
virtio IO space is only 20 bytes long, and it's full, we need to offer a
feature bit to notify the guest that the IO space has been expanded. 

       virtio's PCI IO resource
------------------------------------
|    20 bytes    |                 |
------------------------------------
   virtio-pci       virtio-<device>
    specific          specific
      data              data

If guests don't acknowledge the feature, the host pretends the
VIRTIO_PAGE_SIZE register (which would be the new IO offset 20) doesn't
exist, and reads to offset 20 instead return the device-specific config
data.

Problem: the guest has not yet acknowledged the advertised features
before accessing device-specific data. So in the virtio-blk/virtio-pci
case, virtio_dev_probe() calls virtblk_probe() *before*
vp_finalize_features(). virtblk_probe() uses virtio_config_val(), which
returns the wrong data because the new yet unknown feature flag is still
set. (Of course, we can't just fix the ordering guest-side, because that
breaks backwards compatibility.)

It seems to me that virtio-pci configuration is not very flexible. I
think I'm going to continue revising the hardcoded page size patches I
sent earlier...

-- 
Hollis Blanchard
IBM Linux Technology Center

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2008-11-06 23:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06 23:27 Hollis Blanchard [this message]
2008-11-06 23:27 ` dynamic virtio page size Hollis Blanchard
2008-11-06 23:27 ` Hollis Blanchard
2008-11-06 23:32 ` Hollis Blanchard
2008-11-06 23:32   ` Hollis Blanchard
2008-11-06 23:32   ` Hollis Blanchard
  -- strict thread matches above, loose matches on Subject: below --
2008-11-06 10:54 [PATCH] qemu: define and use VIRTIO_PFN_SHIFT Mark McLoughlin
2008-11-06 10:54 ` Mark McLoughlin
2008-11-06 10:54 ` Mark McLoughlin
2008-11-06 14:01 ` Anthony Liguori
2008-11-06 14:01   ` Anthony Liguori
2008-11-06 14:01   ` Anthony Liguori
2008-11-06 19:02 ` Hollis Blanchard
2008-11-06 19:02   ` Hollis Blanchard
2008-11-06 19:02   ` Hollis Blanchard
2008-11-06 20:02 ` Anthony Liguori
2008-11-06 20:02   ` Anthony Liguori
2008-11-06 20:02   ` Anthony Liguori
2008-11-07  1:38 ` Zhang, Xiantao
2008-11-07  1:38   ` Zhang, Xiantao
2008-11-07  1:38   ` Zhang, Xiantao
2008-11-07  5:05 ` Hollis Blanchard
2008-11-07  5:05   ` Hollis Blanchard
2008-11-07  5:05   ` Hollis Blanchard
2008-11-10  5:55 ` Zhang, Xiantao
2008-11-10  5:55   ` Zhang, Xiantao
2008-11-10  5:55   ` Zhang, Xiantao
2008-11-06  4:49 Hollis Blanchard

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=1226014074.8620.69.camel@localhost.localdomain \
    --to=hollisb@us.ibm.com \
    --cc=kvm-ia64@vger.kernel.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.