Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 20/12/2016 20:53, Stefano Stabellini wrote:
> On Tue, 20 Dec 2016, Julien Grall wrote:
> > On 19/12/2016 21:24, Stefano Stabellini wrote:
> > > On Mon, 19 Dec 2016, Christoffer Dall wrote:
> > > > On Fri, Dec 16, 2016 at 05:03:13PM +0000, Julien Grall wrote:
> > > Finally, we cannot hijack one of the guest PV consoles, regardless of
> > > whether it's the first console or one of the others, because the guest
> > > can always try to use them at any time. We need a PV console reserved
> > > for Xen-Dom0 communications on behalf of the guest. When a VM is created
> > > with "pl011=y", the toolstack needs to allocate one more page and evtchn
> > > for the exclusive hypervisor usage.  They are not going to be advertised
> > > to the guest as PV consoles; otherwise, the guest could rightfully
> > > access them.
> > >
> > > Both Xen and the PV console backend need access to the two numbers (pfn
> > > and evtchn) though. Xen doesn't do xenstore, so I suggest the toolstack
> > > should use another way to tell pfn and evtchn to Xen, maybe hvm_params.
> > I think it will be the other way around. Xen will allocate the event channel
> > and then report to the PV backends. Very similar to what it is done for ioreq
> > server on x86 today.
> It could work that way too. Even in the ioreq case though, the ioreq
> parameters are still exposed via hvm_params (I am looking at
> include/hw/xen/xen_common.h:xen_get_default_ioreq_server_info in QEMU).
I am fine with exposing the event channel via hvm_params. My previous 
mail was more related of who is allocating the event channel.
From my understanding, any event channel between Xen and a domain 
should currently be allocated by Xen via the function 
alloc_unbound_xen_event_channel.
> > > If we use hvm_params for this, we need two new hvm_params and Xen needs
> > > to unmap the pfn from the guest immediately, because we don't want the
> > > guest to have access to it.
> > If you unmap the pfn, the PV backend will not be able to request the page
> > because there will be no translation available.
> >
> > So what you want to do is preventing the guest to at least write into region
> > (not sure if it is worth to restrict read)
> That's a good idea.
>
>
> > and unmap the page via the hypercall XENMEM_decrease_reservation.
> That would be issued by the guest itself, right? To save address space?
Correct. The main use case today is ballooning, but guest could call it 
on any other RAM baked page.
I was thinking about more about the protection needed. Technically the 
data in the ring are not trusted. So if the guest is messing up with it, 
it would not be a big issue. Or did I miss anything here?
[...]

> > IIRC, the UEFI firmware will use Xen console by default but I am not sure it
> > will fallback to the PL011 if present. So we may require some change in the
> > firmware to allow booting on different configuration (i.e PL011 guest or PV
> > console guest).
> Linux has checks to see if the pfn or evtchn are 0 and skips PV console
> initialization in those cases. Tianocores probably has the same checks
> (but I haven't read the code).
Probably, I am more concerned about Tianocore console not falling back 
on the PL011. The UEFI firmware is specifically built for Xen ARM guest, 
so I would be surprised to see a PL011 driver included.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel