[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Questions on ARM PVH



On Mon, 2013-04-15 at 10:32 +0100, Sander Bogaert wrote:
> Hi,
> 
> I went over ( and listened to ) the presentations on PVH ( Linaro
> Connect, Xen Summit,... ), read up on the ARM v7a virtualization
> extensions, Xen,... but I still have a few questions. I was hoping
> someone could answer some of them.
> 
> * The ARM PVH mode doesn't make use of pvops anymore. It does make use
> of PV interfaces for IO. These interfaces, are they the blkback driver
> and such? So the kernel doesn't user hypercalls anymore except for
> those part, it's all trap & emulate ( using the syndrome registers ),
> correct? Does the Xen ARM PVH port still support all the hypercalls (
> if they aren't used )?

pvops is an x86 Linux term which refers to the infrastructure on that
architecture for selecting platform functionality (e.g. hypervisor vs
baremetal) at boot time (strictly it's a loosely related set of
infrastructure and interfaces more than a single monolithic thing).

PVH is also an x86 specific term (an operating mode which uses PV
interfaces + hardware acceleration) although it is roughly analogous to
the Xen on ARM way of doing things (which doesn't have a specific term,
its just the only type of guest).

With that bit of pedantry out of the way:

Xen on ARM does still use hypercalls for some things, e.g. event
channels and grant table operations which as you have noted are used to
provide PV I/O interfaces (blkif, netif etc). Hypercalls are made using
the explicit hvc instruction. The hypervisor only supports the
hypercalls which are actually used (e.g. we don't and will never support
the PV MMU related calls). We may add in support for other hypercalls as
the need arises. You can see which ones are currently wired up in
xen/arch/arm/traps.c:arm_hypercall_table.

Since Xen on ARM is a mixture of hardware features and software
paravirtualisation we do also trap some other stuff and emulate it,
mostly CP register accesses etc.

> * Since there is no ARM port of miniOS yet, what would be the best way
> to experiment with hypercalls, privcmd? Is the privcmd interface the
> only way to do this from userspace?

privcmd or patching the kernel is your best bet. Yes privcmd is the only
way to do this from userspace. You should probably use the libxenctrl
library where possible instead of going at the ioctl directly.

> * Using the vgic to inject from the hypervisor, event channels are
> still used for 'interrupts' between domains right?

Yes. We use a hybrid model where physical hardware interrupts are
injected using the GICs virtualisation extensions and event channels use
the existing event channel software interrupt model.

The difference with x86 PV event channels is that the initial upcall is
done via a virtualised GIC interrupt on ARM instead of a software upcall
as on x86.

> * The port doesn't support the new System MMU yet I read. How does the
> DMA work at the moment? Wouldn't there be a need to translate the
> device addresses?

Yes, there is/will be. Platforms like the vexpress and the models don't
have devices which do DMA (or at least not ones anyone has tried).

On platforms such as the Arndale which do I believe people are working
around the current lack of MMU support by mapping dom0 1-1. Obviously we
need some sort of proper IOMMU support ASAP, it's on the TODO[1] FWIW...

[1] http://wiki.xen.org/wiki/Xen_ARM_TODO#IOMMU_support_in_Xen

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.