Re: [Xen-devel] [PATCH 3/5] x86/hvm: Make HVM_PARAM_{STORE, CONSOLE}_EVTCHN read-only to the guest

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxx]
> Sent: 06 September 2018 18:28
> To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Paul Durrant
> <Paul.Durrant@xxxxxxxxxx>; Xen-devel <xen-devel@xxxxxxxxxxxxx>
> Cc: Jan Beulich <JBeulich@xxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Roger
> Pau Monne <roger.pau@xxxxxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>
> 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:andrew.cooper3@xxxxxxxxxx]
> >>> Sent: 05 September 2018 19:12
> >>> To: Xen-devel <xen-devel@xxxxxxxxxxxxx>
> >>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Jan Beulich
> >>> <JBeulich@xxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Roger Pau Monne
> >>> <roger.pau@xxxxxxxxxx>; Paul Durrant <Paul.Durrant@xxxxxxxxxx>;
> Stefano
> >>> Stabellini <sstabellini@xxxxxxxxxx>; Julien Grall <julien.grall@xxxxxxx>
> >>> 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel