Xen devel - Sep 2009 - Size limit on extra argument to xm create

Experimentally there seems to be a 1024 byte limit on the size of the 
extra parameter to xm create (shades of csh!).

Before I dig in to the code, I''m thought I''d check if this a
limit in xm
or a more fundamental limit in the Xen guest interface. I can imagine a 
hard limit of a page in the latter case, but that would be a lot better 
than 1024.

Thanks
Mick



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/ 9/09 08:49 PM, Mick Jordan wrote:
> Experimentally there seems to be a 1024 byte limit on the size of the 
> extra parameter to xm create (shades of csh!).
>
> Before I dig in to the code, I''m thought I''d check if
this a limit in
> xm or a more fundamental limit in the Xen guest interface. I can 
> imagine a hard limit of a page in the latter case, but that would be a 
> lot better than 1024.
Ha, so funny, the problem was actually the csh limit. xm works fine when 
spawned from bash.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/ 9/09 08:49 PM, Mick Jordan wrote:
> Experimentally there seems to be a 1024 byte limit on the size of the 
> extra parameter to xm create (shades of csh!).
>
> Before I dig in to the code, I''m thought I''d check if
this a limit in
> xm or a more fundamental limit in the Xen guest interface. I can 
> imagine a hard limit of a page in the latter case, but that would be a 
> lot better than 1024.
I was too hasty in attributing this to problems with shell variable 
length limits. There does seem to be a Xen limit of 1024 characters for 
the "extra" argument to "xm create", as shown below. The
cmd_line value
passed to the guest is truncated at 1024. So  my question above holds.

# xm create -c xmconfigs/domain_config_generic 
extra="-XX:+UseVirtualMemory -cp /guestvm/image/GuestVM/bin 
test.java.lang.ArgsTest really_quite_a_long_argument_1 
really_quite_a_long_argument_2 really_quite_a_long_argument_3 
really_quite_a_long_argument_4 really_quite_a_long_argument_5 
really_quite_a_long_argument_6 really_quite_a_long_argument_7 
really_quite_a_long_argument_8 really_quite_a_long_argument_9 
really_quite_a_long_argument_10 really_quite_a_long_argument_11 
really_quite_a_long_argument_12 really_quite_a_long_argument_13 
really_quite_a_long_argument_14 really_quite_a_long_argument_15 
really_quite_a_long_argument_16 really_quite_a_long_argument_17 
really_quite_a_long_argument_18 really_quite_a_long_argument_19 
really_quite_a_long_argument_20 really_quite_a_long_argument_21 
really_quite_a_long_argument_22 really_quite_a_long_argument_23 
really_quite_a_long_argument_24 really_quite_a_long_argument_25 
really_quite_a_long_argument_26 really_quite_a_long_argument_27 
really_quite_a_long_argument_28 really_quite_a_long_argument_29 
really_quite_a_long_argument_30 really_quite_a_long_argument_40 
really_quite_a_long_argument_41 really_quite_a_long_argument_42 
really_quite_a_long_argument_43 really_quite_a_long_argument_44 
really_quite_a_long_argument_45 really_quite_a_long_argument_46 
really_quite_a_long_argument_47 really_quite_a_long_argument_48 
really_quite_a_long_argument_49 really_quite_a_long_argument_50 
really_quite_a_long_argument_51 really_quite_a_long_argument_52 
really_quite_a_long_argument_53 really_quite_a_long_argument_54 
really_quite_a_long_argument_55 really_quite_a_long_argument_56 
really_quite_a_long_argument_57 really_quite_a_long_argument_58 
really_quite_a_long_argument_59 really_quite_a_long_argument_60"

Using config file "./xmconfigs/domain_config_generic".
Started domain GuestVM-mjj
argc 35
  0 GuestVM-mjj
  1 -XX:+UseVirtualMemory
  2 -cp
  3 /guestvm/image/GuestVM/bin
  4 test.java.lang.ArgsTest
  5 really_quite_a_long_argument_1
  6 really_quite_a_long_argument_2
  7 really_quite_a_long_argument_3
  8 really_quite_a_long_argument_4
  9 really_quite_a_long_argument_5
  10 really_quite_a_long_argument_6
  11 really_quite_a_long_argument_7
  12 really_quite_a_long_argument_8
  13 really_quite_a_long_argument_9
  14 really_quite_a_long_argument_10
  15 really_quite_a_long_argument_11
  16 really_quite_a_long_argument_12
  17 really_quite_a_long_argument_13
  18 really_quite_a_long_argument_14
  19 really_quite_a_long_argument_15
  20 really_quite_a_long_argument_16
  21 really_quite_a_long_argument_17
  22 really_quite_a_long_argument_18
  23 really_quite_a_long_argument_19
  24 really_quite_a_long_argument_20
  25 really_quite_a_long_argument_21
  26 really_quite_a_long_argument_22
  27 really_quite_a_long_argument_23
  28 really_quite_a_long_argument_24
  29 really_quite_a_long_argument_25
  30 really_quite_a_long_argument_26
  31 really_quite_a_long_argument_27
  32 really_quite_a_long_argument_28
  33 really_quite_a_long_argument_29
  34 really_quite_a_long_argumen
#


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/10/2009 20:57, "Mick Jordan" <Mick.Jordan@Sun.COM> wrote:
>> Before I dig in to the code, I''m thought I''d check if
this a limit in
>> xm or a more fundamental limit in the Xen guest interface. I can
>> imagine a hard limit of a page in the latter case, but that would be a
>> lot better than 1024.
> I was too hasty in attributing this to problems with shell variable
> length limits. There does seem to be a Xen limit of 1024 characters for
> the "extra" argument to "xm create", as shown below.
The cmd_line value
> passed to the guest is truncated at 1024. So  my question above holds.
xen/include/public/xen.h:MAX_GUEST_CMDLINE should answer your question.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/ 9/09 01:31 PM, Keir Fraser wrote:
> xen/include/public/xen.h:MAX_GUEST_CMDLINE should answer your question.
>
>   
Well it confirms the limit of 1024. So, if I recompiled Xen with, say, 
MAX_GUEST_CMDLINE=4096, would it "just work", or are there other
issues?
Of course, I really don''t want a custom version of Xen, so it would be 
good if this value was increased in the standard build.

In passing I noticed the reference to "initial ram disk" in the image.
Where can I find out more about this?

Mick


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Since it''s baked into the guest ABI, it''s not expandable.
It''s rather likely
you''ll have to live with only 1024 characters of boot parameters: the
horror!

The initial ram disk is just an ''module'' you can load into
guest memory for
interpretation by the guest kernel as it loads. Convention is to load it
into RAM immediately after the guest kernel, and place its address and size
into the mod_start/mod_len fields of start_info.

 -- Keir

On 09/10/2009 23:32, "Mick Jordan" <Mick.Jordan@Sun.COM> wrote:
> On 10/ 9/09 01:31 PM, Keir Fraser wrote:
>> xen/include/public/xen.h:MAX_GUEST_CMDLINE should answer your question.
>> 
>>   
> Well it confirms the limit of 1024. So, if I recompiled Xen with, say,
> MAX_GUEST_CMDLINE=4096, would it "just work", or are there other
issues?
> Of course, I really don''t want a custom version of Xen, so it
would be
> good if this value was increased in the standard build.
> 
> In passing I noticed the reference to "initial ram disk" in the
image.
> Where can I find out more about this?
> 
> Mick
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/ 9/09 11:30 PM, Keir Fraser wrote:
> Since it''s baked into the guest ABI, it''s not expandable.
It''s rather likely
> you''ll have to live with only 1024 characters of boot parameters:
the
> horror!
>   
I realize that 1024 seems large enough for a traditional OS. In my Java 
Virtual Machine guest, I am faced with some applications that issue very 
large command lines, certainly in excess of 1024. There are workarounds, 
but it means I can''t run certain apps out of the
box.
> The initial ram disk is just an ''module'' you can load
into guest memory for
> interpretation by the guest kernel as it loads. Convention is to load it
> into RAM immediately after the guest kernel, and place its address and size
> into the mod_start/mod_len fields of start_info.
>   
I assume this is specified via the "ramdisk" configuration file
option?

Mick


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 12/10/2009 18:05, "Mick Jordan" <Mick.Jordan@Sun.COM> wrote:
> On 10/ 9/09 11:30 PM, Keir Fraser wrote:
>> Since it''s baked into the guest ABI, it''s not
expandable. It''s rather likely
>> you''ll have to live with only 1024 characters of boot
parameters: the
>> horror!
>>   
> I realize that 1024 seems large enough for a traditional OS. In my Java
> Virtual Machine guest, I am faced with some applications that issue very
> large command lines, certainly in excess of 1024. There are workarounds,
> but it means I can''t run certain apps out of the box.
>> The initial ram disk is just an ''module'' you can load
into guest memory for
>> interpretation by the guest kernel as it loads. Convention is to load
it
>> into RAM immediately after the guest kernel, and place its address and
size
>> into the mod_start/mod_len fields of start_info.
>>   
> I assume this is specified via the "ramdisk" configuration file
option?
Yeah, so for example you can (ab)use the ramdisk option by writing your
super-long command line into a file, and then specify that file as a
ramdisk. And have a convention that your Java VM interprets a ramdisk as a
command line. You can stick whatever you like in that ramdisk file, and it
can be pretty much as big as you like.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel