On Fri, 2011-04-08 at 14:33 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 08, 2011 at 09:36:45AM +0100, Ian Campbell wrote:
> > On Thu, 2011-04-07 at 21:25 +0100, Konrad Rzeszutek Wilk wrote:
> > > +typedef struct {
> > > + uint32_t nr_entries;
> > > + struct e820entry *entry;
> > > +} libxl_e820;
> >
> > BTW does the e820entry array need to be packed at some point before
> > getting returned to the guest? (I'm not sure what the expected alignment
>
> The struct e820entry has the __packed__ attribute on it.
OK, so you might end up with the unpacked version in the libxl getting
repacked into the xc version internally to libxl for consumption by
libxc, which is annoying but better than exposing these things to libxl
users, IMHO.
> > is, nor how a 20 byte struct containing two u64s and a u32 naturally
> > aligns on x86_64).
>
> It seems to work OK.. (I booted a 32-bit guest under a 64-bit hypervisor
> with a 64-bit dom0).
If the libxc version of the struct is __packed__ it'll do the right
thing, so that's good.
> > Are we expecting that libxl users might want to modify the e820? If not
> > then why expose libxl_e820_alloc and libxl_e820_sanitize at all, just
> > add a flag to the libxl interface which says whether or not to provide a
> > host-derived e820.
>
> OK. Where should I put the definitions of these two functions? (They are
> called from libxl_dom.c and xl_cmdimpl.c) Is there a internal header file?
libxl_internal.h is the internal hdr although that isn't available to
xl_cmdimpl.c, obviously, but I think we are talking about not having
this call in xl anyway.
> > If users are expected to modify it then I'm in two minds about doing the
> > sanitize step at domain build time instead of in libxl_e820_alloc. If we
>
> The issue I had was that to construct the e820, I needed the
> 'target_kb' and 'max_memkb' and 'slack_memkb'. If I can get those two values
> when the guest config file is parsed (so xl_cmdimpl.c) I think moving
> the sanitization in there (and not doing it during domain build time)
> is the right thing to do. Let me see if I can do that.
>
> > provide a default sanitized e820 to the caller and they want to modify
> > it to be non-santized should we let them? I guess the question here is
> > whether we are sanitizing actually invalid e820 maps or if we are also
> > enforcing some higher level policy based on a specific class Linux
> > guest's requirements.
>
> Which might be quite different if the guest is a BSD one. I guess
> it is time to start launching those NetBSD guests :-)
Yeah ... I'm perpetually trying (and failing) to find a minute to try
that again...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home