[Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Daniel P. Berrange]

From: "Daniel P. Berrange" <berrange@redhat.com>

The Linux guest kernel does not appear to have a problem handling
a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
though perhaps it can be made larger still, or not limited at all ?

Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.

* hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
---
 hw/9pfs/virtio-9p.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 17d44b4..b133b33 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -144,7 +144,7 @@ struct V9fsPDU
 /* The ID for virtio console */
 #define VIRTIO_ID_9P    9
 #define MAX_REQ         128
-#define MAX_TAG_LEN     32
+#define MAX_TAG_LEN     255
 
 #define BUG_ON(cond) assert(!(cond))
 
-- 
1.7.6.2

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Aneesh Kumar K.V]

On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> From: "Daniel P. Berrange" <berrange@redhat.com>
> 
> The Linux guest kernel does not appear to have a problem handling
> a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
> though perhaps it can be made larger still, or not limited at all ?
> 
> Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.
> 
> * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255


mount_tag is passed via pci config space, do we want to have 255 bytes
out of that for device identification. Is this change driven by 
the virt-manager UI where we specify source and target directory for
file system ?. I would like to understand how that target
directory is used in case of other user like NFS ?. If this is something
used to get automout (I am not sure how we drive such an automount) of
those mounts points, then it should be ok for VirtFS to generate mount tag internally
which will fit 32 byte limit and use the target directory for
automounting the mount point using the internally generated mount tag


> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
>  hw/9pfs/virtio-9p.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
> index 17d44b4..b133b33 100644
> --- a/hw/9pfs/virtio-9p.h
> +++ b/hw/9pfs/virtio-9p.h
> @@ -144,7 +144,7 @@ struct V9fsPDU
>  /* The ID for virtio console */
>  #define VIRTIO_ID_9P    9
>  #define MAX_REQ         128
> -#define MAX_TAG_LEN     32
> +#define MAX_TAG_LEN     255
> 
>  #define BUG_ON(cond) assert(!(cond))
> 

-aneesh

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Daniel P. Berrange]

On Thu, Sep 29, 2011 at 08:23:49PM +0530, Aneesh Kumar K.V wrote:
> On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > From: "Daniel P. Berrange" <berrange@redhat.com>
> > 
> > The Linux guest kernel does not appear to have a problem handling
> > a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
> > though perhaps it can be made larger still, or not limited at all ?
> > 
> > Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.
> > 
> > * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255
> 
> 
> mount_tag is passed via pci config space, do we want to have 255 bytes
> out of that for device identification.

How big is the config space available for each 9pfs device and what
other info does it need to keep there ?

>                                        Is this change driven by 
> the virt-manager UI where we specify source and target directory for
> file system ?. I would like to understand how that target
> directory is used in case of other user like NFS ?. If this is something
> used to get automout (I am not sure how we drive such an automount) of
> those mounts points, then it should be ok for VirtFS to generate mount tag internally
> which will fit 32 byte limit and use the target directory for
> automounting the mount point using the internally generated mount tag

There's no virt-manager involved in what I'm working on. It is a tiny
app with KVM embedded behind the scenes. All that runs inside the virtual
machine is a minature 'init' process which mounts any 9pfs filesystems
it finds, creates some device nodes, and then runs the application bianry.
The 'init' code does not have any knowledge of where the 9pfs filesystems
need to be mounted, that info must come from the host, because it can
vary on each boot.

I don't want to have to pass separate 'mount_tag'; -> 'mount point'
mapping data through to the guest via a side-channel. I just want to
put the target mount point path, directly in the mount tag.

Originally I was trying to namespace my mount tags

   org.virttools.dir:/mount/point/path

but this hit the 32 byte limit almost immediately, so now I just
put the raw '/mount/point/path' in each mount tag.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Daniel P. Berrange]

On Thu, Sep 29, 2011 at 04:22:16PM +0100, Daniel P. Berrange wrote:
> On Thu, Sep 29, 2011 at 08:23:49PM +0530, Aneesh Kumar K.V wrote:
> > On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > > From: "Daniel P. Berrange" <berrange@redhat.com>
> > > 
> > > The Linux guest kernel does not appear to have a problem handling
> > > a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
> > > though perhaps it can be made larger still, or not limited at all ?
> > > 
> > > Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.
> > > 
> > > * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255
> > 
> > 
> > mount_tag is passed via pci config space, do we want to have 255 bytes
> > out of that for device identification.
> 
> How big is the config space available for each 9pfs device and what
> other info does it need to keep there ?

Does anyone have an clear answer for this ?

I've done some tests with ever larger mount tags, and managed to increase
the MAX_TAG_LEN value to 1023  before I started getting guest failures.

So if the config space is really 1023 bytes in size, it doesn't seem too
unrealistic to allow 255 bytes of it for the mount_tag, or at the very
least increase it from 32 to 128 ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Aneesh Kumar K.V]

On Fri, 7 Oct 2011 10:27:56 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> On Thu, Sep 29, 2011 at 04:22:16PM +0100, Daniel P. Berrange wrote:
> > On Thu, Sep 29, 2011 at 08:23:49PM +0530, Aneesh Kumar K.V wrote:
> > > On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > > > From: "Daniel P. Berrange" <berrange@redhat.com>
> > > > 
> > > > The Linux guest kernel does not appear to have a problem handling
> > > > a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
> > > > though perhaps it can be made larger still, or not limited at all ?
> > > > 
> > > > Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.
> > > > 
> > > > * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255
> > > 
> > > 
> > > mount_tag is passed via pci config space, do we want to have 255 bytes
> > > out of that for device identification.
> > 
> > How big is the config space available for each 9pfs device and what
> > other info does it need to keep there ?
> 
> Does anyone have an clear answer for this ?
> 
> I've done some tests with ever larger mount tags, and managed to increase
> the MAX_TAG_LEN value to 1023  before I started getting guest failures.
> 
> So if the config space is really 1023 bytes in size, it doesn't seem too
> unrealistic to allow 255 bytes of it for the mount_tag, or at the very
> least increase it from 32 to 128 ?
> 

Last time we discussed this Anthony wanted to keep the config space
usage minimal, hence we agreed on the size 32 bytes. 

Anthony,

Any comments ?

-aneesh

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Daniel P. Berrange]

On Fri, Oct 07, 2011 at 04:49:13PM +0530, Aneesh Kumar K.V wrote:
> On Fri, 7 Oct 2011 10:27:56 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > On Thu, Sep 29, 2011 at 04:22:16PM +0100, Daniel P. Berrange wrote:
> > > On Thu, Sep 29, 2011 at 08:23:49PM +0530, Aneesh Kumar K.V wrote:
> > > > On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > > > > From: "Daniel P. Berrange" <berrange@redhat.com>
> > > > > 
> > > > > The Linux guest kernel does not appear to have a problem handling
> > > > > a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
> > > > > though perhaps it can be made larger still, or not limited at all ?
> > > > > 
> > > > > Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.
> > > > > 
> > > > > * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255
> > > > 
> > > > 
> > > > mount_tag is passed via pci config space, do we want to have 255 bytes
> > > > out of that for device identification.
> > > 
> > > How big is the config space available for each 9pfs device and what
> > > other info does it need to keep there ?
> > 
> > Does anyone have an clear answer for this ?
> > 
> > I've done some tests with ever larger mount tags, and managed to increase
> > the MAX_TAG_LEN value to 1023  before I started getting guest failures.
> > 
> > So if the config space is really 1023 bytes in size, it doesn't seem too
> > unrealistic to allow 255 bytes of it for the mount_tag, or at the very
> > least increase it from 32 to 128 ?
> > 
> 
> Last time we discussed this Anthony wanted to keep the config space
> usage minimal, hence we agreed on the size 32 bytes. 

Ping ? Anyone ....

Does anyone have any clear information about the per-device config
space we have available ?  As above I'd really like us to raise
the mount_tag length even just a little bit higher for QEMU 1.0,
if we have the PCI config space available to play with.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Anthony Liguori]

On 10/20/2011 10:13 AM, Daniel P. Berrange wrote:
> On Fri, Oct 07, 2011 at 04:49:13PM +0530, Aneesh Kumar K.V wrote:
>> On Fri, 7 Oct 2011 10:27:56 +0100, "Daniel P. Berrange"<berrange@redhat.com>  wrote:
>>> On Thu, Sep 29, 2011 at 04:22:16PM +0100, Daniel P. Berrange wrote:
>>>> On Thu, Sep 29, 2011 at 08:23:49PM +0530, Aneesh Kumar K.V wrote:
>>>>> On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange"<berrange@redhat.com>  wrote:
>>>>>> From: "Daniel P. Berrange"<berrange@redhat.com>
>>>>>>
>>>>>> The Linux guest kernel does not appear to have a problem handling
>>>>>> a mount_tag larger than 32 bytes. Increase the limit to 255 bytes,
>>>>>> though perhaps it can be made larger still, or not limited at all ?
>>>>>>
>>>>>> Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length.
>>>>>>
>>>>>> * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255
>>>>>
>>>>>
>>>>> mount_tag is passed via pci config space, do we want to have 255 bytes
>>>>> out of that for device identification.
>>>>
>>>> How big is the config space available for each 9pfs device and what
>>>> other info does it need to keep there ?
>>>
>>> Does anyone have an clear answer for this ?
>>>
>>> I've done some tests with ever larger mount tags, and managed to increase
>>> the MAX_TAG_LEN value to 1023  before I started getting guest failures.
>>>
>>> So if the config space is really 1023 bytes in size, it doesn't seem too
>>> unrealistic to allow 255 bytes of it for the mount_tag, or at the very
>>> least increase it from 32 to 128 ?
>>>
>>
>> Last time we discussed this Anthony wanted to keep the config space
>> usage minimal, hence we agreed on the size 32 bytes.
>
> Ping ? Anyone ....
>
> Does anyone have any clear information about the per-device config
> space we have available ?  As above I'd really like us to raise
> the mount_tag length even just a little bit higher for QEMU 1.0,
> if we have the PCI config space available to play with.

Yes, PCI PIO space is very small.  I think 128 is even pushing it.

Why not add a feature that exchanges the tag through another mechanism such that 
there doesn't need to be a limit?  It could be as simple as adding an fsstat .L 
operation or something like that.

Regards,

Anthony Liguori

>
> Regards,
> Daniel

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Daniel P. Berrange]

On Tue, Nov 01, 2011 at 01:27:56PM -0500, Anthony Liguori wrote:
> On 10/20/2011 10:13 AM, Daniel P. Berrange wrote:
> >On Fri, Oct 07, 2011 at 04:49:13PM +0530, Aneesh Kumar K.V wrote:
> >>On Fri, 7 Oct 2011 10:27:56 +0100, "Daniel P. Berrange"<berrange@redhat.com>  wrote:
> >>>On Thu, Sep 29, 2011 at 04:22:16PM +0100, Daniel P. Berrange wrote:
> >>>I've done some tests with ever larger mount tags, and managed to increase
> >>>the MAX_TAG_LEN value to 1023  before I started getting guest failures.
> >>>
> >>>So if the config space is really 1023 bytes in size, it doesn't seem too
> >>>unrealistic to allow 255 bytes of it for the mount_tag, or at the very
> >>>least increase it from 32 to 128 ?
> >>>
> >>
> >>Last time we discussed this Anthony wanted to keep the config space
> >>usage minimal, hence we agreed on the size 32 bytes.
> >
> >Ping ? Anyone ....
> >
> >Does anyone have any clear information about the per-device config
> >space we have available ?  As above I'd really like us to raise
> >the mount_tag length even just a little bit higher for QEMU 1.0,
> >if we have the PCI config space available to play with.
> 
> Yes, PCI PIO space is very small.  I think 128 is even pushing it.

Odd, because I managed to pass through a 1023 byte path without
appearing to have any trouble. Is the space per-device, or global
to all devices. If the latter, I could understand the desire to
keep it smaller.

> Why not add a feature that exchanges the tag through another
> mechanism such that there doesn't need to be a limit?  It could be
> as simple as adding an fsstat .L operation or something like that.

That would require kernel side updates too I presume, so if that
kind of change is the only option, I think I'll just have to change
my app's code to cope with the current smaller limits for now.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes

[Anthony Liguori]

On 11/01/2011 01:48 PM, Daniel P. Berrange wrote:
> On Tue, Nov 01, 2011 at 01:27:56PM -0500, Anthony Liguori wrote:
>> On 10/20/2011 10:13 AM, Daniel P. Berrange wrote:
>>> On Fri, Oct 07, 2011 at 04:49:13PM +0530, Aneesh Kumar K.V wrote:
>>>> On Fri, 7 Oct 2011 10:27:56 +0100, "Daniel P. Berrange"<berrange@redhat.com>   wrote:
>>>>> On Thu, Sep 29, 2011 at 04:22:16PM +0100, Daniel P. Berrange wrote:
>>>>> I've done some tests with ever larger mount tags, and managed to increase
>>>>> the MAX_TAG_LEN value to 1023  before I started getting guest failures.
>>>>>
>>>>> So if the config space is really 1023 bytes in size, it doesn't seem too
>>>>> unrealistic to allow 255 bytes of it for the mount_tag, or at the very
>>>>> least increase it from 32 to 128 ?
>>>>>
>>>>
>>>> Last time we discussed this Anthony wanted to keep the config space
>>>> usage minimal, hence we agreed on the size 32 bytes.
>>>
>>> Ping ? Anyone ....
>>>
>>> Does anyone have any clear information about the per-device config
>>> space we have available ?  As above I'd really like us to raise
>>> the mount_tag length even just a little bit higher for QEMU 1.0,
>>> if we have the PCI config space available to play with.
>>
>> Yes, PCI PIO space is very small.  I think 128 is even pushing it.
>
> Odd, because I managed to pass through a 1023 byte path without
> appearing to have any trouble. Is the space per-device, or global
> to all devices. If the latter, I could understand the desire to
> keep it smaller.

It's global so it ends up being a problem when you have many devices.

>
>> Why not add a feature that exchanges the tag through another
>> mechanism such that there doesn't need to be a limit?  It could be
>> as simple as adding an fsstat .L operation or something like that.
>
> That would require kernel side updates too I presume, so if that
> kind of change is the only option, I think I'll just have to change
> my app's code to cope with the current smaller limits for now.

Right.

Regards,

Anthony Liguori

>
> Regards,
> Daniel