On 1/10/19 11:58 AM, Paul Durrant wrote:
-----Original Message-----
Why re-invent the wheel here? The ioreq infrastructure already does
pretty much everything you need AFAICT.
Paul
I wanted preseve as much as possible from the existing vm_event DOMCTL
interface and add only the necessary code to allocate and map the
vm_event_pages.
That means we have two subsystems duplicating a lot of functionality
though. It would be much better to use ioreq server if possible than
provide a compatibility interface via DOMCTL.
Just to clarify the compatibility issue: there's a third element between
Xen and the introspection application, the Linux kernel which needs to
be fairly recent for the whole ioreq machinery to work. The qemu code
also seems to fallback to the old way of working if that's the case.
Tht'a corrent. For IOREQ server there is a fall-back mechanism when privcmd
doesn't support resource mapping.
This means that there's a choice to be made here: either we keep
backwards compatibility with the old vm_event interface (in which case
we can't drop the waitqueue code), or we switch to the new one and leave
older setups in the dust (but there's less code duplication and we can
get rid of the waitqueue code).
I don't know what your compatibility model is. QEMU needs to maintain
compatibility across various different versions of Xen and Linux so there are
many shims and much compat code. You may not need this.
Our current model is: deploy a special guest (that we call a SVA - short
for security virtual appliance), with its own kernel and applications,
that for all intents and purposes will act dom0-like.
So in that scenario, we control the guest kernel so backwards
compatibility for the case where the kernel does not support the proper
ioctl is not a priority. That said, it might very well be an issue for
someone, and we'd like to be well-behaved citizens and not inconvenience
other vm_event consumers. Tamas, is this something you'd be concerned about?
What we do care about is being able to fallback in the case where the
host hypervisor does not know anything about the new ioreq
infrastructure. IOW, nobody can stop a client from running a Xen
4.7-based XenServer on top of which our introspection guest will not be
able to use the new ioreq code even if it's using the latest kernel. But
that can be done at application level and would not require
hypervisor-level backwards compatibility support (whereas in the first
case - an old kernel - it would).
On top of all of this there's Andrew's concern of being able to get rid
of the current vm_event waitqueue code that's making migration brittle.
So, if I understand the situation correctly, we need to negotiate the
following:
1. Should we try to switch to the ioreq infrastructure for vm_event or
use our custom one? If I'm remembering things correctly, Paul and Jan
are for it, Andrew is somewhat against it, Tamas has not expressed a
preference.
2. However we approach the new code, should we or should we not also
provide a backwards compatibility layer in the hypervisor? We don't need
it, but somebody might and it's probably not a good idea to design based
entirely on the needs of one use-case. Tamas may have different needs
here, and maybe other members of the xen-devel community as well. Andrew
prefers that we don't since that removes the waitqueue code.
To reiterate how this got started: we want to move the ring buffer
memory from the guest to the hypervisor (we've had cases of OSes
reclaiming that page after the first introspection application exit),
and we want to make that memory bigger (so that more events will fit
into it, carrying more information (bigger events)). That's essentially
all we're after.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel