Re: [Xen-devel] [PATCH 00/12 v3] PL011 emulation support in Xen

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

It seems there is some threading problem with the patches. I got them 
split in 4 batches in my inbox.
I can't see anything in the cover letter explaining the interaction with 
the guest. Mainly how the guest will know which console to use?
For instance, the UEFI firmware will always log on HVC console. However, 
the guest OS may only use pl011. It means that the user would have to 
first use hvc console to access UEFI and then switch to pl011 console 
once the OS boot.
This will confuse more than one user. Do you have a plan here to either 
make UEFI log on both consoles or a way to tell UEFI which one to use?
Also, how this is going to fit with ACPI? If you enable pl011, likely 
SPCR will be generated and in this case how the guest will behave?
Currently Linux is preferring HVC console over pl011. So how will it be 
prioritized?
Cheers,


On 10/05/17 15:24, Bhupinder Thakur wrote:
> PL011 emulation for guests in Xen
> ===================================
> Linaro has published VM System specification for ARM Processors, which
> provides a set of guidelines for both guest OS and hypervisor implementations,
> such that building OS images according to these guidelines guarantees
> that those images can also run on hypervisors compliant with this specification.
>
> One of the spec requirements is that the hypervisor must provide an
> emulated PL011 UART as a serial console which meets the minimum requirements in
> SBSA UART as defined in appendix B of the following ARM Server Base 
> Architecture Document:
>
> https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf.
>
> This feature allows the Xen guests to use SBSA compliant pl011 UART as
> as a console.
>
> Note that SBSA pl011 UART is a subset of full featured ARM pl011 UART and
> supports only a subset of registers as mentioned below. It does not support
> rx/tx DMA.
>
> Currently, Xen supports paravirtualized (aka PV console) and an emulated serial
> consoles. This feature will expose an emulated SBSA pl011 UART console to the
> guest, which a user can access using xenconsole.
>
> The device tree passed to the guest VM will contain the pl011 MMIO address
> range and an irq for receiving rx/tx pl011 interrupts. The device tree format
> is specified in Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt.
>
> The Xen hypervisor will expose two types of interfaces to the backend and domU.
>
> The interface exposed to domU will be an emulated pl011 UART by emulating the
> access to the following pl011 registers by the guest.
>
> - Data register (DR)            - RW
> - Raw interrupt status register (RIS)   - RO
> - Masked interrupt status register (MIS)- RO
> - Interrupt Mask (IMSC)         - RW
> - Interrupt Clear (ICR)         - WO
>
> It will also inject the pl011 interrupts to the guest in the following
> conditions:
>
> - incoming data in the rx buffer for the guest
> - there is space in the tx buffer for the guest to write more data
>
> The interface exposed to the backend will be the same PV console interface,
> which minimizes the changes required in xenconsole to support a new pl011 
> console.
>
> This interface has rx and tx ring buffers and an event channel for
> sending/receiving events from the backend.
>
> So essentially Xen handles the data on behalf of domU and the backend. Any data
> written by domU is captured by Xen and written to the TX (OUT) ring buffer
> and a pl011 event is raised to the backend to read the TX ring buffer.
>
> Similarly on reciving a pl011 event, Xen injects an interrupt to guest to
> indicate there is data available in the RX (IN) ring buffer.
>
> The pl011 UART state is completely captured in the set of registers
> mentioned above and this state is updated everytime there is an event from
> the backend or there is register read/write access from domU.
>
> For example, if domU has masked the rx interrupt in the IMSC register, then Xen
> will not inject an interrupt to guest and will just update the RIS register.
> Once the interrupt is unmasked by guest, the interrupt will be delivered to the
> guest.
>
> Changes summary:
>
> Xen Hypervisor
> ===============
>
> 1. Add emulation code to emulate read/write access to pl011 registers and pl011
>    interrupts:
>     - It emulates DR read/write by reading and writing from/to the IN and
>       OUT ring buffers and raising an event to dom0 when there is data in
>       the OUT ring buffer and injecting an interrupt to the guest when there
>       is data in the IN ring buffer.
>     - Other registers are related to interrupt management and essentially
>       control when interrupts are delivered to the guest.
>
> 2. Add two new domctl APIs to initialize and de-initialize vpl011 emulation in 
> Xen.
>
> 3. Enable vpl011 emulation for a domain based on a libxl option passed during
>    domain creation.
>
> Toolstack
> ==========
>
> 1. Add a new option "vuart" in the domU configuration file to enable/disable 
> vuart.
>
> 2. Create a SBSA UART DT node in the guest device tree. It uses a fixed
>    vpl011 SPI IRQ number and MMIO address.
>
> 3. Call vpl011 init DOMCTL API to enable vpl011 emulation.
>
> 4. Call vpl011 de-init DOMCTL API to disable vpl011 emulation.
>
> 5. Add a new vuart xenstore node, which contains:
>     - ring-ref
>     - event channel
>     - buffer limit
>     - type
>
> Xenconsoled
> ============
>
> 1. Split the domain structure to support multiple consoles.
>
> 2. Modify different APIs such as buffer_append() etc. to operate on the
>    console structure.
>
> 3. Add a new generic console_create_ring() function which maps the console GFN
>    and binds the event channel for a given console.
>
> 4. Modify domain_create_ring() to use console_create_ring() for a new console.
>
> 5. Modifications in handle_ring_read() to handle both PV and VUART
>    events.
--
Julien Grall

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