From: Anthony Liguori <aliguori@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ryan Harper <ryanh@us.ibm.com>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, kvm-devel@lists.sourceforge.net,
Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [PATCH] add virtio disk geometry feature
Date: Wed, 16 Apr 2008 16:32:30 -0500 [thread overview]
Message-ID: <4806706E.10701@us.ibm.com> (raw)
In-Reply-To: <200804170715.55041.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Thursday 17 April 2008 04:56:37 Ryan Harper wrote:
>
>> From: Ryan Harper <ryanh@us.ibm.com>
>>
>> Rather than faking up some geometry, allow the backend to push the disk
>> geometry via virtio pci config option. Keep the old geo code around for
>> compatibility.
>>
>
> Hi Ryan,
>
> Looks good! Some brief review below. Mainly just "how I would have done
> things" stuff. BTW, does this help in real life? I assume something in
> userspace wants it?
>
Boot loaders (like grub) query the geometry from the kernel to figure
out how to setup the stage1/stage2. We've seen strange issues with grub
thinking it has crazy geometries when installed on a virtio disk (as
opposed to booting from virtio with an existing disk).
Ryan: have you tested a hardy install with your patches? Does it help
when installing to virtio? I could pretty reliably reproduce the
strangeness with a 20GB disk image FWIW.
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -157,10 +157,25 @@ static int virtblk_ioctl(struct inode *i
> /* We provide getgeo only to please some old bootloader/partitioning tools */
> static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo)
> {
> - /* some standard values, similar to sd */
> - geo->heads = 1 << 6;
> - geo->sectors = 1 << 5;
> - geo->cylinders = get_capacity(bd->bd_disk) >> 11;
> + struct virtio_blk *vblk = bd->bd_disk->private_data;
> + struct virtio_blk_geometry vgeo;
> + int err;
> +
> + /* see if the host passed in geometry config */
> + err = virtio_config_val(vblk->vdev, VIRTIO_BLK_F_GEOMETRY,
> + offsetof(struct virtio_blk_config, geometry),
> + &vgeo);
> +
> + if (!err) {
> + geo->heads = vgeo.heads;
> + geo->sectors = vgeo.sectors;
> + geo->cylinders = vgeo.cylinders;
> + } else {
> + /* some standard values, similar to sd */
> + geo->heads = 1 << 6;
> + geo->sectors = 1 << 5;
> + geo->cylinders = get_capacity(bd->bd_disk) >> 11;
> + }
> return 0;
> }
>
You're probably breaking PPC since the values in the config space are in
little endian format. virtio_config_val does automagic endianness
conversion if the size is 2, 4, or 8. In this case, the structure size
is 4 so the endianness conversion will do the wrong thing.
Magic endianness conversion based on read size is looking pretty evil to
me... Perhaps we need explicit *_val[8,16,32,64]?
Regards,
Anthony Liguori
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <aliguori@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: kvm-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
Hollis Blanchard <hollisb@us.ibm.com>,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] add virtio disk geometry feature
Date: Wed, 16 Apr 2008 16:32:30 -0500 [thread overview]
Message-ID: <4806706E.10701@us.ibm.com> (raw)
In-Reply-To: <200804170715.55041.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Thursday 17 April 2008 04:56:37 Ryan Harper wrote:
>
>> From: Ryan Harper <ryanh@us.ibm.com>
>>
>> Rather than faking up some geometry, allow the backend to push the disk
>> geometry via virtio pci config option. Keep the old geo code around for
>> compatibility.
>>
>
> Hi Ryan,
>
> Looks good! Some brief review below. Mainly just "how I would have done
> things" stuff. BTW, does this help in real life? I assume something in
> userspace wants it?
>
Boot loaders (like grub) query the geometry from the kernel to figure
out how to setup the stage1/stage2. We've seen strange issues with grub
thinking it has crazy geometries when installed on a virtio disk (as
opposed to booting from virtio with an existing disk).
Ryan: have you tested a hardy install with your patches? Does it help
when installing to virtio? I could pretty reliably reproduce the
strangeness with a 20GB disk image FWIW.
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -157,10 +157,25 @@ static int virtblk_ioctl(struct inode *i
> /* We provide getgeo only to please some old bootloader/partitioning tools */
> static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo)
> {
> - /* some standard values, similar to sd */
> - geo->heads = 1 << 6;
> - geo->sectors = 1 << 5;
> - geo->cylinders = get_capacity(bd->bd_disk) >> 11;
> + struct virtio_blk *vblk = bd->bd_disk->private_data;
> + struct virtio_blk_geometry vgeo;
> + int err;
> +
> + /* see if the host passed in geometry config */
> + err = virtio_config_val(vblk->vdev, VIRTIO_BLK_F_GEOMETRY,
> + offsetof(struct virtio_blk_config, geometry),
> + &vgeo);
> +
> + if (!err) {
> + geo->heads = vgeo.heads;
> + geo->sectors = vgeo.sectors;
> + geo->cylinders = vgeo.cylinders;
> + } else {
> + /* some standard values, similar to sd */
> + geo->heads = 1 << 6;
> + geo->sectors = 1 << 5;
> + geo->cylinders = get_capacity(bd->bd_disk) >> 11;
> + }
> return 0;
> }
>
You're probably breaking PPC since the values in the config space are in
little endian format. virtio_config_val does automagic endianness
conversion if the size is 2, 4, or 8. In this case, the structure size
is 4 so the endianness conversion will do the wrong thing.
Magic endianness conversion based on read size is looking pretty evil to
me... Perhaps we need explicit *_val[8,16,32,64]?
Regards,
Anthony Liguori
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
next prev parent reply other threads:[~2008-04-16 21:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-16 18:56 [PATCH] add virtio disk geometry feature Ryan Harper
2008-04-16 18:56 ` Ryan Harper
2008-04-16 21:15 ` Rusty Russell
2008-04-16 21:15 ` Rusty Russell
2008-04-16 21:15 ` Rusty Russell
2008-04-16 21:32 ` Anthony Liguori
2008-04-16 21:32 ` Anthony Liguori [this message]
2008-04-16 21:32 ` Anthony Liguori
2008-04-16 21:57 ` Hollis Blanchard
2008-04-16 21:57 ` Hollis Blanchard
2008-04-16 21:57 ` Hollis Blanchard
2008-04-17 14:37 ` Ryan Harper
2008-04-17 14:37 ` Ryan Harper
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=4806706E.10701@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=hollisb@us.ibm.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=ryanh@us.ibm.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.