On Fri, 2019-07-19 at 12:59 +0000, Jan Beulich wrote: > On 19.07.2019 14:37, Paul Durrant wrote: > > > From: Jan Beulich <jbeul...@suse.com> > > > Sent: 19 July 2019 13:32 > > > > > > On 19.07.2019 14:11, Paul Durrant wrote: > > > > > -----Original Message----- > > > > > From: Petre Ovidiu PIRCALABU <ppircal...@bitdefender.com> > > > > > Sent: 19 July 2019 12:24 > > > > > > > > > > Sorry, my mistake. I meant to say it's shared with MD. > > > > > > > > > > Many thanks for your support, > > > > > > > > Ok, in that case please share with the ID instead. > > > > > > But that's exactly what we want to avoid: If sharing at all, then > > > please with the more privileged entity. > > > > Why? We're talking HVM guests only here IIUC so this is equivalent > > to IOREQ server... > > Not sure: The main vm_event.c files live in common/ and arch/x86/ > respectively, so I thought at least architecturally VM events were > possible for PV as well. If it's indeed HVM-only, then following > the IOREQ server model in its entirety would of course be fine. > > Jan
In one of the previous version of the patchset there was a suggestion to implement the new vm_event transport using IOREQ, but it was dropped . https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg00173.html Also, unless there isn't a proper way allocate the necessary pages, I wouldn't introduce a HVM-only limitation because, other than the HVM param used to keep track of the ring pfn, the vm_event mechanism is quite generic. Many thanks for your support, Petre _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
