Re: Xen ARM - Exposing a PL011 to the guest

[Christoffer Dall <christoffer.dall@linaro.org>]

On Fri, Dec 16, 2016 at 05:03:13PM +0000, Julien Grall wrote:
> (CC rest maintainers for event channel questions)
> 
> On 16/12/16 10:06, Bhupinder Thakur wrote:
> >Hi,
> 
> Hi Bhupinder,
> 
> >The idea is for Xen to act as an intermediary as shown below:
> >
> >               ring buffers
> >                           rx/tx fifo
> >dom0 <-------------------> Xen HYP (running pl011 emulation)
> ><-------------------> domU
> >                    event
> >                           interrupts
> >
> >Xen will directly manage the in/out console ring buffers (allocated by
> >dom0 for dom0-domU console communication) for reading/writing console
> >data from/to dom0. On the other side, Xen HYP will emulate pl011 to
> >read/write data from/to domU and pass it on to/from dom0 over the
> >in/out console ring buffers. There should be no change in dom0 as it
> >will still use the same ring buffers. Similarly there should be no
> >change in domU which would be running a standard pll011 driver.
> >
> >Currently, I am working on the interface between dom0 and Xen HYP. I
> >want to intercept the console events in Xen HYP which pass between
> >dom0 and domU. For now, I just want to capture console data coming
> >from dom0 at Xen HYP and loop it back to dom0, to confirm that this
> >interface is working.
> >
> >Since each guest domain will have a unique event channel assigned for
> >console communication, Xen HYP can find out the event channel for a
> >given domU from the start_info page of that domU, which should have
> 
> The start_info page is x86 specific. If you want to get the console
> event channel for ARM, you would have to use
> d->arch.hvm_domain.params[HVM_PARAM_CONSOLE_EVTCHN].
> 
> This parameter will be setup by the toolstack (see alloc_magic_pages
> in libxc/xc_dom_arm.c).
> 
> >been allocated by dom0. Whenever, an event is to be dispatched via
> >evtchn_send() API in Xen, it can check if the event channel is the
> >console event channel for a given domU. If yes and its source domain
> >is dom0 and destination domain is domU then it will write the data
> >back to the console out ring buffer of the domU and raise a console
> >event to dom0.
> >
> >Once this interface is working, Xen HYP can check the source and
> >destination dom ids and decide which way the event came from and
> >accordingly process the console data. To allow a mix of PV console
> >guests and pl011 guests, Xen might have to maintain a flag per domain,
> >which tells whether Xen HYP should intercept and process the data (for
> >pl011 UART case) or let it go transparently (for PV conosle case).
> 
> I am not very familiar with the event channel code. I will let the
> others comment on this bit.
> 
> Regardless that, how would you decide whether the hypervisor should
> intercept the notification?
> 
> I can see 2 different cases:
> 	1) The guest is starting to use the pl011 then move to the HVC
> console (or HVC then pl011)
> 	2) The guest is using both the PL011 and the HVC console
> 
> Should we consider the second case valid? I would say yes, because a
> user could specify both on the command line. If we use the same
> ring, the output would be a total garbage.
> 
> So maybe we need to allocate two distinct rings and event channel?

This sounds like the only sensible thing to me.  I think this is really
about adding a new device to the Xen virtual platform, and providing the
user the option to choose which one he wants the tool in Dom0 to be
presented using stdin/out.  Presumably the other console/serial can be
redirected to a file or socket or something?


Thanks,
-Christoffer

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