[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac4c7e15-2715-b889-9ae5-42b3c5baa332@oracle.com>
Date: Thu, 30 Nov 2017 10:23:17 -0800
From: Maran Wilson <maran.wilson@...cle.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Roger Pau Monné <roger.pau@...rix.com>,
Juergen Gross <jgross@...e.com>
Cc: tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
x86@...nel.org, xen-devel@...ts.xenproject.org,
linux-kernel@...r.kernel.org, rkrcmar@...hat.com,
JBeulich@...e.com, andrew.cooper3@...rix.com, kvm@...r.kernel.org
Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point
On 11/29/2017 6:44 AM, Paolo Bonzini wrote:
> I actually like this patch, except that I'd get the e820 memory map from
> fw_cfg (see the first part of
> https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820
> inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the
> second module.
Hi Paolo,
I want to make sure I understand exactly what you are suggesting...
Are you saying the Linux PVH entry code (such as init_pvh_bootparams())
should use the fw_cfg interface to read the e820 memory map data and put
it into the zeropage? Basically, keeping the patch very much like it
already is, just extracting the e820 data via the fw_cfg interface
instead of from the second module of start_info struct?
If that is the case, I guess I'm a bit hesitant to throw the QEMU
specific fw_cfg interface into the mix on the Linux PVH side when the
existing PVH ABI already seems to contain an interface for passing
modules/blobs to the guest. But if you feel there is a compelling reason
to use the fw_cfg interface here, I'm happy to explore that approach
further.
Thanks,
-Maran
Powered by blists - more mailing lists