On Tue, 2022-12-13 at 23:32 +0100, Paolo Bonzini wrote: > Il mar 13 dic 2022, 01:59 David Woodhouse <dw...@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
