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.
smime.p7s
Description: S/MIME cryptographic signature
