Re: [RFC] OVMF on PVH

From: Wei Liu <wei.liu2@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: "Wei Liu" <wei.liu2@citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Ian Jackson" <ian.jackson@citrix.com>,
	xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [RFC] OVMF on PVH
Date: Thu, 9 Aug 2018 10:07:36 +0100	[thread overview]
Message-ID: <20180809090736.5k57ujv6xriny6yo@citrix.com> (raw)
In-Reply-To: <20180808150209.GV1327@perard.uk.xensource.com>

On Wed, Aug 08, 2018 at 04:02:09PM +0100, Anthony PERARD wrote:
> > But long term we might want to support VarStore (that is used to stored
> > config, right?). How are we going to do that in the future if we
> > repurpose it now?
> 
> So, normally on QEMU/KVM, in order to use this VarStore, libvirt (or
> user) would add two flash device to qemu, one which gives access to this
> VarStore that a guest can write to it (and so would be baked by a file
> in the host), and the second flash device would be the rest of OVMF, all
> its code.
> 
> In Xen, we only ever load the sum of both, and I think hvmloader might
> not work if the OVMF blob is smaller than expected (meaning the
> toolstack load ovmf without the VarStore so it can attach to QEMU
> instead).
> 
> I think that VarStore is just a placeholder anyway, in the current
> binary.

OK. I think I understand better now. I'm fine with repurposing the
in-binary VarStore for something else, because if we really want to
support it we should expose another flash device to the guest just like
KVM does.

> 
> > If you specify the virt_addr (?) in the ELF header, libxc should know
> > how to deal with that? What is missing in the current toolstack code?
> 
> RAM.
> 
> If I set the ELF header properly so that it is written that the blob
> must be loaded in the guest RAM just below 4G, libxc will not be able to
> do anything because there is no RAM, that space is suppose to be a mem
> hole, or something like that, I forgot the exact detail :(. I think also
> that libxl would try to load other data like the startinfo page past the
> kernel (OVMF here) and that would mean past 4G.
> 
> (In my notes from when I tried, I've written "libxc will not move ram
> like hvmloader would; [and with >4G for the guest] libxc can not map
> anything past 0xfee00000, and I want 0xffe00000", whatever that mean,
> can find out where I found that 0xfee00000 address.)
> 
> Anyway, it didn't make sense to be to move the RAM around for some
> code/data that is only use very early and never used again. And it seams
> easier to have initial blob somewhere else rather trying to teach libxc
> about this weirdness.
> 

OK. This makes sense.

Wei.

> Thanks,
> 
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel