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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 20 Dec 2016, Bhupinder Thakur wrote:
> Hi Stefano,
> 
> Thanks for a detailed explanation. I have some queries.
> 
> > Let me explain how the PV console protocol and drivers work, because
> > they are a bit unusual. The first PV console is advertised via
> > hvm_params. The guest calls:
> >
> >   hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> >   hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> >
> In drivers/tty/hvc/hvc_xen.c, I see that there are two console init
> functions - xen_hvm_console_init () and xen_pv_console_init () and
> either of them are called based on the xen_domain_type(). Can you
> clarify which init () is called in which case?

Good question. x86 Xen has two different types of guests, PV guests and
HVM guests. In Linux, many code paths depend on whether a guest is PV
or HVM. However, on ARM we only have one kind of guest which is neither
PV or HVM. In this case, initialization on ARM follows the HVM path, so
xen_hvm_console_init is the one that is called. It isn't always the case
though. Feel free to ask (or add a printk) if you are in doubt.


> > to get the two parameters to setup the ring and evtchn. If they are 0,
> > the guest considers the first console unavailable. Other PV console
> > rings, from the second onward, are advertised via xenstore like any
> > other Xen PV protocols. In those cases, frontend and backend access
> > xenstore to setup ring and event channel.
> >
> > The PV console backends are unusual too. xenconsoled, available on all
> > Xen systems, is one process per host and can handle only one PV console
> > per domain. Specifically, it is only able to deal with the first console.
> > Domains that have multiple PV consoles require QEMU (not as an emulator,
> > but as a PV backends provider). The toolstack writes "type" =
> > "xenconsoled" or "ioemu" to distinguish PV consoles that xenconsoled or
> > QEMU are supposed to handle. Ideally, we shouldn't require QEMU for
> > pl011 PV consoles, but it wouldn't be the end of the world if we did.
> >
> > Additionally, Xen cannot speak xenstore. It can neither read nor write
> > to it. I don't think we should add xenstore support to the hypervisor
> > for this. We need to come up with a solution that doesn't require it.
> >
> > 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
> 
> I see that that there are xen events which can be allocated
> (alloc_unbound_xen_event_channel ()). Should I use those kind of
> events or just allocate a new event for each VM (similar to how the
> console event channel is allocated) and intercept and process them in
> the Xen HYP?

You need to allocate a new event channel for the PV console. In fact, it
should be exactly like any other event channels for consoles.


> > 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.
> >
> There is a function alloc_magic_pages () (defined in
> tools/libxc/xc_dom_arm.c), where the console PFN and event channel are
> allocated for a new domain. So can I allocate a new PFN and the event
> channel here for pl011?

That is what I was thinking.


> > 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.
> > 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.
> >
> This looks fine. We can add new hvm_params to communicate the PFN and
> the event channel for Xen to use. These hvm_params can be called from
> alloc_magic_pages().

That is the idea.


> > However, the PV console backend can access xenstore, so in that case, it
> > is fine to write the pfn and evtchn of the PV console for pl011 to
> > xenstore, paying attention at using the xenstore permissions
> > appropriately. There are no reasons why the guest should have access to
> > them; only the console backend should be able to read them. Given that
> > the console backend has dom0 privileges, it is not a problem. I also
> > suggest using new xenstore nodes, different from any of the existing PV
> > console nodes.  For example:
> >
> > /local/domain/$DOMID/xen-console/$NUM/ring-ref
> > /local/domain/$DOMID/xen-console/$NUM/port
> >
> > Where $DOMID is the guest domain id, and $NUM is the console number,
> > starting from 0. If we use new hvm_parms for the pl011 PV console, we
> > might get away without any xenstore stuff.
> >
> > For simplicity, given that xenconsoled doesn't support multiple PV
> > consoles, we could setup the pl011 PV console *instead* of the regular
> > PV console, hacking tools/console/daemon/io.c:domain_create_ring. It's
> > safe if the toolstack doesn't provide a PV console. When pl011 is
> > requested, libxl could set the pfn and evtchn hvm_params to 0 for the
> > initial PV console. Eventually, it would be nice if xenconsoled was able
> > to support both consoles at the same time.
> 
> Is domain_create_ring() responsible for setting up the ring and the
> event channel for the first PV console?

tools/console/daemon/io.c:domain_create_ring is a xenconsoled function.
xenconsoled is the PV console backend. This function sets up the ring
from the backend point view, which means mapping the page and binding
the event channel. It doesn't do any allocations.


> This function seems to refer
> to xenstore for getting the shared page reference and the remote port.
> Is this the same shared page which was set by libxl using hvm_param
> for pfn (for guest to access).

That's right. It is the same.

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