Re: [Xen-devel] [RFC] OVMF on PVH

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel