Re: [RFC PATCH v2 02/22] xen: add CONFIG_XENFV_MACHINE and CONFIG_XEN_EMU options for Xen emulation

[David Woodhouse]

On Tue, 2022-12-13 at 23:32 +0100, Paolo Bonzini wrote:
> Il mar 13 dic 2022, 01:59 David Woodhouse <dwmw2@infradead.org> ha scritto:
> > There was *also* a call to xen_emulated_machine_init() added to
> > pc_init1() by the 'pc_piix: handle XEN_EMULATE backend init' patch.
> > I've dropped that for now; once we are ready to hook up the xenbus and
> > PV drivers, that seems like it can go into mc->kvm_type too. Or maybe I
> > should have kept that, and initialised the overlay and evtchn devices
> > from xen_emulated_machine_init() instead of mc->kvm_type() ?
> 
> 
> I think that would be too early. mc->kvm_type, which really should be
> called mc->accel_created, is the first place where you can look at
> xen_mode.

Ack. So now I instantiate the overlay and evtchn devices from
pc_machine_kvm_type() when needed. Thanks.

I've followed the HPET example and wired up a full set of NUM_GSI_PINS
outbound IRQs, each connected to the corresponding system GSI, and fire
the one I want to according to the guest's CALLBACK_PARAM setup.

But *connecting* those had to be done later than kvm_type(), so I've
done it from pc_basic_device_init() right alongside the HPET one. It
couldn't work out how to qdev_find_recursive() the evtchn device, since
it lacks an ID. So I just called a function in xen_evtchn.c which has
access to that singleton you already told me not to worry about. 

The IRQs still concern me a little. I could have sworn that QEMU coped
with shared level IRQs, but I can't see how. It looks like each
'output' connected to a qemu_irq input gets to waggle it up and down
independently, overriding the others?

Maybe it was Xen itself that keeps a *count* of how many outputs have
asserted a given input, and each output is responsible for ensuring it
only ever contributes a count of 0 or 1 to that total?

Part of me wants to go off at a tangent and fix that in QEMU, allowing
shared level IRQs as well as the EOI-driven resampling. But December
only lasts so long before the US wakes up and remembers that you exist
in January, and I *really* want to get the Xen support to the point
where I can run XTF tests under it, at the very least...

smime.p7s
Description: S/MIME cryptographic signature