This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 4 of 5] libxl: Add support for passing in the mac

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 4 of 5] libxl: Add support for passing in the machine's E820 for PCI passthrough
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 8 Apr 2011 15:00:08 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 08 Apr 2011 07:03:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110408133335.GE6189@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <patchbomb.1302207921@xxxxxxxxxxxxxxxxxxxxxxx> <2e464234c94cfd29a98a.1302207925@xxxxxxxxxxxxxxxxxxxxxxx> <1302251805.27835.61.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110408133335.GE6189@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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...


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>