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

[Julien Grall <julien.grall@xxxxxxx>]

(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?

For your testing, you could consider that the ring is only used by the 
pl011. I would recommend you to disable the HVC console driver in the 
guest (see CONFIG_HVC_XEN).
I looked at the event channel code and I can only find a function for 
xen to create an event channel (see alloc_unbound_xen_event_channel). 
But in your case, you want a function to bind an event channel.
> Is this the correct way to find out the console event channel for a
> given domU or there is some other way? I could not locate in the Xen
> source code, where exactly the start_info page is created for a new
> domain, which would contain the console event channel and and machine
> page where the ring buffers are mapped.
You can give a look to HVM_PARAM_CONSOLE_EVTCHN and 
HVM_PARAM_CONSOLE_PFN (see more details above).
Cheers,

--
Julien Grall

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