On Saturday, October 15, 2016 2:30 AM, Paolo Bonzini wrote:
> On Friday, October 14, 2016 6:51:53 PM, Wei W Wang"
> <wei.w.wang@xxxxxxxxx> wrote:
> > When it comes to the "guest virtio<-->guest virtio" notification case,
> > it should be clear where the interrupt should go to (e.g. which
> > specific device interrupt it is), rather than just trapping to the
> > host. So, instead of simply trapping to the host by an MMIO write,
> > hypercall gives us the flexibility to pass some parameters.
>
> What parameters do you need? There is no difference between "which specific
> device interrupt you are raising" and "which specific virtqueue you are kicking".
> The latter uses ioeventfd just fine, and VFIO also uses eventfd successfully.
We need two parameters: destination UUID and GSI, to identify the destination VM and the destination queue interrupt.
Please let me elaborate on the two possible solutions based on the existing eventfd mechanism and the new hypercall mechanism - how can we use them to achieve the notification from virtio1 driver to virtio2 driver (across world contexts). We can't directly deliver interrupts from virtio1 driver to virtio2 driver, so here, for both solutions, we need a trampoline - the host. A uuid field is necessary to be added to the kvm struct, so that the trampoline can know who is who.
Generally, two steps are needed:
Step1: virtio1's driver sends the interrupt request to the trampoline;
Step2: the trampoline sends the interrupt request to virtio2's driver.
*Solution 1. eventfd
Step1: achieved by virtio1's ioeventfd;
Step2: achieved by virtio2's irqfd.
In the setup phase, the trampoline makes a connection between virtio1's ioeventfd and virtio2's irqfd. So, in this solution, we would need a host kernel module to do the trampoline work - connection setup and interrupt request delivery.
*Solution 2. hypercall
Step1: achieved by hypercall
Step2: achieved by interrupt injection with GSI
We only need to patch the hypercall handler to inject the interrupt to the destination.
Pros & Cons:
>From the performance point of view, the eventfd solution has a much longer code path (if we go through the whole code path how they are handled), which results in longer latency.
>From the design point of view, I think using hypercall makes the design simple and straightforward.
> > The GSI number is assigned in QEMU. By making use of the traditional
> > irqfd implementation code in QEMU, a virtq's GSI is stored in the
> > irqfd struct - "VirtIOIRQFD->virq", we can pass it or them(the
> > multi-queue case) to the sender. I prefer GSI, because the KVM irq routing
> table is indexed by GSI.
> > Would this be acceptable?
> > Alternatively, we can pass the vector of the virtq.
>
> No, the hypercall will not be accepted in any form. The established protocols
> for communication between KVM and the outside world, including other KVM
> instances, are MMIO write and irqfd.
Could you please give more details about why hypercall is not welcomed, given the fact that it has already been implemented in KVM for some usages? Thanks.
Best,
Wei
��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
