On 19.07.2019 19:40, Petre Ovidiu PIRCALABU wrote: > 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. > > 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
And validly so (imo), not the least because of also being HVM specific. > 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. By "wouldn't introduce" do you mean "wouldn't want to introduce" or do you mean to say you in fact wouldn't and I'm not seeing why that is? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
