> -----Original Message----- > From: Julien Grall [mailto:[email protected]] > Sent: 06 September 2018 18:28 > To: Andrew Cooper <[email protected]>; Paul Durrant > <[email protected]>; Xen-devel <[email protected]> > Cc: Jan Beulich <[email protected]>; Wei Liu <[email protected]>; Roger > Pau Monne <[email protected]>; Stefano Stabellini > <[email protected]> > Subject: Re: [PATCH 3/5] x86/hvm: Make > HVM_PARAM_{STORE,CONSOLE}_EVTCHN read-only to the guest > > > > On 06/09/18 16:29, Andrew Cooper wrote: > > On 06/09/18 10:16, Paul Durrant wrote: > >>> -----Original Message----- > >>> From: Andrew Cooper [mailto:[email protected]] > >>> Sent: 05 September 2018 19:12 > >>> To: Xen-devel <[email protected]> > >>> Cc: Andrew Cooper <[email protected]>; Jan Beulich > >>> <[email protected]>; Wei Liu <[email protected]>; Roger Pau Monne > >>> <[email protected]>; Paul Durrant <[email protected]>; > Stefano > >>> Stabellini <[email protected]>; Julien Grall <[email protected]> > >>> Subject: [PATCH 3/5] x86/hvm: Make > >>> HVM_PARAM_{STORE,CONSOLE}_EVTCHN read-only to the guest > >>> > >>> These values are set by the toolstack for each create/restore operation, > and > >>> bound by xen{store,console}d before the the guest starts running. > >>> > >>> A guest has no reason to modify them at all, and the matching *_PFN > >>> parameters > >>> are already read-only. Adjust the *_EVTCHN permissions to be > consistent. > >> Unfortunately this patch will break the Windows PV driver function here: > >> > >> > http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenbus.git;a=blob;f=src/x > enbus/evtchn.c;hb=HEAD#l1037 > >> > >> Unfortunately the values really do change across a reset. It would be > possible to use volatile (disappear on reboot) registry keys to store the > updated values instead but I don't really see any harm in allowing the guest > to update the values to be correct, unless we want to change Xen to do the > job so the guest doesn't have to go through this dance. > > > > :( Everything is terrible. > > > > This is a general problem, not x86 specific, so I'll drop this patch and > > make a similar adjustment to the ARM one. > > I am a bit confused. I would have thought this was updated by the > toolstack at reset. So why would the guest update them? >
The problem comes when establishing the evtchn ABI. In the Windows case, when the XENBUS driver loads, it will establish the ABI )which is FIFO by default but can be overridden to 2-level). The XENBUS driver can be manually unloaded and re-loaded (e.g. for upgrade purposes) so it is also necessary to tear down the ABI during unload. This means it is necessary to go through an event channel reset operation, and this has the side-effect of tearing down the store and console event channels which were established by the toolstack before the guest started to boot. It is therefore necessary for the guest, prior to requesting the reset, to query the store and console event channels to get information about the remote domain and port and then, after reset, perform an interdomain bind operation to re-establish the channels. When the guest goes through this dance there is no guarantee that it will get the same local port number for each of the channels is it had previously. Thus, either the information has to be stored somewhere locally such that a new instantiation of the XENBUS driver can find it (e.g. a volatile registry key) or the HVM param needs to be updated to match reality. HTH, Paul > Cheers, > > -- > Julien Grall _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
