Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

 -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, March 22, 2012 7:26 AM
> To: Keir Fraser
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian Campbell; Ross Philipson
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> Hi,
> 
> At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote:
> > My impression from the earlier discussions is that we're pasing
> > largish blobs of binary BIOS goop around, which aren't suitable to go
> > into xenstore.  Dropping them in memory where HVMloader can pick them
> > up seems reasonable.
> >
> > All the control-path stuff - what the blobs are, where they are &c,
> > should go through Xenstore, though.
> 
> So having looked at the code, I think the module system is really
> overkill - AIUI all the things you're talking about passing through are
> ACPI tables, which have their own length fields internally. So all

Ok well fair enough. I can go back and do it again, making something smaller. 
For the record, I am passing in more than just ACPI tables; I am passing in 
parts of the SMBIOS tables. Each of the SMBIOS types does not actually report 
its length but rather you have to parse them for the double terminator after 
the string section. I guess it seems a shame to have to do that parse logic in 
two places.

> you'd need to do is have a type code and an address in xenstore
> somewhere, the same way we pass a type code and a string for the other
> BIOS customizations.
> 

So I am not exactly sure how to proceed here since libxc seems the correct 
place to load the individual blobs (ACPI tables, SMBIOS junk) but libxc seems 
too low level to be writing values to xenstore (and it does not do that at 
present). Would it be better to have a peer API to xc_hvm_build() that write 
the chunks and returns the addresses where it loaded them? Or should it be 
totally moved out of libxc? Advice would be appreciated...

Finally, I had made this a generic framework because I thought it could be 
extended in the future to pass in other types of firmware-ish blobs at runtime. 
It also handles the case where the passing of one set of tables/blobs is not 
tied to passing another set. E.g. in our work we pass in some static ACPI 
tables to satisfy one feature and construct/pass-in an SSDT to satisfy another 
unrelated feature.

> Cheers,
> 
> Tim.

Thanks
Ross






_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel