Re: [RFC PATCH v2 07/22] pc_piix: handle XEN_EMULATE backend init

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Mon, 2022-12-12 at 13:47 +0000, Paul Durrant wrote:
> 
> > @@ -155,6 +156,10 @@ static void pc_init1(MachineState *machine,
> >                x86ms->above_4g_mem_size = 0;
> >                x86ms->below_4g_mem_size = machine->ram_size;
> >            }
> > +
> > +        if (pcms->xen_version && !xen_be_xenstore_open()) {
> 
> So, this is a bit subtle... it's only *because* using real Xen results 
> in xen_version being 0 that this is sane? Also does this not mean that 
> we are now relying on libxenstore? Shouldn't that be called out in the 
> config?

None of the CONFIG_XENFV_MACHINE code builds right now unless
CONFIG_XEN is set anyway. We can move code around and use #ifdef
appropriately once the dust has settled on how the config options are
going to relate to one another; doing that too soon seemed like
pointless churn. I know I didn't *quite* do the config options the way
that Philippe said, so figured it was better to wait until we have
consensus.

As noted in the cover letter, "For now, we just need to be able to use
the xenfv machine in order to instantiate the shinfo and evtchn
objects."

So for now I've basically just stuck with what was in the original
patchset, and this is going to change.

Ideally, I'd like to avoid the external xenstore completely. We could
have a completely internal implementation which is private to the
guest. Since this isn't true Xen, the guest has no way of talking to
anything other than qemu itself, which will play the rôle of dom0.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]