On Tue, 2021-01-05 at 12:11 +0000, Joao Martins wrote: > On 1/1/21 2:33 PM, David Woodhouse wrote: > > What it does actually mean in the short term is that as I update your > > KVM_IRQ_ROUTING_XEN_EVTCHN support, I probably *won't* bother to add a > > 'priority' field to struct kvm_irq_routing_xen_evtchn to make it > > extensible to FIFO event channels. We can always add that later. > > > > Does that seem reasonable? > > > > Yes, makes sense IMHO. Guests need to anyway fallback to 2L if the > evtchnop_init_control hypercall fails, and the way we are handling events, > doesn't warrant FIFO event channel support as mandatory. Right. I think it's perfectly OK to declare that we aren't going to support FIFO event channel acceleration in Linux/KVM, and anyone who really wants to support them would have to do it entirely in userspace. The only reason a VMM would really need to support FIFO event channels is if we're insane enough to want to do live migration from actual Xen, of guests which were previously using them. While I make no comment about my mental state, I can happily observe that I don't have guests which currently use FIFO support.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
