From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Harsh Bora <harsh@linux.vnet.ibm.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes
Date: Tue, 1 Nov 2011 18:48:47 +0000 [thread overview]
Message-ID: <20111101184847.GM22168@redhat.com> (raw)
In-Reply-To: <4EB03A2C.8050302@us.ibm.com>
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 :|
next prev parent reply other threads:[~2011-11-01 18:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 10:34 [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes Daniel P. Berrange
2011-09-29 14:53 ` Aneesh Kumar K.V
2011-09-29 15:22 ` Daniel P. Berrange
2011-10-07 9:27 ` Daniel P. Berrange
2011-10-07 11:19 ` Aneesh Kumar K.V
2011-10-20 15:13 ` Daniel P. Berrange
2011-11-01 18:27 ` Anthony Liguori
2011-11-01 18:48 ` Daniel P. Berrange [this message]
2011-11-01 19:45 ` Anthony Liguori
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=20111101184847.GM22168@redhat.com \
--to=berrange@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=harsh@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.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.