On Wed, Feb 28, 2018 at 05:17:23PM +0800, Haozhong Zhang wrote:
> On 02/27/18 17:37 +0000, Anthony PERARD wrote:
> > On Thu, Dec 07, 2017 at 06:10:22PM +0800, Haozhong Zhang wrote:
> > > Add a function in libacpi to detect QEMU fw_cfg interface. Limit the
> > > usage of fw_cfg interface to hvmloader now, so use stub functions for
> > > others.
> > I think libacpi is not the right place for a driver. The fw_cfg driver
> > would be better in hvmloader.
> Yes, I can move it to hvmloader. My original thought was it might be
> reused (by replacing those stub functions) when someone wants to add
> vNVDIMM support to PVH domU and still use QEMU as the device model
> for vNVDIMM.
:(, I don't see how the fw_cfg drivers could be reuse in a PVH guest,
right now. It is only usefull when runned from inside the guest. So far,
I think libacpi is use in Xen, maybe libxl and hvmloader.
If QEMU's fw_cfg was available within a PVH guest, I guess we could use
hvmloader, or teach OVMF to merge the tables from Xen and QEMU, or maybe
GRUB or Linux could learn about fw_cfg.
Anyway, I think for now, the fw_cfg drivers is better in hvmloader, and
we can move the code later if/when needed.
> > As to copy the ACPI tables from fw_cfg to libacpi, maybe the passthrough
> > tables (or an improvement of it) could be use. (It is already to to add
> > extra tables from libxl (HVM_XS_ACPI_PT_ADDRESS).)
> They are doing the same job (transferring guest ACPI from host to
> guest) in two quite different ways, rather than two pieces of jobs not
> completely overlap, so I think it's hard to let them collaborate with
> each other. Do you have any idea in mind?
I don't really have an idea in mind. I guess it is going to depends of
what libacpi have to do, once the fw_cfg drivers have done the jobs of
loading the ACPI tables in memory.
Xen-devel mailing list