Re: [Xen-devel] domU jiffies not incrementing - timer issue? - Kernel 3.18.10 on Xen 4.5.0
2015-03-30 17:56 GMT-04:00 Mark m...@overnetdata.com: Hi, I have an issue where domUs will hang at boot if CONFIG_XOR_BLOCKS is enabled. This is a PV domU on Xen which is running inside a Hyper-V virtual machine. Did you try to run Xen on native machine instead of using the nested virtualization? We have another installation (different hardware) working without any issues. Does Xen run in nested virtualization or on bare metal in this case? As far as I know, the scheduler in Xen may not be aware of the nested virtualization. I'm guessing the uncontinuous time below Xen in nested virtualization may affect the scheduling decision and then make some domU starving. But it's weird that a domU is never scheduled... (When I run Xen on virtual box, domU is slow but still running) So I'm unsure if it's the scheduler issue or not... Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] x86: add support for COS/CBM manangement
On Fri, Mar 27, 2015 at 08:16:10PM +, Andrew Cooper wrote:
On 26/03/15 12:38, Chao Peng wrote:
@@ -238,6 +450,8 @@ static void cat_cpu_init(unsigned int cpu)
ASSERT(socket nr_sockets);
info = cat_socket_info + socket;
+if ( info-socket_cpu_mask == NULL )
+info-socket_cpu_mask = per_cpu(cpu_core_mask, cpu);
Surely this wants to be skipped if info is already initialised?
The mask will be set to NULL in psr_cpu_fini() when the last CPU of the
socket is hot un-plugged. If any CPU of the socket is plugged in again
then the mask needs to be initialized but not skip.
/* Avoid initializing more than one times for the same socket. */
if ( test_and_set_bool(info-initialized) )
@@ -254,6 +468,14 @@ static void cat_cpu_init(unsigned int cpu)
info-cbm_len = (eax 0x1f) + 1;
info-cos_max = (edx 0x);
+info-cos_cbm_map = xzalloc_array(struct psr_cat_cbm,
+ info-cos_max + 1UL);
+if ( !info-cos_cbm_map )
+return;
This indicates that cat_cpu_init() needs to be able to signal ENOMEM.
The current behavior for ENOMEM case is: CAT is not enabled on the
socket. Both cat_cpu_init() and the caller will not actually make use
of this error code.
+
+/* cos=0 is reserved as default cbm(all ones). */
+info-cos_cbm_map[0].cbm = (1ull info-cbm_len) - 1;
+
info-enabled = 1;
printk(XENLOG_DEBUG CAT: enabled on socket %u, cos_max:%u,
cbm_len:%u\n,
socket, info-cos_max, info-cbm_len);
@@ -274,6 +496,24 @@ static void psr_cpu_init(unsigned int cpu)
psr_assoc_init();
}
+static void psr_cpu_fini(unsigned int cpu)
+{
+unsigned int socket, next;
+cpumask_t *cpu_mask;
+
+if ( cat_socket_info )
+{
+socket = cpu_to_socket(cpu);
+cpu_mask = cat_socket_info[socket].socket_cpu_mask;
+
+if ( (next = cpumask_cycle(cpu, cpu_mask)) == cpu )
+cat_socket_info[socket].socket_cpu_mask = NULL;
+else
+cat_socket_info[socket].socket_cpu_mask =
+per_cpu(cpu_core_mask, next);
+}
+}
+
Overall, this patch has a lot of moving parts in it. I have not spotted
any major problems, but I also don't feel confident that I understand
all of what is going on.
It would certainly be easier to review if you split the patch into at
least 3; the core infrastructure, the domctl and the sysctl bits. Even
then, there appear to be several different bits of core changes going
on, with some per-socket infrastructure and per-domain infrastructure.
OK, I will split it.
The code itself appears to attempt to deal with sockets having a
different quantity of COS entries, but how does it resolve having a
different number of entries in the COS bitmaps? This would appear to
mean that a domain given a certain COS would exhibit different behaviour
depending on which socket it happened to be scheduled on.
Hypervisor maintains per-socket COS bitmask for each domain as well. So
a domain actually has COS bitmask for each socket but not only one COS
bitmask. xen_domctl_psr_cat_op interface allows toolstack to set/get
each COS bitmask on socket basis.
Chao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 50268: tolerable FAIL - PUSHED
flight 50268 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50268/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-i386 14 guest-localmigrate/x10fail pass in 36775 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10fail pass in 36775 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail in 36775 pass in 50268 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail in 36775 pass in 50268 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 36775 like 36511 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-armhf-armhf-xl-arndale 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-startfail in 36775 never pass test-armhf-armhf-xl-midway 10 migrate-support-check fail in 36775 never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail in 36775 never pass version targeted for testing: xen 7fe1c1b28581686aca42361d4fee740c643dde1b baseline version: xen e76209d69c406ecc3518dbd0e2efa5705273fa20 People who touched revisions under test: George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com Kevin Tian kevin.t...@intel.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Roger Pau Monné roger@citrix.com Ross Lagerwall ross.lagerw...@citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass
Re: [Xen-devel] [PATCH v4 15/33] xen/arm: gic: GICv2 GICv3 only supports 1020 physical interrupts
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: GICD_TYPER.ITLinesNumber can encode up to 1024 interrupts. Although, IRQ 1020-1023 are reserved for special purpose. The result is used by the callers of gic_number_lines in order to check the validity of an IRQ. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Frediano Ziglio frediano.zig...@huawei.com Cc: Zoltan Kiss zoltan.k...@huawei.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 12/33] xen/arm: gic: Add sanity checks gic_route_irq_to_guest
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: With the addition of interrupt assignment to guest, we need to make sure the guest can't blow up the interrupt management in Xen. Before associating the IRQ to a vIRQ we need to make sure: - the vIRQ is not already associated to another IRQ - the guest didn't enable the vIRQ Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 18/33] xen/arm: Release IRQ routed to a domain when it's destroying
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: Xen has to release IRQ routed to a domain in order to reuse later. Currently only SPIs can be routed to the guest so we only need to browse SPIs for a specific domain. Furthermore, a guest can crash and let the IRQ in an incorrect state leave the irq (i.e has not being EOIed). Xen will have to reset the IRQ in order to s/being/been/ be able to reuse the IRQ later. Introduce 2 new functions for release an IRQ routed to a domain: - release_guest_irq: upper level to retrieve the IRQ, call the GIC code and release the action - gic_remove_guest_irq: Check if we can remove the IRQ, and reset it if necessary Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 20/33] xen/dts: Provide an helper to get a DT node from a path provided by a guest
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The maximum size of the copied string has been chosen based on the value use by XSM in similar case. Furthermore, Linux seems to allow path up to 4096 characters. Though this could vary from one OS to another. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 21/33] xen/passthrough: Introduce iommu_construct
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: This new function will correctly initialize the IOMMU page table for the current domain. Also use it in iommu_assign_dt_device even though the current IOMMU implementation on ARM shares P2M with the processor. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Jan Beulich jbeul...@suse.com With Jan's requested change: Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen/passthrough: Support a single iommu_domain per xen domain per SMMU
On Tue, 2015-03-24 at 16:48 -0400, Robbie VanVossen wrote: If multiple devices are being passed through to the same domain and they share a single SMMU, then they only require a single iommu_domain. In arm_smmu_assign_dev, before a new iommu_domain is created, the xen_domain-contexts is checked for any iommu_domains that are already assigned to device that uses the same SMMU as the current device. If one is found, attach the device to that iommu_domain. If a new one isn't found, create a new iommu_domain just like before. The arm_smmu_deassign_dev function assumes that there is a single device per iommu_domain. This meant that when the first device was deassigned, the iommu_domain was freed and when another device was deassigned a crash occurred in xen. To fix this, a reference counter was added to the iommu_domain struct. When an arm_smmu_xen_device references an iommu_domain, the iommu_domains ref is incremented. When that reference is removed, the iommu_domains ref is decremented. The iommu_domain will only be freed when the ref is 0. Signed-off-by: Robbie VanVossen robert.vanvos...@dornerworks.com Reviewed-by: Julien Grall julien.gr...@linaro.org I was expecting this to come back in a new version of Julien's passthrough series, but Julien prodded me to say that this patch didn't actually have any dependency/interaction with his passthrough series like I thought, so it can go in now. So Acked + applied, sorry for the delay. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 25/33] xen/xsm: Add helpers to check permission for device tree passthrough
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: This is a follow-up of commit 525ee49 xsm: add device tree labeling support which add support for device tree labelling in flask. Those helpers will be use latter when non-pci passthrough (i.e device tree) will be added. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Daniel De Graaf dgde...@tycho.nsa.gov Looks ok to me: Acked-by: Ian Campbell ian.campb...@citrix.com But I'd like to here from Daniel too. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 26/33] xen/passthrough: Extend XEN_DOMCTL_*assign_device to support DT device
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
+int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
+ XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+int ret;
+struct dt_device_node *dev;
+
+/* TODO: How to deal with XSM? */
Looks like you do in the following code? Old comment?
+/* TODO: Do we need to check is_dying? Mostly to protect against
+ * hypercall trying to passthrough a device while we are
+ * dying.
iommu_do_pci_domctl does in specific casses (i.e. assign device). I
guess you should follow that lead.
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 7f90150..a7cb272 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -475,12 +475,30 @@ typedef struct xen_domctl_sendtrigger
xen_domctl_sendtrigger_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_sendtrigger_t);
-/* Assign PCI device to HVM guest. Sets up IOMMU structures. */
+/* Assign a device to a guest. Sets up IOMMU structures. */
/* XEN_DOMCTL_assign_device */
/* XEN_DOMCTL_test_assign_device */
-/* XEN_DOMCTL_deassign_device */
+/*
+ * XEN_DOMCTL_deassign_device: The behavior of this DOMCTL differs
+ * between the different type of device:
+ * - PCI device (XEN_DOMCTL_DEV_PCI) will be reassigned to DOM0
+ * - non-PCI device (XEN_DOMCTL_DEV_PCI) will left unassigned. DOM0
Did you miss a ! before XEN_DOMCTL, or did you mean to say DT?
From an ease of review PoV it would have been nice to add dev and u.pci
first since that would be mechanical, but nevermind now.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 16/33] xen/arm: Let the toolstack configure the number of SPIs
Hi Ian,
On 31/03/15 11:54, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
@@ -68,16 +68,17 @@ static void vgic_init_pending_irq(struct pending_irq *p,
unsigned int virq)
p-irq = virq;
}
-int domain_vgic_init(struct domain *d)
+int domain_vgic_init(struct domain *d, unsigned int nr_spis)
{
int i;
d-arch.vgic.ctlr = 0;
[...]
+/* Limit the number of SPIs supported base on the hardware */
+if ( nr_spis (gic_number_lines() - NR_LOCAL_IRQS) )
+return -EINVAL;
Is there anything in the h/w which leads to this restriction?
The h/w accept an VirtualID 1020. Although, given that we can only
route a physical interrupt to the guest, it's pointless to support more
SPIs than the h/w does.
If not then I think we should just check against the architectural 1020
limit and leave it at that.
I would have to check on 988 (1020 - 32) which I find less readable.
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 9e0419e..6dacfef 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -125,6 +125,8 @@ struct arch_domain
unsigned int evtchn_irq;
} __cacheline_aligned;
+#define domain_is_configured(d) ((d)-arch.is_configured)
+
struct arch_vcpu
{
struct {
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..254cc17 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -54,6 +54,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned
long len);
void arch_get_xen_caps(xen_capabilities_info_t *info);
int construct_dom0(struct domain *d);
+int configure_dom0(struct domain *d);
Are these two hunks stray from some other patch in the series?
No. It's part of an old version of this patch and I forgot to drop it.
I will resend a new version.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/33] xen/arm: Divide GIC initialization in 2 parts
Frediano, Zoltan,
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
Note that the HIP04 GIC driver has not been modified because I don't
have a platform where I can test my changes. Although, the code is
still building.
I let the Hisilicon guys (Frediano and Zoltan) providing a suitable
patch for there platform.
Are you going to provide an update for the hip04 driver for this change?
Meanwhile, I think it can go upstream as it has been acked by both
Ian and Stefano.
Changes in v4:
- Rebase on the latest staging (no functional changes)
- Add Ian and Stefano's ack
- Typo in the commit message
Changes in v3:
- Patch was previously sent in a separate series [1]
- Reorder the function to avoid forward declaration
- Make gic-v3 driver compliant to the new interface
- Remove spurious field addition in gicv2 structure
Changelog based on the separate series:
Changes in v3:
- Patch added.
[1] https://patches.linaro.org/33313/
---
xen/arch/arm/gic-v2.c | 70 ++-
xen/arch/arm/gic-v3.c | 75
---
xen/arch/arm/gic.c| 16 --
xen/arch/arm/setup.c | 3 +-
xen/include/asm-arm/gic.h | 8 +
5 files changed, 100 insertions(+), 72 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 20cdbc9..3be4ad6 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -674,37 +674,10 @@ static hw_irq_controller gicv2_guest_irq_type = {
.set_affinity = gicv2_irq_set_affinity,
};
-const static struct gic_hw_operations gicv2_ops = {
-.info= gicv2_info,
-.secondary_init = gicv2_secondary_cpu_init,
-.save_state = gicv2_save_state,
-.restore_state = gicv2_restore_state,
-.dump_state = gicv2_dump_state,
-.gicv_setup = gicv2v_setup,
-.gic_host_irq_type = gicv2_host_irq_type,
-.gic_guest_irq_type = gicv2_guest_irq_type,
-.eoi_irq = gicv2_eoi_irq,
-.deactivate_irq = gicv2_dir_irq,
-.read_irq= gicv2_read_irq,
-.set_irq_properties = gicv2_set_irq_properties,
-.send_SGI= gicv2_send_SGI,
-.disable_interface = gicv2_disable_interface,
-.update_lr = gicv2_update_lr,
-.update_hcr_status = gicv2_hcr_status,
-.clear_lr= gicv2_clear_lr,
-.read_lr = gicv2_read_lr,
-.write_lr= gicv2_write_lr,
-.read_vmcr_priority = gicv2_read_vmcr_priority,
-.read_apr= gicv2_read_apr,
-.make_dt_node= gicv2_make_dt_node,
-};
-
-/* Set up the GIC */
-static int __init gicv2_init(struct dt_device_node *node, const void *data)
+static int __init gicv2_init(void)
{
int res;
-
-dt_device_set_used_by(node, DOMID_XEN);
+const struct dt_device_node *node = gicv2_info.node;
res = dt_device_get_address(node, 0, gicv2.dbase, NULL);
if ( res || !gicv2.dbase || (gicv2.dbase ~PAGE_MASK) )
@@ -727,9 +700,6 @@ static int __init gicv2_init(struct dt_device_node *node,
const void *data)
panic(GICv2: Cannot find the maintenance IRQ);
gicv2_info.maintenance_irq = res;
-/* Set the GIC as the primary interrupt controller */
-dt_interrupt_controller = node;
-
/* TODO: Add check on distributor, cpu size */
printk(GICv2 initialization:\n
@@ -774,8 +744,42 @@ static int __init gicv2_init(struct dt_device_node
*node, const void *data)
spin_unlock(gicv2.lock);
+return 0;
+}
+
+const static struct gic_hw_operations gicv2_ops = {
+.info= gicv2_info,
+.init= gicv2_init,
+.secondary_init = gicv2_secondary_cpu_init,
+.save_state = gicv2_save_state,
+.restore_state = gicv2_restore_state,
+.dump_state = gicv2_dump_state,
+.gicv_setup = gicv2v_setup,
+.gic_host_irq_type = gicv2_host_irq_type,
+.gic_guest_irq_type = gicv2_guest_irq_type,
+.eoi_irq = gicv2_eoi_irq,
+.deactivate_irq = gicv2_dir_irq,
+.read_irq= gicv2_read_irq,
+.set_irq_properties = gicv2_set_irq_properties,
+.send_SGI= gicv2_send_SGI,
+.disable_interface = gicv2_disable_interface,
+.update_lr = gicv2_update_lr,
+.update_hcr_status = gicv2_hcr_status,
+.clear_lr= gicv2_clear_lr,
+.read_lr = gicv2_read_lr,
+.write_lr= gicv2_write_lr,
+.read_vmcr_priority = gicv2_read_vmcr_priority,
+.read_apr= gicv2_read_apr,
+.make_dt_node= gicv2_make_dt_node,
+};
+
+/* Set up the GIC */
+static int __init gicv2_preinit(struct dt_device_node *node, const
Re: [Xen-devel] [PATCH v4 32/33] xl: Add new option dtdev
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The option dtdev will be used to passthrough a non-PCI device described s/non-PCI/device tree/ or just drop it. in the device tree to a guest. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] libxc/xentrace: Replace xc_tbuf_set_cpu_mask with CPU mask with xc_cpumap_t instead of uint32_t
On 03/30/2015 07:04 PM, Konrad Rzeszutek Wilk wrote: Sorry, not ''. Phew. :-) It was the '(i * 8)' vs '(i*8)' Yeah, as you can probably tell style isn't one of the things I'm very particular about (at least compared with a lot of other developers). I think what you had originally was probably closer in line with what's in xentrace.c. So do you want to take this patch and put it into your series (making all the changes you suggest), or do you want me to polish it up and send it separately? I will take it in, do the changes, and also test it on a large machine. Thought should I wait until you are done looking at the other patch? Sure, I should have that done here shortly. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Tue, 31 Mar 2015, George Dunlap wrote: On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu wei.l...@citrix.com wrote: IMHO we need to support --with-system-blktap= in configure in case distro wants to package blktap separately. Not sure if in practice this makes sense since AIUI blktap is only used by Xen. I agree that would be ideal; however, it's not so simple, because at the moment libxl links directly against libblktap. This would mean: 1) Changing libxl so that it could dynamically detect the presence of the proper version of libblktap at runtime and use the stubbed-out defaults if not available. This should be done in ./configure too, not during libxl build / runtime. If libblktap is not present during ./configure then libxl just use stubs. It sounds like you're talking about introducing a hard dependency, such that packages that use a libxl built this way won't function without blktap installed. Yeah, that's simple enough. I'm not super experienced in the distro packaging mindset, but since (AFAIK) no other programs or projects use blktap, is there much point to having a separate repo if you can't opt-out of installing it? It is not an hard dependency: as long as one doesn't use VHDs, ones doesn't see any difference whether blktap is installed on not. #1 is even more difficult because at the moment blktap isn't really designed to have stable external versions -- it would involve adding a library version and all the fun stuff we already do with libxl. It blktap is to be maintained as external project to get wider usage outside of Xen then this is a thing they have to do, isn't it? Otherwise this is just an effort to separate blktap to an external tree, Xen is still coupled with a certain blktap changeset. Not saying this itself is a problem but it would be better to clarify what's the future expectation of blktap as a project. My understanding was: 1. The XenServer team develop and maintain blktap primarily for their own product. 2. They don't have a particular desire for blktap to get wider usage. It's actually other projects -- CentOS and COLO in particular -- that want to be able to use a maintained version of blktap. 3. The XenServer developers are, as individuals, happy to have other people using it; and are willing to make small amounts of efforts to be an upstream -- namely, accepting bug fixes and reviewing minor contributions. 4. However, the XenServer team is primarily focused on building their own product. They won't be able to spend a significant amount of time making blktap more community-friendly. Adding features that are useful to other downstreams but not to XenServer will probably be accepted, but I wouldn't be surprised if large architectural changes which help downstreams (such as COLO) but don't have any benefit for XenServer were rejected. In that case we should probably not have blktap in the xen-unstable tree, because we wouldn't want to have so divergent community models for different component in the same source repository. However we could make it easier to built libxl and blktap together, we could also add blktap to OSSTest and Raisin (http://marc.info/?l=xen-develm=142779794216955). I figured it was worth giving it a try. If things don't work out, then we can either fork (if someone is willing to maintain it), or remove blktap support entirely. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 09/33] xen: Extend DOMCTL createdomain to support arch configuration
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: On ARM the virtual GIC may differ between each guest (emulated GIC version, number of SPIs...). This information is already known at the domain creation and can never change. For now only the gic_version is set. In the long run, there will be more parameters such as the number of SPIs. All will be required to be set at the same time. A new arch-specific structure arch_domainconfig has been created, the x86 one doesn't have any specific configuration, for now, a dummy structure (C-spec compliant) has been created. Some external tools (qemu, xenstore) may be required to create a domain. Rather than asking them to take care of the arch-specific domain configuration, let the current function (xc_domain_create) chose a default configuration and introduce a new one (xc_domain_create_config). This patch also drops the previously introduced DOMCTL arm_configure_domain in Xen 4.5, as it has been made useless. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Keir Fraser k...@xen.org Cc: Andrew Cooper andrew.coop...@citrix.com Cc: George Dunlap george.dun...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com A couple of minor nits which I'll try and remember to fix on commit if a resend of the series isn't needed for another reason. -LOG(DEBUG, - vGIC version: %s, gicv_to_string(config.gic_version)); +LOG(DEBUG, - vGIC version: %s\n, gicv_to_string(xc_config-gic_version)); Log adds the \n itself. /* Create initial domain 0. */ -dom0 = domain_create(0, 0, 0); +/* The vGIC for DOM0 is exactly emulated the hardware GIC */ emulating Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 11/33] xen/arm: route_irq_to_guest: Check validity of the IRQ
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: Currently Xen only supports SPIs routing for guest, add a function is_assignable_irq to check if we can assign a given IRQ to the guest. Secondly, make sure the vIRQ is not the greater that the number of IRQs s/that/than/ configured in the vGIC and it's an SPI. Thirdly, when the IRQ is already assigned to the domain, check the user is not asking to use a different vIRQ than the one already bound. Finally, desc-arch.type which contains the IRQ type (i.e level/edge) must be correctly configured before. The misconfiguration can happen when: - the device has been blacklisted for the current platform - the IRQ has not been described in the device tree Also, use XENLOG_G_ERR in the error message within the function as it will be later called from a guest. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 13/33] xen/arm: gic_route_irq_to_guest: Honor the priority given in parameter
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The priority is already hardcoded in route_irq_to_guest and therefore can't be controlled by the guest. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/33] xen/arm: Allow virq != irq
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: Currently, Xen is assuming that the virtual IRQ will always be the same as IRQ. Modify route_guest_irq to take the virtual IRQ in parameter which allow Xen to assign a different IRQ number. Also store the vIRQ in the desc action to easily retrieve the IRQ target when we need to inject the interrupt. As DOM0 will get most the devices, the vIRQ is equal to the IRQ in that case. At the same time modify the behavior of irq_get_domain. The function now requires that the irq_desc belongs to an IRQ assigned to a guest. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/33] xen/arm: vgic: Correctly calculate GICD_TYPER.ITLinesNumber
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The formula of GICD_TYPER.ITLinesNumber is 32(N + 1). As the number of SPIs suppported by the domain may not be a multiple of 32, we have to round up the number before using it. At the same time remove the mask GICD_TYPE_LINES which is pointless. I presume because something else has ensured that nr_spis is less than the maximum value represented by the mask? Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] domU jiffies not incrementing - timer issue? - Kernel 3.18.10 on Xen 4.5.0
On 31 March 2015 at 07:40, Meng Xu xumengpa...@gmail.com wrote: Did you try to run Xen on native machine instead of using the nested virtualization? Unfortunately we cannot try this as the machine is in use for other things and I don't have access to an identical piece of hardware to try this out. We have another installation (different hardware) working without any issues. Does Xen run in nested virtualization or on bare metal in this case? It's nested under Hyper-V in the same manner as the problematic install. I was deliberately trying to replicate the issue, but the problem doesn't manifest. Mark ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 17/33] xen/arm: vgic: Add spi_to_pending
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
Introduce spi_to_pending in order retrieve the irq_pending structure for
a specific SPI.
It's not possible to re-use irq_to_pending because it's required a VCPU
it requires
and some call of the new function may during domain destruction after
the VCPUs are freed.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Acked-by: Ian Campbell ian.campb...@citrix.com
Although given the name I would expect it to take an spi (i.e. -32) not
an irq. I can't think of a better name though and perhaps that just
makes things harder for the caller.
Ian.
---
Changes in v4:
- Patch added
---
xen/arch/arm/vgic.c| 7 +++
xen/include/asm-arm/vgic.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 74751e0..fc283ec 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -371,6 +371,13 @@ struct pending_irq *irq_to_pending(struct vcpu *v,
unsigned int irq)
return n;
}
+struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq)
+{
+ASSERT(irq = NR_LOCAL_IRQS);
+
+return d-arch.vgic.pending_irqs[irq - 32];
+}
+
void vgic_clear_pending_irqs(struct vcpu *v)
{
struct pending_irq *p, *t;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 647f2fe..8d22532 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -185,6 +185,7 @@ extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned
int virq);
extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
extern void vgic_clear_pending_irqs(struct vcpu *v);
extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int
irq);
extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n,
int s);
extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq);
extern int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On 03/31/2015 11:40 AM, Stefano Stabellini wrote: On Tue, 31 Mar 2015, George Dunlap wrote: On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu wei.l...@citrix.com wrote: IMHO we need to support --with-system-blktap= in configure in case distro wants to package blktap separately. Not sure if in practice this makes sense since AIUI blktap is only used by Xen. I agree that would be ideal; however, it's not so simple, because at the moment libxl links directly against libblktap. This would mean: 1) Changing libxl so that it could dynamically detect the presence of the proper version of libblktap at runtime and use the stubbed-out defaults if not available. This should be done in ./configure too, not during libxl build / runtime. If libblktap is not present during ./configure then libxl just use stubs. It sounds like you're talking about introducing a hard dependency, such that packages that use a libxl built this way won't function without blktap installed. Yeah, that's simple enough. I'm not super experienced in the distro packaging mindset, but since (AFAIK) no other programs or projects use blktap, is there much point to having a separate repo if you can't opt-out of installing it? It is not an hard dependency: as long as one doesn't use VHDs, ones doesn't see any difference whether blktap is installed on not. I'm talking about a hard dependency *for the resulting package*. If libxl built linked against libblktap, and libblktap is not installed on the system, then won't running the binary at all result in Can't find shared library errors? In any case, I'm pretty sure that if you build an RPM and link against a particular library, that the RPM will then refuse to install if that library isn't available. In that case we should probably not have blktap in the xen-unstable tree, because we wouldn't want to have so divergent community models for different component in the same source repository. Community model doesn't matter to me; what matters to me is the practical question of whether we can upstream what we need to upstream. An upstream that was in theory open but in practice difficult to work with or hostile to our patches would be a lot worse than an upstream that was in theory closed but in practice cooperative and took everything we sent them. I don't expect there to be any major changes required upstream, and so I think that in practice this won't be an issue. If it ever does become an issue, then we can decide what to do about it at that time. The reason I put it so strongly is that I want to make sure that there are no hard feelings if we end up having to go separate ways. The XenServer team are doing us a favor, and haven't promised a large amount of development time or commitment. I think what they're willing to offer will be sufficient for what we need. However we could make it easier to built libxl and blktap together, we could also add blktap to OSSTest and Raisin (http://marc.info/?l=xen-develm=142779794216955). I wouldn't mind moving all external repos (qemu-*, seabios, ovmf, blktap, c) out of the Xen tree as soon as Raisin is mature enough to do so. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 19/33] xen/arm: Implement hypercall DOMCTL_{, un}bind_pt_pirq
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
On x86, an IRQ is assigned in 2 steps to an HVM guest:
- The toolstack is calling PHYSDEVOP_map_pirq in order to create a
guest PIRQ (IRQ bound to an event channel)
- The emulator (QEMU) is calling DOMCTL_bind_pt_irq in order to
bind the IRQ
On ARM, there is no concept of PIRQ as the IRQ can be assigned to a
virtual IRQ using the interrupt controller.
It's not clear if we will need 2 different hypercalls on ARM to assign
IRQ and, for now, only the toolstack will manage IRQ.
In order to avoid re-using a fixed ABI hypercall (PHYSDEVOP_*) for a
different purpose and allow us more time to figure out the right out,
figure out the right way
only DOMCTL_{,un}bind_pt_pirq is implemented on ARM.
The DOMCTL is extended with a new type PT_IRQ_TYPE_SPI and only IRQ ==
vIRQ (i.e machine_irq == spi) is supported.
Concerning XSM, even if ARM is using one hypercall rather than 2, the
resulting check is nearly the same.
XSM PHYSDEVOP_map_pirq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to add the IRQ
3) Check if the target domain has permission to use the IRQ
XSM DOMCTL_bind_pirq_irq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to bind the IRQ
3) Check if the target domain has permission to use the IRQ
Rather than checking that the current domain can both add and bind the
IRQ, we only check the bind permission. I think this is not a big deal
because we don't have emulator on ARM and therefore no disaggregation is
required.
Is this because we don't have the add concept on arm?
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 579d266..8243b70 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1764,7 +1764,7 @@ int xc_domain_bind_pt_irq(
uint8_t bus,
uint8_t device,
uint8_t intx,
-uint8_t isa_irq)
+uint16_t isa_irq)
This interface is pretty awful, taking the union of all the options
needed for each type as separate parameters. Reusing the isa_irq
parameter is making this worse along a different axis as well.
AFAICT its only user is qemu-trad with PT_IRQ_TYPE_MSI_TRANSLATE.
I think we should discourage any new uses of this function, and hide any
ugliness in an internal static function to be used by the more specific
xc_domain_bind_pt_isa_irq et al. i.e. make the current
xc_doamin_bind_pt_irq an internal helper with a new name and a new
spi_irq parameter and make the replacement xc_domain_bind_pt_irq a
wrapper which handles only the set of types which it handles today and a
new xc_domain_bind_pt_spi_irq which exposes the new functionality.
Hopefully we can eventually remove xc_domain_bind_pt_irq. If you are
minded to you could do that today, but it's not required I think.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 23/33] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: Currently, when the device is deassigned from a domain, we directly reassign to DOM0. As the device may not have been correctly reset, this may lead to corruption or expose some part of DOM0 memory. Also, we may have no way to reset some platform devices. If Xen reassigns the device to nobody, it may receive some global/context fault because the transaction has failed (indeed the context has been marked invalid). Unfortunately there is no simple way to quiesce a buggy hardware. I think we could live with that for a first version of platform device passthrough. DOM0 will have to issue an hypercall to assign the device to itself if it wants to use it. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 22/33] xen/passthrough: arm: release the DT devices assigned to a guest earlier
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The toolstack may not have deassigned every device used by a guest. Therefore we have to go through the device list and remove them before asking the IOMMU drivers to release memory for this domain. This can be done by moving the call to the release function when we relinquish the resources. The IOMMU part will be destroyed later when the domain is freed. Signed-off-by: Julien Grall julien.gr...@linaro.org Signed-off-by: Robert VanVossen robert.vanvos...@dornerworks.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 27/33] tools/libxl: Create a per-arch function to map IRQ to a domain
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: ARM and x86 use a different hypercall to map an IRQ to a domain. The hypercall to give IRQ permission to the domain as also been moved has also been. on the x86 specific function as ARM guest won't be able to manage the IRQ. s/on the/to be an/? We may want to support it later. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/33] xen/arm: vgic: Correctly calculate GICD_TYPER.ITLinesNumber
On 31/03/15 11:46, Ian Campbell wrote: On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The formula of GICD_TYPER.ITLinesNumber is 32(N + 1). As the number of SPIs suppported by the domain may not be a multiple of 32, we have to round up the number before using it. At the same time remove the mask GICD_TYPE_LINES which is pointless. I presume because something else has ensured that nr_spis is less than the maximum value represented by the mask? The number of SPIs is validated in domain_vgic_init. We would be in trouble in the IRQ guest injection if this number is too high. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com Thanks, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] xentrace: Implement cpu mask range parsing of human values (-c).
On 03/24/2015 03:39 PM, Konrad Rzeszutek Wilk wrote:
Instead of just using -c 0xsome hex value we can
also use -c starting cpu-end cpu or -c cpu1,cpu2
or a combination of them. Also it can include just
singular CPUs: -c cpu1, or ranges without an
start or end (and xentrace will figure out the values), such
as: -c -cpu2 (which will include cpu0, cpu1, and cpu2) or
-c cpu2- (which will include cpu2 and up to MAX_CPUS).
That should make it easier to trace the right CPU if
using this along with 'xl vcpu-list'.
The code has been lifted from the Linux kernel, see file
lib/bitmap.c, function __bitmap_parselist.
To make the old behavior and the new function work, we check
to see if the arguments have '0x' in them. If they do
we use the old style parsing (limited to 32 CPUs). If that
does not exist we use the new parsing.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
[v4: Fix per George's review]
---
tools/xentrace/xentrace.8 | 34 -
tools/xentrace/xentrace.c | 190
++
2 files changed, 188 insertions(+), 36 deletions(-)
diff --git a/tools/xentrace/xentrace.8 b/tools/xentrace/xentrace.8
index c176a96..eb6fba8 100644
--- a/tools/xentrace/xentrace.8
+++ b/tools/xentrace/xentrace.8
@@ -36,10 +36,36 @@ all new records to the output
set the time, p, (in milliseconds) to sleep between polling the buffers
for new data.
.TP
-.B -c, --cpu-mask=c
-set bitmask of CPUs to trace. It is limited to 32-bits.
-If not specified, the cpu-mask of all of the available CPUs will be
-constructed.
+.B -c, --cpu-mask=[\fIc\fP|\fICPU-LIST\fP]
+This can either be a hex value (of the form 0x...), or a set of cpu
+ranges as described below. Hex values are limited to 32 bits. If not
+specified, the cpu-mask of all of the available CPUs will be
+constructed. If using the \fICPU-LIST\fP it expects decimal numbers, which
+may be specified as follows:
+
+.RS 4
+.ie n .IP 0-3 4
+.el .IP ``0-3'' 4
+.IX Item 0-3
+Trace only on CPUs 0 through 3
+.ie n .IP 0,2,5-7 4
+.el .IP ``0,2,5-7'' 4
+.IX Item 0,2,5-7
+Trace only on CPUs 0, 2, and 5 through 7.
+.ie n .IP -3 4
+.el .IP ``-3'' 4
+.IX Item -3
+Trace only on CPUs 0 through 3
+.ie n .IP -3,7 4
+.el .IP ``-3,7'' 4
+.IX Item -3,7
+Trace only on CPUs 0 through 3 and 7
+.ie n .IP 3- 4
+.el .IP ``3-'' 4
+.IX Item -3-
+Trace only on CPUs 3 up to maximum numbers of CPUs the host has.
+.RE
+.Sp
.TP
.B -e, --evt-mask=e
diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c
index 40504ec..3dd5c01 100644
--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -23,6 +23,7 @@
#include string.h
#include getopt.h
#include assert.h
+#include ctype.h
#include sys/poll.h
#include sys/statvfs.h
@@ -54,6 +55,7 @@ typedef struct settings_st {
uint32_t evt_mask;
xc_cpumap_t cpu_mask;
int cpu_bits;
+char *cpu_mask_str;
unsigned long tbuf_size;
unsigned long disk_rsvd;
unsigned long timeout;
@@ -545,25 +547,6 @@ void print_cpu_mask(xc_cpumap_t mask, int bits)
static void set_cpu_mask(xc_cpumap_t mask, int bits)
{
-int i;
-
-if ( bits = 0 )
-{
-bits = xc_get_max_cpus(xc_handle);
-if ( bits = 0 )
-goto out;
-}
-if ( !mask )
-{
-mask = xc_cpumap_alloc(xc_handle);
-if ( !mask )
-goto out;
-
-/* Set it to include _all_ CPUs. */
-for ( i = 0; i XC_DIV_ROUND_UP(bits, 8); i++ )
-mask[i] = 0xff;
-}
-/* And this will limit it to the exact amount of bits. */
if ( xc_tbuf_set_cpu_mask(xc_handle, mask, bits) )
goto out;
@@ -822,7 +805,7 @@ static void usage(void)
Usage: xentrace [OPTION...] [output file]\n \
Tool to capture Xen trace buffer data\n \
\n \
- -c, --cpu-mask=cSet cpu-mask\n \
+ -c, --cpu-mask=cSet cpu-mask, using either hex or CPU ranges\n \
-e, --evt-mask=eSet evt-mask\n \
-s, --poll-sleep=p Set sleep time, p, in milliseconds between\n \
polling the trace buffer for new data\n \
@@ -976,6 +959,156 @@ static int parse_cpumask(const char *arg)
return 0;
}
+#define ZERO_DIGIT '0'
+
+static int parse_cpumask_range(const char *arg)
+{
+xc_cpumap_t map;
+unsigned int a, b, buflen = strlen(arg);
+int c, c_old, totaldigits, nmaskbits;
+int in_range;
+const char *s;
+
+if ( !buflen )
+{
+fprintf(stderr, Invalid option argument: %s\n, arg);
+errno = EINVAL;
+return EXIT_FAILURE;
+}
I think we need blank lines between these if() statements
+nmaskbits = xc_get_max_cpus(xc_handle);
[space]
+if ( nmaskbits = 0 )
+{
+fprintf(stderr, Failed to get max number of CPUs! rc: %d\n,
nmaskbits);
+return EXIT_FAILURE;
+}
[space]
+map =
Re: [Xen-devel] [PATCH v4 28/33] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
The functions fdt_{fisrt,next}_subnode may not be available because:
first
diff --git a/tools/libxl/libxl_fdt.c b/tools/libxl/libxl_fdt.c
new file mode 100644
index 000..f88e9f1
--- /dev/null
+++ b/tools/libxl/libxl_fdt.c
Since this is effectively shims for missing libfdt functionality how
about libxl_libfdt_compat.c or some such?
If wee wanted any fdt specific helpers as part of libxl itself then
those would want to use the libxl_fdt.c name.
@@ -0,0 +1,84 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
Since this is libxl, which should be LGPL I think we must therefore be
taking the BSD option. Perhaps we should make that clear? I'm not sure.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 30/33] tools/libxl: arm: Use an higher value for the GIC phandle
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: The partial device tree may contains phandle. The Device Tree Compiler tends to allocate the phandle from 1. Reserve the ID 65000 for the GIC phandle. I think we can safely assume that the partial device tree will never contain a such ID. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com --- It's not easily possible to track the maximum phandle in the partial device tree. We would need to parse it twice: one for looking the maximum phandle, and one for copying the nodes. This is because we have to know the phandle of the GIC when we create the properties of the root. Or you could fill it in post-hoc like we do with e.g. the initramfs location? Anyway, this'll do for now: Acked-by: Ian Campbell ian.ampb...@citrix.com As the phandle is encoded an unsigned 32 bits, I could use an higher value. Though, having 65000 phandle is already a lot... TODO: If it's necessary, I can check if the value has been used by another phandle in the device tree. If that's easy enough to add then yes please, but if it is complex then don't bother. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 31/33] libxl: Add support for non-PCI passthrough
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: On ARM, every non-PCI device are described in the device tree. Each of them can be found via a path. This patch introduces a very basic support, only the IOMMU will be set up correctly. The user will have to: - Describe the device in the partial device tree - Map manually MMIO/IRQ This is a first approach, that will allow to have a basic non-PCI passthrough support in Xen. This could be improved later. Furthermore add LIBXL_HAVE_DEVICETREE_PASSTHROUGH to indicate we support non-PCI passthrough and partial device tree (introduced by a previous patch). Ah, you can ignore my comment on the previous patch then. The comment with the #define might be an OK place for the big-scary-warning I mentioned in the previous patch too? Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com --- Changes in v4: - Add LIBXL_HAVE_DEVICTREE_PASSTHROUGH to indicate we support non-PCI passthrough. This is also used in order to indicate partial device tree is supported - Remove libxl_dtdev.c as it contains only a 2 lines functions and call directly xc_* from libxl_create.c - Introduce domcreate_attach_dtdev Changes in v3: - Dynamic allocation has been dropped - Rework the commit message in accordance with the previous item Changes in v2: - Get DT infos earlier - Allocate/map IRQ in libxl__arch_domain_create rather than in libxl__device_dt_add - Use VIRQ rather than the PIRQ to construct the interrupts properties of the device tree - Correct cpumask in make_dtdev_node. We allow the interrupt to be used on the 8 CPUs - Fix LOGE when we map the MMIO region in the guest in libxl__device_dt_add. The domain and the IRQ were inverted - Calculate the number of SPIs to configure the VGIC - xc_physdev_dtdev_* helpers has been renamed to xc_dtdev_* - Rename libxl_device_dt to libxl_device_dtdev --- tools/libxl/libxl.h | 6 ++ tools/libxl/libxl_create.c | 32 tools/libxl/libxl_internal.h | 5 + tools/libxl/libxl_types.idl | 5 + 4 files changed, 48 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 6bc75c5..baaf06b 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -179,6 +179,12 @@ #define LIBXL_HAVE_BUILDINFO_HVM_MMIO_HOLE_MEMKB 1 /* + * libxl_domain_build_info has device_tree and libxl_device_dtdev + * exists. This mean non-PCI passthrough is supported for ARM Rather than non-PCI I'd say device tree here, since I'm sure you aren't supporting the new flargle-bus I've just invented... + * +#define LIBXL_HAVE_DEVICETREE_PASSTHROUGH 1 + +/* * libxl ABI compatibility * * The only guarantee which libxl makes regarding ABI compatibility diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 15b464e..39c828b 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -751,6 +751,8 @@ static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret); static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs, int ret); +static void domcreate_attach_dtdev(libxl__egc *egc, + libxl__domain_create_state *dcs); static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); @@ -1444,6 +1446,36 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, } } +domcreate_attach_dtdev(egc, dcs); +return; + +error_out: +assert(ret); +domcreate_complete(egc, dcs, ret); +} + +static void domcreate_attach_dtdev(libxl__egc *egc, + libxl__domain_create_state *dcs) I know it isn't strictly needed, but I think for consistency this function should take a ret and check it + propagate it via domcreate_complete on error, like the other ones in the call chain do. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 08/15] xen: arm: drop cache maintenance by set/way trap handling
On Mon, 2015-03-30 at 14:59 +0100, Julien Grall wrote: On 30/03/15 14:15, Ian Campbell wrote: On Mon, 2015-03-30 at 13:28 +0100, Julien Grall wrote: Hi Ian, On 30/03/15 12:12, Ian Campbell wrote: We do not set HCR_EL2.TSW so we will never see these. This is undoubtedly wrong, but for now remove the dead code. Would it be better to trap and ignore them? Yes, but this patch retains the status quo (while removing a thing to think about in later patches). Doing something better is on my todo list (as I said in the cover letter). Ok. Based on this: Reviewed-by: Julien Grall julien.gr...@linaro.org With that, I think I review all this series. AFAICT yes, you have, thanks. Applied. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: Update XEN_SYSCTL_cputopoinfo name
On Mon, 2015-03-30 at 16:17 -0400, Daniel De Graaf wrote: On 03/30/2015 04:17 PM, Boris Ostrovsky wrote: Commit 2090f14c5cbd (sysctl: make XEN_SYSCTL_topologyinfo sysctl a little more efficient) renamed XEN_SYSCTL_topologyinfo to XEN_SYSCTL_cputopoinfo. It, however, neglected to update this macro for flask-related files. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Reported-by: Wei Liu wei.l...@citrix.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov Applied, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu wei.l...@citrix.com wrote: IMHO we need to support --with-system-blktap= in configure in case distro wants to package blktap separately. Not sure if in practice this makes sense since AIUI blktap is only used by Xen. I agree that would be ideal; however, it's not so simple, because at the moment libxl links directly against libblktap. This would mean: 1) Changing libxl so that it could dynamically detect the presence of the proper version of libblktap at runtime and use the stubbed-out defaults if not available. This should be done in ./configure too, not during libxl build / runtime. If libblktap is not present during ./configure then libxl just use stubs. It sounds like you're talking about introducing a hard dependency, such that packages that use a libxl built this way won't function without blktap installed. Yeah, that's simple enough. I'm not super experienced in the distro packaging mindset, but since (AFAIK) no other programs or projects use blktap, is there much point to having a separate repo if you can't opt-out of installing it? #1 is even more difficult because at the moment blktap isn't really designed to have stable external versions -- it would involve adding a library version and all the fun stuff we already do with libxl. It blktap is to be maintained as external project to get wider usage outside of Xen then this is a thing they have to do, isn't it? Otherwise this is just an effort to separate blktap to an external tree, Xen is still coupled with a certain blktap changeset. Not saying this itself is a problem but it would be better to clarify what's the future expectation of blktap as a project. My understanding was: 1. The XenServer team develop and maintain blktap primarily for their own product. 2. They don't have a particular desire for blktap to get wider usage. It's actually other projects -- CentOS and COLO in particular -- that want to be able to use a maintained version of blktap. 3. The XenServer developers are, as individuals, happy to have other people using it; and are willing to make small amounts of efforts to be an upstream -- namely, accepting bug fixes and reviewing minor contributions. 4. However, the XenServer team is primarily focused on building their own product. They won't be able to spend a significant amount of time making blktap more community-friendly. Adding features that are useful to other downstreams but not to XenServer will probably be accepted, but I wouldn't be surprised if large architectural changes which help downstreams (such as COLO) but don't have any benefit for XenServer were rejected. I figured it was worth giving it a try. If things don't work out, then we can either fork (if someone is willing to maintain it), or remove blktap support entirely. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 06/19] xen: arm: add minimum exception level argument to trap handler helpers
Removes a load of boiler plate.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 65 +-
1 file changed, 32 insertions(+), 33 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ebc09f9..c9c98d3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1578,8 +1578,12 @@ static void advance_pc(struct cpu_user_regs *regs, const
union hsr hsr)
static void handle_raz_wi(struct cpu_user_regs *regs,
register_t *reg,
bool_t read,
- const union hsr hsr)
+ const union hsr hsr,
+ int min_el)
{
+if ( min_el 0 psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+
if ( read )
*reg = 0;
/* else: write ignored */
@@ -1591,8 +1595,12 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
static void handle_wo_wi(struct cpu_user_regs *regs,
register_t *reg,
bool_t read,
- const union hsr hsr)
+ const union hsr hsr,
+ int min_el)
{
+if ( min_el 0 psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+
if ( read )
return inject_undef_exception(regs, hsr);
/* else: ignore */
@@ -1604,8 +1612,12 @@ static void handle_wo_wi(struct cpu_user_regs *regs,
static void handle_ro_raz(struct cpu_user_regs *regs,
register_t *reg,
bool_t read,
- const union hsr hsr)
+ const union hsr hsr,
+ int min_el)
{
+if ( min_el 0 psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+
if ( !read )
return inject_undef_exception(regs, hsr);
/* else: raz */
@@ -1652,16 +1664,15 @@ static void do_cp15_32(struct cpu_user_regs *regs,
*/
case HSR_CPREG32(PMUSERENR):
/* RO at EL0. RAZ/WI at EL1 */
-if ( psr_mode_is_user(regs) !hsr.cp32.read )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+if ( psr_mode_is_user(regs) )
+return handle_ro_raz(regs, r, cp32.read, hsr, 0);
+else
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(PMINTENSET):
case HSR_CPREG32(PMINTENCLR):
/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
-if ( psr_mode_is_user(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(PMCR):
case HSR_CPREG32(PMCNTENSET):
case HSR_CPREG32(PMCNTENCLR):
@@ -1678,9 +1689,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* Accessible at EL0 only if PMUSERENR_EL0.EN is set. We
* emulate that register as 0 above.
*/
-if ( psr_mode_is_user(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
default:
gdprintk(XENLOG_ERR,
@@ -1768,14 +1777,11 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
return handle_ro_raz(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGDSCREXT):
-if ( usr_mode(regs) )
-return inject_undef_exception(regs, hsr);
-
/*
* Implement debug status and control register as RAZ/WI.
* The OS won't use Hardware debug if MDBGen not set.
*/
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGVCR):
case HSR_CPREG32(DBGBVR0):
@@ -1785,14 +1791,10 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
case HSR_CPREG32(DBGBVR1):
case HSR_CPREG32(DBGBCR1):
case HSR_CPREG32(DBGOSDLR):
-if ( usr_mode(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGOSLAR):
-if ( usr_mode(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_wo_wi(regs, r, cp32.read, hsr);
+return handle_wo_wi(regs, r, cp32.read, hsr, 1);
default:
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1868,23 +1870,22 @@ static void do_sysreg(struct cpu_user_regs *regs,
* Accessible from EL1 only, but if EL0 trap happens handle as
* undef.
*/
-if ( psr_mode_is_user(regs) )
-return
[Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper
Reduces the use of goto in the trap handlers to none.
Some explcitily 32-bit types become register_t here, but that's OK, on
32-bit they are 32-bit already and on 64-bit it is fine/harmless to
set the larger register, a 32-bit guest won't see the top half in any
case.
Unlike the previous code the advancing of PC is handled within the
helper, rather than after the end of the switch as before. So return
as the handler is called.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 51 +-
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7270116..8b1846a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1574,11 +1574,24 @@ static void advance_pc(struct cpu_user_regs *regs,
const union hsr hsr)
regs-pc += hsr.len ? 4 : 2;
}
+/* Read as zero + write ignore */
+static void handle_raz_wi(struct cpu_user_regs *regs,
+ register_t *reg,
+ bool_t read,
+ const union hsr hsr)
+{
+if ( read )
+*reg = 0;
+/* else: write ignored */
+
+advance_pc(regs, hsr);
+}
+
static void do_cp15_32(struct cpu_user_regs *regs,
const union hsr hsr)
{
const struct hsr_cp32 cp32 = hsr.cp32;
-uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
+register_t *r = select_user_reg(regs, cp32.reg);
struct vcpu *v = current;
if ( !check_conditional_instr(regs, hsr) )
@@ -1613,14 +1626,14 @@ static void do_cp15_32(struct cpu_user_regs *regs,
/* RO at EL0. RAZ/WI at EL1 */
if ( psr_mode_is_user(regs) !hsr.cp32.read )
return inject_undef_exception(regs, hsr);
-goto cp15_32_raz_wi;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(PMINTENSET):
case HSR_CPREG32(PMINTENCLR):
/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
-goto cp15_32_raz_wi;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(PMCR):
case HSR_CPREG32(PMCNTENSET):
case HSR_CPREG32(PMCNTENCLR):
@@ -1639,11 +1652,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
*/
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
- cp15_32_raz_wi:
-if ( cp32.read )
-*r = 0;
-/* else: write ignored */
-break;
+return handle_raz_wi(regs, r, cp32.read, hsr);
default:
gdprintk(XENLOG_ERR,
@@ -1694,7 +1703,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr)
{
const struct hsr_cp32 cp32 = hsr.cp32;
-uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
+register_t *r = select_user_reg(regs, cp32.reg);
struct domain *d = current-domain;
if ( !check_conditional_instr(regs, hsr) )
@@ -1738,12 +1747,11 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
if ( usr_mode(regs) )
return inject_undef_exception(regs, hsr);
-/* Implement debug status and control register as RAZ/WI.
- * The OS won't use Hardware debug if MDBGen not set
+/*
+ * Implement debug status and control register as RAZ/WI.
+ * The OS won't use Hardware debug if MDBGen not set.
*/
-if ( cp32.read )
- *r = 0;
-break;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(DBGVCR):
case HSR_CPREG32(DBGBVR0):
@@ -1755,10 +1763,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGOSDLR):
if ( usr_mode(regs) )
return inject_undef_exception(regs, hsr);
-/* RAZ/WI */
-if ( cp32.read )
-*r = 0;
-break;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(DBGOSLAR):
if ( usr_mode(regs) )
@@ -1845,7 +1850,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
*/
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
-goto sysreg_raz_wi;
+return handle_raz_wi(regs, x, hsr.sysreg.read, hsr);
case HSR_SYSREG_MDCCSR_EL0:
/*
@@ -1863,7 +1868,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* RO at EL0. RAZ/WI at EL1 */
if ( psr_mode_is_user(regs) !hsr.sysreg.read )
return inject_undef_exception(regs, hsr);
-goto sysreg_raz_wi;
+return handle_raz_wi(regs, x, hsr.sysreg.read, hsr);
case HSR_SYSREG_PMCR_EL0:
case HSR_SYSREG_PMCNTENSET_EL0:
case HSR_SYSREG_PMCNTENCLR_EL0:
@@ -1882,11 +1887,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
[Xen-devel] [PATCH 15/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDA
Gather the affected handlers in a single place per trap type. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 71 ++ 1 file changed, 60 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 518f047..0ab5e56 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1816,6 +1816,28 @@ static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) case HSR_CPREG32(DBGOSDLR): return handle_raz_wi(regs, r, cp32.read, hsr, 1); +/* + * MDCR_EL2.TDA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59 + * + * Unhandled: + *DBGDCCINT + *DBGDTRRXint + *DBGDTRTXint + *DBGWFAR + *DBGDTRTXext + *DBGDTRRXext, + *DBGBXVRn + *DBGCLAIMSET + *DBGCLAIMCLR + *DBGAUTHSTATUS + *DBGDEVID + *DBGDEVID1 + *DBGDEVID2 + *DBGOSECCR + */ case HSR_CPREG32(DBGDIDR): /* * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis @@ -1925,6 +1947,17 @@ static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr) return; } +/* + * MDCR_EL2.TDOSA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58 + * + * Unhandled: + *DBGDTRTXint + *DBGDTRRXint + */ + gdprintk(XENLOG_ERR, %s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n, cp64.read ? mrrc : mcrr, @@ -1993,15 +2026,38 @@ static void do_sysreg(struct cpu_user_regs *regs, case HSR_SYSREG_OSDLR_EL1: return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); -/* RAZ/WI registers: */ -/* - Debug */ +/* + * MDCR_EL2.TDA + * + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59 + * + * Unhandled: + *MDCCINT_EL1 + *DBGDTR_EL0 + *DBGDTRRX_EL0 + *DBGDTRTX_EL0 + *OSDTRRX_EL1 + *OSDTRTX_EL1 + *OSECCR_EL1 + *DBGCLAIMSET_EL1 + *DBGCLAIMCLR_EL1 + *DBGAUTHSTATUS_EL1 + */ case HSR_SYSREG_MDSCR_EL1: -/* - Breakpoints */ +return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); +case HSR_SYSREG_MDCCSR_EL0: +/* + * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate that + * register as RAZ/WI above. So RO at both EL0 and EL1. + */ +return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 0); HSR_SYSREG_DBG_CASES(DBGBVR): HSR_SYSREG_DBG_CASES(DBGBCR): -/* - Watchpoints */ HSR_SYSREG_DBG_CASES(DBGWVR): HSR_SYSREG_DBG_CASES(DBGWCR): +return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); + +/* RAZ/WI registers: */ /* - Perf monitors */ case HSR_SYSREG_PMINTENSET_EL1: case HSR_SYSREG_PMINTENCLR_EL1: @@ -2011,13 +2067,6 @@ static void do_sysreg(struct cpu_user_regs *regs, */ return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); -case HSR_SYSREG_MDCCSR_EL0: -/* - * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate that - * register as RAZ/WI above. So RO at both EL0 and EL1. - */ -return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 0); - /* - Perf monitors */ case HSR_SYSREG_PMUSERENR_EL0: /* RO at EL0. RAZ/WI at EL1 */ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 05/19] xen: arm: Add and use r/o+raz and w/o+wi helpers
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 52 --
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 8b1846a..ebc09f9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1587,6 +1587,34 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
advance_pc(regs, hsr);
}
+/* Write only + write ignore */
+static void handle_wo_wi(struct cpu_user_regs *regs,
+ register_t *reg,
+ bool_t read,
+ const union hsr hsr)
+{
+if ( read )
+return inject_undef_exception(regs, hsr);
+/* else: ignore */
+
+advance_pc(regs, hsr);
+}
+
+/* Read only + read as zero */
+static void handle_ro_raz(struct cpu_user_regs *regs,
+ register_t *reg,
+ bool_t read,
+ const union hsr hsr)
+{
+if ( !read )
+return inject_undef_exception(regs, hsr);
+/* else: raz */
+
+*reg = 0;
+
+advance_pc(regs, hsr);
+}
+
static void do_cp15_32(struct cpu_user_regs *regs,
const union hsr hsr)
{
@@ -1737,11 +1765,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
* Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
* is set to 0, which we emulated below.
*/
-if ( !cp32.read )
-return inject_undef_exception(regs, hsr);
-
-*r = 0;
-break;
+return handle_ro_raz(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGDSCREXT):
if ( usr_mode(regs) )
@@ -1768,11 +1792,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGOSLAR):
if ( usr_mode(regs) )
return inject_undef_exception(regs, hsr);
-/* WO */
-if ( cp32.read )
-return inject_undef_exception(regs, hsr);
-/* else: ignore */
-break;
+return handle_wo_wi(regs, r, cp32.read, hsr);
default:
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1857,11 +1877,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
* Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate
that
* register as RAZ/WI above. So RO at both EL0 and EL1.
*/
-if ( !hsr.sysreg.read )
-return inject_undef_exception(regs, hsr);
-
-*x = 0;
-break;
+return handle_ro_raz(regs, x, hsr.sysreg.read, hsr);
/* - Perf monitors */
case HSR_SYSREG_PMUSERENR_EL0:
@@ -1891,10 +1907,8 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* Write only, Write ignore registers: */
case HSR_SYSREG_OSLAR_EL1:
-if ( hsr.sysreg.read )
-return inject_undef_exception(regs, hsr);
-/* else: write ignored */
-break;
+return handle_wo_wi(regs, x, hsr.sysreg.read, hsr);
+
case HSR_SYSREG_CNTP_CTL_EL0:
case HSR_SYSREG_CNTP_TVAL_EL0:
case HSR_SYSREG_CNTP_CVAL_EL0:
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 19/19] xen: arm: Annotate source of ICC SGI register trapping
I was unable to find an ARMv8 ARM reference to this, so refer to the
GIC Architecture Specification instead.
ARMv8 ARM does cover other ways of trapping these accesses via
ICH_HCR_EL2 but we don't use those and they trap additional registers
as well.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index cc5b8dd..71e349a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2144,6 +2144,12 @@ static void do_sysreg(struct cpu_user_regs *regs,
return inject_undef_exception(regs, hsr);
break;
+/*
+ * HCR_EL2.FMO or HCR_EL2.IMO
+ *
+ * ARMv8: GIC Architecture Specification (PRD03-GENC-010745 24.0)
+ *Section 4.6.8.
+ */
case HSR_SYSREG_ICC_SGI1R_EL1:
if ( !vgic_emulate(regs, hsr) )
{
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 13/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDRA
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 32
xen/include/asm-arm/cpregs.h |4
xen/include/asm-arm/sysregs.h |1 +
3 files changed, 37 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 21bef01..7c37cec 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1790,6 +1790,17 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
switch ( hsr.bits HSR_CP32_REGS_MASK )
{
+/*
+ * MDCR_EL2.TDRA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.15
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ *
+ * Unhandled:
+ *DBGDRAR
+ *DBGDSAR
+ */
+
case HSR_CPREG32(DBGDIDR):
/*
* Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
@@ -1840,6 +1851,8 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
*
* ARMv7 (DDI 0406C.b): B1.14.16
* ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
+ * And all other unknown registers.
*/
default:
gdprintk(XENLOG_ERR,
@@ -1870,6 +1883,17 @@ static void do_cp14_64(struct cpu_user_regs *regs, const
union hsr hsr)
*
* ARMv7 (DDI 0406C.b): B1.14.16
* ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
+ * MDCR_EL2.TDRA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.15
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ *
+ * Unhandled:
+ *DBGDRAR64
+ *DBGDSAR64
+ *
+ * And all other unknown registers.
*/
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
@@ -1936,6 +1960,14 @@ static void do_sysreg(struct cpu_user_regs *regs,
*x = v-arch.actlr;
break;
+/*
+ * MDCR_EL2.TDRA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ */
+case HSR_SYSREG_MDRAR_EL1:
+return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 1);
+
/* RAZ/WI registers: */
/* - Debug */
case HSR_SYSREG_MDSCR_EL1:
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index afe9148..9db8cfd 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -89,10 +89,14 @@
#define TEECR p14,6,c0,c0,0 /* ThumbEE Configuration Register */
/* CP14 CR1: */
+#define DBGDRAR64 p14,0,c1/* Debug ROM Address Register (64-bit
access) */
+#define DBGDRAR p14,0,c1,c0,0 /* Debug ROM Address Register (32-bit
access) */
#define TEEHBR p14,6,c1,c0,0 /* ThumbEE Handler Base Register */
#define JOSCR p14,7,c1,c0,0 /* Jazelle OS Control Register */
/* CP14 CR2: */
+#define DBGDSAR64 p14,0,c2/* Debug Self Address Offset Register
(64-bit access) */
+#define DBGDSAR p14,0,c2,c0,0 /* Debug Self Address Offset Register
(32-bit access) */
#define JMCRp14,7,c2,c0,0 /* Jazelle Main Configuration Register
*/
diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h
index d75e154..55457fd 100644
--- a/xen/include/asm-arm/sysregs.h
+++ b/xen/include/asm-arm/sysregs.h
@@ -45,6 +45,7 @@
#define HSR_SYSREG_DCCISW HSR_SYSREG(1,0,c7,c14,2)
#define HSR_SYSREG_MDSCR_EL1 HSR_SYSREG(2,0,c0,c2,2)
+#define HSR_SYSREG_MDRAR_EL1 HSR_SYSREG(2,0,c1,c0,0)
#define HSR_SYSREG_OSLAR_EL1 HSR_SYSREG(2,0,c1,c0,4)
#define HSR_SYSREG_OSDLR_EL1 HSR_SYSREG(2,0,c1,c3,4)
#define HSR_SYSREG_MDCCSR_EL0 HSR_SYSREG(2,3,c0,c1,0)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 03/19] xen: arm: call inject_undef_exception directly
Reducing the amount of goto maze considerably.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 56 +++---
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 99ceaea..7270116 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -518,13 +518,13 @@ static void inject_iabt64_exception(struct cpu_user_regs
*regs,
#endif
static void inject_undef_exception(struct cpu_user_regs *regs,
- int instr_len)
+ const union hsr hsr)
{
if ( is_32bit_domain(current-domain) )
inject_undef32_exception(regs);
#ifdef CONFIG_ARM_64
else
-inject_undef64_exception(regs, instr_len);
+inject_undef64_exception(regs, hsr.len);
#endif
}
@@ -1592,11 +1592,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
case HSR_CPREG32(CNTP_CTL):
case HSR_CPREG32(CNTP_TVAL):
if ( !vtimer_emulate(regs, hsr) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
break;
case HSR_CPREG32(ACTLR):
if ( psr_mode_is_user(regs) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
if ( cp32.read )
*r = v-arch.actlr;
break;
@@ -1612,14 +1612,14 @@ static void do_cp15_32(struct cpu_user_regs *regs,
case HSR_CPREG32(PMUSERENR):
/* RO at EL0. RAZ/WI at EL1 */
if ( psr_mode_is_user(regs) !hsr.cp32.read )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
goto cp15_32_raz_wi;
case HSR_CPREG32(PMINTENSET):
case HSR_CPREG32(PMINTENCLR):
/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
if ( psr_mode_is_user(regs) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
goto cp15_32_raz_wi;
case HSR_CPREG32(PMCR):
case HSR_CPREG32(PMCNTENSET):
@@ -1638,7 +1638,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* emulate that register as 0 above.
*/
if ( psr_mode_is_user(regs) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
cp15_32_raz_wi:
if ( cp32.read )
*r = 0;
@@ -1652,8 +1652,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs-pc);
gdprintk(XENLOG_ERR, unhandled 32-bit CP15 access %#x\n,
hsr.bits HSR_CP32_REGS_MASK);
- undef_cp15_32:
-inject_undef_exception(regs, hsr.len);
+inject_undef_exception(regs, hsr);
return;
}
advance_pc(regs, hsr);
@@ -1673,7 +1672,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
case HSR_CPREG64(CNTPCT):
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_emulate(regs, hsr) )
-goto undef_cp15_64;
+return inject_undef_exception(regs, hsr);
break;
default:
{
@@ -1685,8 +1684,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs-pc);
gdprintk(XENLOG_ERR, unhandled 64-bit CP15 access %#x\n,
hsr.bits HSR_CP64_REGS_MASK);
- undef_cp15_64:
-inject_undef_exception(regs, hsr.len);
+inject_undef_exception(regs, hsr);
return;
}
}
@@ -1713,7 +1711,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
* is set to 0, which we emulated below.
*/
if ( !cp32.read )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
/* Implement the minimum requirements:
* - Number of watchpoints: 1
@@ -1731,14 +1729,14 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
* is set to 0, which we emulated below.
*/
if ( !cp32.read )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
*r = 0;
break;
case HSR_CPREG32(DBGDSCREXT):
if ( usr_mode(regs) )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
/* Implement debug status and control register as RAZ/WI.
* The OS won't use Hardware debug if MDBGen not set
@@ -1756,7 +1754,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGBCR1):
case HSR_CPREG32(DBGOSDLR):
if ( usr_mode(regs) )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
/* RAZ/WI */
if ( cp32.read )
*r = 0;
@@ -1764,10 +1762,10 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union
[Xen-devel] [PATCH 16/19] xen: arm: Annotate registers trapped by MDCR_EL2.TPM and TPMCR
Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 39 ++- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 0ab5e56..64d55dc 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1661,6 +1661,24 @@ static void do_cp15_32(struct cpu_user_regs *regs, *r = v-arch.actlr; break; +/* + * MDCR_EL2.TPM + * + * ARMv7 (DDI 0406C.b): B1.14.17 + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61 + * + * Unhandled: + *PMEVCNTRn + *PMEVTYPERn + *PMCCFILTR + * + * MDCR_EL2.TPMCR + * + * ARMv7 (DDI 0406C.b): B1.14.17 + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62 + * + * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR. + */ /* We could trap ID_DFR0 and tell the guest we don't support * performance monitoring, but Linux doesn't check the ID_DFR0. * Therefore it will read PMCR. @@ -1675,7 +1693,6 @@ static void do_cp15_32(struct cpu_user_regs *regs, return handle_ro_raz(regs, r, cp32.read, hsr, 0); else return handle_raz_wi(regs, r, cp32.read, hsr, 1); - case HSR_CPREG32(PMINTENSET): case HSR_CPREG32(PMINTENCLR): /* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */ @@ -2057,8 +2074,22 @@ static void do_sysreg(struct cpu_user_regs *regs, HSR_SYSREG_DBG_CASES(DBGWCR): return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); -/* RAZ/WI registers: */ -/* - Perf monitors */ +/* + * MDCR_EL2.TPM + * + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61 + * + * Unhandled: + *PMEVCNTRn_EL0 + *PMEVTYPERn_EL0 + *PMCCFILTR_EL0 + * MDCR_EL2.TPMCR + * + * ARMv7 (DDI 0406C.b): B1.14.17 + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62 + * + * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR. + */ case HSR_SYSREG_PMINTENSET_EL1: case HSR_SYSREG_PMINTENCLR_EL1: /* @@ -2066,8 +2097,6 @@ static void do_sysreg(struct cpu_user_regs *regs, * undef. */ return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); - -/* - Perf monitors */ case HSR_SYSREG_PMUSERENR_EL0: /* RO at EL0. RAZ/WI at EL1 */ if ( psr_mode_is_user(regs) ) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 11/19] xen: arm: Annotate handlers for PCTR_EL2.Tx
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9cdbda8..ba120e5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1704,6 +1704,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* ARMv7 (DDI 0406C.b): B1.14.3
* ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
*
+ * CPTR_EL2.T{0..9,12..13}
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.12
+ * ARMv8 (DDI 0487A.d): N/A
+ *
* And all other unknown registers.
*/
default:
@@ -1735,6 +1740,15 @@ static void do_cp15_64(struct cpu_user_regs *regs,
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
break;
+
+/*
+ * CPTR_EL2.T{0..9,12..13}
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.12
+ * ARMv8 (DDI 0487A.d): N/A
+ *
+ * And all other unknown registers.
+ */
default:
{
const struct hsr_cp64 cp64 = hsr.cp64;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 14/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDOSA
Gather the affected handlers in a single place per trap type. Add some HSR_SYSREG and AArch32 defines for those registers (because I'd already typed them in when I realised I didn't need them). Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 37 + xen/include/asm-arm/cpregs.h |2 ++ xen/include/asm-arm/sysregs.h |2 ++ 3 files changed, 33 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 7c37cec..518f047 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1801,6 +1801,21 @@ static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) *DBGDSAR */ +/* + * MDCR_EL2.TDOSA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58 + * + * Unhandled: + *DBGOSLSR + *DBGPRCR + */ +case HSR_CPREG32(DBGOSLAR): +return handle_wo_wi(regs, r, cp32.read, hsr, 1); +case HSR_CPREG32(DBGOSDLR): +return handle_raz_wi(regs, r, cp32.read, hsr, 1); + case HSR_CPREG32(DBGDIDR): /* * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis @@ -1840,12 +1855,8 @@ static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) case HSR_CPREG32(DBGWCR0): case HSR_CPREG32(DBGBVR1): case HSR_CPREG32(DBGBCR1): -case HSR_CPREG32(DBGOSDLR): return handle_raz_wi(regs, r, cp32.read, hsr, 1); -case HSR_CPREG32(DBGOSLAR): -return handle_wo_wi(regs, r, cp32.read, hsr, 1); - /* * CPTR_EL2.TTA * @@ -1968,6 +1979,20 @@ static void do_sysreg(struct cpu_user_regs *regs, case HSR_SYSREG_MDRAR_EL1: return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 1); +/* + * MDCR_EL2.TDOSA + * + * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58 + * + * Unhandled: + *OSLSR_EL1 + *DBGPRCR_EL1 + */ +case HSR_SYSREG_OSLAR_EL1: +return handle_wo_wi(regs, x, hsr.sysreg.read, hsr, 1); +case HSR_SYSREG_OSDLR_EL1: +return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); + /* RAZ/WI registers: */ /* - Debug */ case HSR_SYSREG_MDSCR_EL1: @@ -1977,8 +2002,6 @@ static void do_sysreg(struct cpu_user_regs *regs, /* - Watchpoints */ HSR_SYSREG_DBG_CASES(DBGWVR): HSR_SYSREG_DBG_CASES(DBGWCR): -/* - Double Lock Register */ -case HSR_SYSREG_OSDLR_EL1: /* - Perf monitors */ case HSR_SYSREG_PMINTENSET_EL1: case HSR_SYSREG_PMINTENCLR_EL1: @@ -2021,8 +2044,6 @@ static void do_sysreg(struct cpu_user_regs *regs, return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); /* Write only, Write ignore registers: */ -case HSR_SYSREG_OSLAR_EL1: -return handle_wo_wi(regs, x, hsr.sysreg.read, hsr, 1); case HSR_SYSREG_CNTP_CTL_EL0: case HSR_SYSREG_CNTP_TVAL_EL0: diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h index 9db8cfd..e5cb00c 100644 --- a/xen/include/asm-arm/cpregs.h +++ b/xen/include/asm-arm/cpregs.h @@ -83,7 +83,9 @@ #define DBGBVR1 p14,0,c0,c1,4 /* Breakpoint Value 1 */ #define DBGBCR1 p14,0,c0,c1,5 /* Breakpoint Control 1 */ #define DBGOSLARp14,0,c1,c0,4 /* OS Lock Access */ +#define DBGOSLSRp14,0,c1,c1,4 /* OS Lock Status Register */ #define DBGOSDLRp14,0,c1,c3,4 /* OS Double Lock */ +#define DBGPRCR p14,0,c1,c4,4 /* Debug Power Control Register */ /* CP14 CR0: */ #define TEECR p14,6,c0,c0,0 /* ThumbEE Configuration Register */ diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h index 55457fd..570f43e 100644 --- a/xen/include/asm-arm/sysregs.h +++ b/xen/include/asm-arm/sysregs.h @@ -47,7 +47,9 @@ #define HSR_SYSREG_MDSCR_EL1 HSR_SYSREG(2,0,c0,c2,2) #define HSR_SYSREG_MDRAR_EL1 HSR_SYSREG(2,0,c1,c0,0) #define HSR_SYSREG_OSLAR_EL1 HSR_SYSREG(2,0,c1,c0,4) +#define HSR_SYSREG_OSLSR_EL1 HSR_SYSREG(2,0,c1,c1,4) #define HSR_SYSREG_OSDLR_EL1 HSR_SYSREG(2,0,c1,c3,4) +#define HSR_SYSREG_DBGPRCR_EL1HSR_SYSREG(2,0,c1,c4,4) #define HSR_SYSREG_MDCCSR_EL0 HSR_SYSREG(2,3,c0,c1,0) #define HSR_SYSREG_DBGBVRn_EL1(n) HSR_SYSREG(2,0,c0,c##n,4) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 09/19] xen: arm: Annotate registers trapped by HSR_EL1.TIDCP
This traps variety of implementation defined registers, so add a note
to the default case of the respective handler.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 16
1 file changed, 16 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ca43f79..e26e673 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1698,6 +1698,14 @@ static void do_cp15_32(struct cpu_user_regs *regs,
*/
return handle_raz_wi(regs, r, cp32.read, hsr, 1);
+/*
+ * HCR_EL2.TIDCP
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.3
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
+ *
+ * And all other unknown registers.
+ */
default:
gdprintk(XENLOG_ERR,
%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1948,6 +1956,14 @@ static void do_sysreg(struct cpu_user_regs *regs,
dprintk(XENLOG_WARNING,
Emulation of sysreg ICC_SGI0R_EL1/ASGI1R_EL1 not
supported\n);
return inject_undef64_exception(regs, hsr.len);
+
+/*
+ * HCR_EL2.TIDCP
+ *
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
+ *
+ * And all other unknown registers.
+ */
default:
{
const struct hsr_sysreg sysreg = hsr.sysreg;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 17/19] xen: arm: Remove CNTPCT_EL0 trap handling.
We set CNTHCTL_EL2.EL1PCTEN and therefore according to ARMv8 (DDI
0487A.d) D1-1510 Table D1-60 we are not trapping this.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c |1 -
xen/arch/arm/vtimer.c | 30 --
2 files changed, 31 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 64d55dc..1c9cf21 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1757,7 +1757,6 @@ static void do_cp15_64(struct cpu_user_regs *regs,
switch ( hsr.bits HSR_CP64_REGS_MASK )
{
-case HSR_CPREG64(CNTPCT):
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index be65c9f..685bfea 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -243,28 +243,6 @@ static int vtimer_cntp_cval(struct cpu_user_regs *regs,
uint64_t *r, int read)
}
return 1;
}
-static int vtimer_cntpct(struct cpu_user_regs *regs, uint64_t *r, int read)
-{
-struct vcpu *v = current;
-uint64_t ticks;
-s_time_t now;
-
-if ( read )
-{
-if ( !ACCESS_ALLOWED(regs, EL0PCTEN) )
-return 0;
-now = NOW() - v-domain-arch.phys_timer_base.offset;
-ticks = ns_to_ticks(now);
-*r = ticks;
-return 1;
-}
-else
-{
-gprintk(XENLOG_DEBUG, WRITE to R/O CNTPCT\n);
-return 0;
-}
-}
-
static int vtimer_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr)
{
@@ -303,11 +281,6 @@ static int vtimer_emulate_cp64(struct cpu_user_regs *regs,
union hsr hsr)
switch ( hsr.bits HSR_CP64_REGS_MASK )
{
-case HSR_CPREG64(CNTPCT):
-if ( !vtimer_cntpct(regs, x, cp64.read) )
-return 0;
-break;
-
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_cntp_cval(regs, x, cp64.read) )
return 0;
@@ -356,9 +329,6 @@ static int vtimer_emulate_sysreg(struct cpu_user_regs
*regs, union hsr hsr)
case HSR_SYSREG_CNTP_CVAL_EL0:
return vtimer_cntp_cval(regs, x, sysreg.read);
-case HSR_SYSREG_CNTPCT_EL0:
-return vtimer_cntpct(regs, x, sysreg.read);
-
default:
return 0;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 10/19] xen: arm: Annotate registers trapped by CPTR_EL2.TTA
Add explicit handler for 64-bit CP14 accesses, with more relevant
debug message (as per other handlers) and to provide a place for the
comment.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 43 +-
xen/include/asm-arm/perfc_defn.h |1 +
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e26e673..9cdbda8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1810,6 +1810,13 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGOSLAR):
return handle_wo_wi(regs, r, cp32.read, hsr, 1);
+
+/*
+ * CPTR_EL2.TTA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.16
+ * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ */
default:
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1824,7 +1831,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
advance_pc(regs, hsr);
}
-static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr)
+static void do_cp14_64(struct cpu_user_regs *regs, const union hsr hsr)
{
const struct hsr_cp64 cp64 = hsr.cp64;
@@ -1834,12 +1841,37 @@ static void do_cp14_dbg(struct cpu_user_regs *regs,
const union hsr hsr)
return;
}
+/*
+ * CPTR_EL2.TTA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.16
+ * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ */
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
cp64.read ? mrrc : mcrr,
cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs-pc);
gdprintk(XENLOG_ERR, unhandled 64-bit CP14 access %#x\n,
hsr.bits HSR_CP64_REGS_MASK);
+inject_undef_exception(regs, hsr);
+}
+
+static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr)
+{
+struct hsr_cp64 cp64 = hsr.cp64;
+
+if ( !check_conditional_instr(regs, hsr) )
+{
+advance_pc(regs, hsr);
+return;
+}
+
+gdprintk(XENLOG_ERR,
+ %s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
+ cp64.read ? mrrc : mcrr,
+ cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs-pc);
+gdprintk(XENLOG_ERR, unhandled 64-bit CP14 DBG access %#x\n,
+ hsr.bits HSR_CP64_REGS_MASK);
inject_undef_exception(regs, hsr);
}
@@ -1962,6 +1994,10 @@ static void do_sysreg(struct cpu_user_regs *regs,
*
* ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
*
+ * CPTR_EL2.TTA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
* And all other unknown registers.
*/
default:
@@ -2156,6 +2192,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
perfc_incr(trap_cp14_32);
do_cp14_32(regs, hsr);
break;
+case HSR_EC_CP14_64:
+GUEST_BUG_ON(!psr_mode_is_32bit(regs-cpsr));
+perfc_incr(trap_cp14_64);
+do_cp14_64(regs, hsr);
+break;
case HSR_EC_CP14_DBG:
GUEST_BUG_ON(!psr_mode_is_32bit(regs-cpsr));
perfc_incr(trap_cp14_dbg);
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index 46015f5..69fabe7 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -9,6 +9,7 @@ PERFCOUNTER(trap_wfe, trap: wfe)
PERFCOUNTER(trap_cp15_32, trap: cp15 32-bit access)
PERFCOUNTER(trap_cp15_64, trap: cp15 64-bit access)
PERFCOUNTER(trap_cp14_32, trap: cp14 32-bit access)
+PERFCOUNTER(trap_cp14_64, trap: cp14 64-bit access)
PERFCOUNTER(trap_cp14_dbg, trap: cp14 dbg access)
PERFCOUNTER(trap_cp, trap: cp access)
PERFCOUNTER(trap_smc32,trap: 32-bit smc)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 18/19] xen: arm: Annotate registers trapped when CNTHCTL_EL2.EL1PCEN == 0
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1c9cf21..cc5b8dd 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1642,6 +1642,12 @@ static void do_cp15_32(struct cpu_user_regs *regs,
switch ( hsr.bits HSR_CP32_REGS_MASK )
{
+/*
+ * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
+ *
+ * ARMv7 (DDI 0406C.b): B4.1.22
+ * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
+ */
case HSR_CPREG32(CNTP_CTL):
case HSR_CPREG32(CNTP_TVAL):
if ( !vtimer_emulate(regs, hsr) )
@@ -1757,6 +1763,12 @@ static void do_cp15_64(struct cpu_user_regs *regs,
switch ( hsr.bits HSR_CP64_REGS_MASK )
{
+/*
+ * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
+ *
+ * ARMv7 (DDI 0406C.b): B4.1.22
+ * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
+ */
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
@@ -2120,14 +2132,18 @@ static void do_sysreg(struct cpu_user_regs *regs,
*/
return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1);
-/* Write only, Write ignore registers: */
-
+/*
+ * !CNTHCTL_EL2.EL1PCEN
+ *
+ * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
+ */
case HSR_SYSREG_CNTP_CTL_EL0:
case HSR_SYSREG_CNTP_TVAL_EL0:
case HSR_SYSREG_CNTP_CVAL_EL0:
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
break;
+
case HSR_SYSREG_ICC_SGI1R_EL1:
if ( !vgic_emulate(regs, hsr) )
{
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-netfront: transmit fully GSO-sized packets
On 30/03/15 14:46, Wei Liu wrote: On Thu, Mar 26, 2015 at 03:08:58PM +, Jonathan Davies wrote: On 26/03/15 12:05, Eric Dumazet wrote: On Thu, 2015-03-26 at 11:13 +, Jonathan Davies wrote: xen-netfront limits transmitted skbs to be at most 44 segments in size. However, GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448 bytes each. This slight reduction in the size of packets means a slight loss in efficiency. Since c/s 9ecd1a75d, xen-netfront sets gso_max_size to XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER, where XEN_NETIF_MAX_TX_SIZE is 65535 bytes. The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s 6c09fa09d) in determining when to split an skb into two is sk-sk_gso_max_size - 1 - MAX_TCP_HEADER. So the maximum permitted size of an skb is calculated to be (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER. Intuitively, this looks like the wrong formula -- we don't need two TCP headers. Instead, there is no need to deviate from the default gso_max_size of 65536 as this already accommodates the size of the header. Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments of 1448 bytes each), as observed via tcpdump. This patch makes netfront send skbs of up to 65160 bytes (45 segments of 1448 bytes each). Fixes: 9ecd1a75d977 (xen-netfront: reduce gso_max_size to account for max TCP header) Signed-off-by: Jonathan Davies jonathan.dav...@citrix.com --- drivers/net/xen-netfront.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index e9b960f..fb6e978 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1279,8 +1279,6 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev) netdev-ethtool_ops = xennet_ethtool_ops; SET_NETDEV_DEV(netdev, dev-dev); - netif_set_gso_max_size(netdev, XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER); - np-netdev = netdev; netif_carrier_off(netdev); Hmm, this partially reverts commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 Why xennet_change_mtu() is not changed by your patch ? I think you are right: the mtu calculation suffers from the same problem. I believe the value of mtu relates to the size of the whole packet, including the header (which is why the value of dev-mtu is normally 1500 rather than 1448). Wei, as the author of commit 9ecd1a75d977 (xen-netfront: reduce gso_max_size to account for max TCP header), do you agree that the max mtu formula should not need to subtract MAX_TCP_HEADER? IIRC at the time I wrote that patch I needed to subtract MAX_TCP_HEADER otherwise netfront would generate oversized packets then get marked as malicious by backend. I think your reasoning is straightforward. Probably other core driver changes have somehow mitigated the issues I saw. Presuming you tested this change and saw no problems, I'm of course happy with making netfront more efficient. :-) Okay, thanks for confirming. I'll post a v2 including the change to xennet_change_mtu. Jonathan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] machine address
On Mon, Mar 30, 2015 at 3:00 PM, HANNAS YAYA Issa issa.hannasy...@enseeiht.fr wrote: Hi When there is a page fault the trapper of the page fault in the hypervisor is do_page_fault in xen/arch/x86/traps.c right? That's for PV guests. For HVM guests, the page fault causes a VMEXIT, which will be handled in xen/arch/x86/hvm/vmx/vmx.c:vmx_vmexit_handler() (on Intel). in this funcion i found a method read_cr2() which return the virtual adrress of the page who generate the page fault. My question is : is it possible to get the machine address of the page table entry for this virtual address? In general the way you have to do that is to use the virtual address to walk the guest's pagetables (exactly the same way the hardware would do on a TLB miss). For HVM guests (or PV guests in shadow mode) there's already code to do walk for you in xen/arch/x86/mm/guest_walk.c:guest_walk(). You can see how it's called from the HAP code and the shadow code if you want. I don't immediately see a walker for PV guests. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen-netfront: transmit fully GSO-sized packets
xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
bytes each. This slight reduction in the size of packets means a slight loss in
efficiency.
Since c/s 9ecd1a75d, xen-netfront sets gso_max_size to
XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
6c09fa09d) in determining when to split an skb into two is
sk-sk_gso_max_size - 1 - MAX_TCP_HEADER.
So the maximum permitted size of an skb is calculated to be
(XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
Instead, there is no need to deviate from the default gso_max_size of 65536 as
this already accommodates the size of the header.
Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
skbs of up to 65160 bytes (45 segments of 1448 bytes each).
Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
it relates to the size of the whole packet, including the header.
Fixes: 9ecd1a75d977 (xen-netfront: reduce gso_max_size to account for max TCP
header)
Signed-off-by: Jonathan Davies jonathan.dav...@citrix.com
---
Changes in v2:
- Also correct max mtu in xennet_change_mtu.
---
drivers/net/xen-netfront.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e9b960f..720aaf6 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1008,8 +1008,7 @@ err:
static int xennet_change_mtu(struct net_device *dev, int mtu)
{
- int max = xennet_can_sg(dev) ?
- XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER : ETH_DATA_LEN;
+ int max = xennet_can_sg(dev) ? XEN_NETIF_MAX_TX_SIZE : ETH_DATA_LEN;
if (mtu max)
return -EINVAL;
@@ -1279,8 +1278,6 @@ static struct net_device *xennet_create_dev(struct
xenbus_device *dev)
netdev-ethtool_ops = xennet_ethtool_ops;
SET_NETDEV_DEV(netdev, dev-dev);
- netif_set_gso_max_size(netdev, XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER);
-
np-netdev = netdev;
netif_carrier_off(netdev);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 01/19] xen: arm: constify union hsr and struct hsr_* where possible.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aaa9d93..69b9513 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -447,7 +447,7 @@ static vaddr_t exception_handler64(struct cpu_user_regs
*regs, vaddr_t offset)
static void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len)
{
vaddr_t handler;
-union hsr esr = {
+const union hsr esr = {
.iss = 0,
.len = instr_len,
.ec = HSR_EC_UNKNOWN,
@@ -1141,7 +1141,7 @@ int do_bug_frame(struct cpu_user_regs *regs, vaddr_t pc)
}
#ifdef CONFIG_ARM_64
-static void do_trap_brk(struct cpu_user_regs *regs, union hsr hsr)
+static void do_trap_brk(struct cpu_user_regs *regs, const union hsr hsr)
{
/* HCR_EL2.TGE and MDCR_EL2.TDE are not set so we never receive
* software breakpoint exception for EL1 and EL0 here.
@@ -1488,7 +1488,8 @@ static const unsigned short cc_map[16] = {
0 /* NV */
};
-static int check_conditional_instr(struct cpu_user_regs *regs, union hsr hsr)
+static int check_conditional_instr(struct cpu_user_regs *regs,
+ const union hsr hsr)
{
unsigned long cpsr, cpsr_cond;
int cond;
@@ -1533,7 +1534,7 @@ static int check_conditional_instr(struct cpu_user_regs
*regs, union hsr hsr)
return 1;
}
-static void advance_pc(struct cpu_user_regs *regs, union hsr hsr)
+static void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
{
unsigned long itbits, cond, cpsr = regs-cpsr;
@@ -1574,9 +1575,9 @@ static void advance_pc(struct cpu_user_regs *regs, union
hsr hsr)
}
static void do_cp15_32(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
-struct hsr_cp32 cp32 = hsr.cp32;
+const struct hsr_cp32 cp32 = hsr.cp32;
uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
struct vcpu *v = current;
@@ -1659,7 +1660,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
}
static void do_cp15_64(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1676,7 +1677,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
break;
default:
{
-struct hsr_cp64 cp64 = hsr.cp64;
+const struct hsr_cp64 cp64 = hsr.cp64;
gdprintk(XENLOG_ERR,
%s p15, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
@@ -1692,9 +1693,9 @@ static void do_cp15_64(struct cpu_user_regs *regs,
advance_pc(regs, hsr);
}
-static void do_cp14_32(struct cpu_user_regs *regs, union hsr hsr)
+static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr)
{
-struct hsr_cp32 cp32 = hsr.cp32;
+const struct hsr_cp32 cp32 = hsr.cp32;
uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
struct domain *d = current-domain;
@@ -1784,9 +1785,9 @@ static void do_cp14_32(struct cpu_user_regs *regs, union
hsr hsr)
advance_pc(regs, hsr);
}
-static void do_cp14_dbg(struct cpu_user_regs *regs, union hsr hsr)
+static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr)
{
-struct hsr_cp64 cp64 = hsr.cp64;
+const struct hsr_cp64 cp64 = hsr.cp64;
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1804,9 +1805,9 @@ static void do_cp14_dbg(struct cpu_user_regs *regs, union
hsr hsr)
inject_undef_exception(regs, hsr.len);
}
-static void do_cp(struct cpu_user_regs *regs, union hsr hsr)
+static void do_cp(struct cpu_user_regs *regs, const union hsr hsr)
{
-struct hsr_cp cp = hsr.cp;
+const struct hsr_cp cp = hsr.cp;
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1821,7 +1822,7 @@ static void do_cp(struct cpu_user_regs *regs, union hsr
hsr)
#ifdef CONFIG_ARM_64
static void do_sysreg(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
register_t *x = select_user_reg(regs, hsr.sysreg.reg);
@@ -1918,7 +1919,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
inject_undef64_exception(regs, hsr.len);
default:
{
-struct hsr_sysreg sysreg = hsr.sysreg;
+const struct hsr_sysreg sysreg = hsr.sysreg;
gdprintk(XENLOG_ERR,
%s %d, %d, c%d, c%d, %d %s x%d @ 0x%PRIregister\n,
@@ -1997,16 +1998,16 @@ done:
}
static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
register_t addr = READ_SYSREG(FAR_EL2);
inject_iabt_exception(regs, addr, hsr.len);
}
static void
[Xen-devel] [PATCH 08/19] xen: arm: implement handling of ACTLR_EL1 trap
While annotating ACTLR I noticed that we don't appear to handle the
64-bit version of this trap. Do so and annotate everything.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 20
xen/include/asm-arm/sysregs.h |1 +
2 files changed, 21 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 70e1b4d..ca43f79 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1647,6 +1647,13 @@ static void do_cp15_32(struct cpu_user_regs *regs,
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
break;
+
+/*
+ * HSR_EL2.TASC / HSR.TAC
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.6
+ * ARMv8 (DDI 0487A.d): G6.2.1
+ */
case HSR_CPREG32(ACTLR):
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
@@ -1849,9 +1856,22 @@ static void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr)
{
register_t *x = select_user_reg(regs, hsr.sysreg.reg);
+struct vcpu *v = current;
switch ( hsr.bits HSR_SYSREG_REGS_MASK )
{
+/*
+ * HSR_EL2.TASC
+ *
+ * ARMv8 (DDI 0487A.d): D7.2.1
+ */
+case HSR_SYSREG_ACTLR_EL1:
+if ( psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+if ( hsr.sysreg.read )
+ *x = v-arch.actlr;
+break;
+
/* RAZ/WI registers: */
/* - Debug */
case HSR_SYSREG_MDSCR_EL1:
diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h
index 2284fd7..d75e154 100644
--- a/xen/include/asm-arm/sysregs.h
+++ b/xen/include/asm-arm/sysregs.h
@@ -72,6 +72,7 @@
case HSR_SYSREG_##REG##n_EL1(15)
#define HSR_SYSREG_SCTLR_EL1 HSR_SYSREG(3,0,c1, c0,0)
+#define HSR_SYSREG_ACTLR_EL1 HSR_SYSREG(3,0,c1, c0,1)
#define HSR_SYSREG_TTBR0_EL1 HSR_SYSREG(3,0,c2, c0,0)
#define HSR_SYSREG_TTBR1_EL1 HSR_SYSREG(3,0,c2, c0,1)
#define HSR_SYSREG_TCR_EL1HSR_SYSREG(3,0,c2, c0,2)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 07/19] xen: arm: Annotate trap handler for HCR_EL2.{TWI, TWE, TSC}
Reference the bit which enables the trap and the section/page which
describes what that bit enables.
These ones are pretty trivial, included for completeness.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c9c98d3..70e1b4d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2083,6 +2083,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
switch (hsr.ec) {
case HSR_EC_WFI_WFE:
+/*
+ * HSR_EL2.TWI, HSR_EL2.TWE
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.9
+ * ARMv8 (DDI 0487A.d): D1-1505 Table D1-51
+ */
if ( !check_conditional_instr(regs, hsr) )
{
advance_pc(regs, hsr);
@@ -2125,6 +2131,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
do_cp(regs, hsr);
break;
case HSR_EC_SMC32:
+/*
+ * HSR_EL2.TSC
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.8
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-44
+ */
GUEST_BUG_ON(!psr_mode_is_32bit(regs-cpsr));
perfc_incr(trap_smc32);
inject_undef32_exception(regs);
@@ -2153,6 +2165,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
do_trap_hypercall(regs, regs-x16, hsr.iss);
break;
case HSR_EC_SMC64:
+/*
+ * HSR_EL2.TSC
+ *
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-44
+ */
GUEST_BUG_ON(psr_mode_is_32bit(regs-cpsr));
perfc_incr(trap_smc64);
inject_undef64_exception(regs, hsr.len);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 12/19] xen: arm: Annotate the handlers for HSTR_EL2.Tx
Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index ba120e5..21bef01 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1709,6 +1709,11 @@ static void do_cp15_32(struct cpu_user_regs *regs, * ARMv7 (DDI 0406C.b): B1.14.12 * ARMv8 (DDI 0487A.d): N/A * + * HSTR_EL2.Tx + * + * ARMv7 (DDI 0406C.b): B1.14.14 + * ARMv8 (DDI 0487A.d): D1-1507 Table D1-55 + * * And all other unknown registers. */ default: @@ -1747,6 +1752,11 @@ static void do_cp15_64(struct cpu_user_regs *regs, * ARMv7 (DDI 0406C.b): B1.14.12 * ARMv8 (DDI 0487A.d): N/A * + * HSTR_EL2.Tx + * + * ARMv7 (DDI 0406C.b): B1.14.14 + * ARMv8 (DDI 0487A.d): D1-1507 Table D1-55 + * * And all other unknown registers. */ default: -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 00/19] xen: arm: cleanup traps.c
While working on reenabling 32-bit user space on arm63 I concluded that the trap handling in traps.c had grown into a twisty confusing mess. Lets try and sort that out. This series contains to halves (after a couple of preparatory cleanups). First clean up the goto maze which we've found ourselves in, by providing a selection of handle_* helpers e.g. for raz/ro etc and by calling those and the existing inject_* helpers directly instead of trying to have only one call to each of the latter by using goto. The handle_* helpers can also deal with the minimum allowable exception level, which simplifies things further. To keep things simpler I've used return handle_... when the caller and callee both return void, since that avoids the need for 3 more lines (2 braces and the return), I think this improves clarity. Second go through init_traps and for each bit there consolidate the handling for each type of trap (e.g. do_cp15_32, do_cp15_64, do_sysreg etc) such that all the registers whose traps are associated with that bit are kept together beneath a comment which documents why those bits are trapped, references the appropriate section of the ARMv7 and ARMv8 ARM (the v8 one in particular has a series of very useful tables per bit) and notes which registers are not explicitly handled (and therefore take the default case). For traps which have no explicit handling (i.e. those which trap implementation defined registers) and which always hit the default case add the comment above that instead. Do the same for the GICv3 ICC traps and timer traps. There is probably scope for doing more, i.e. refactoring related functionality into subsystem helpers (like we do for vtimer) and even moving into separate files, but I think this is a good start. This is a lot of patches, sorry, because I wanted to mostly go through the trap bits one at a time per patch to keep each one manageable, although I did end up compressing some of the more obvious ones. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 02/19] xen: arm: add missing break
Signed-off-by: Ian Campbell ian.campb...@citrix.com
xen: arm: Fix handling of ICC_{SGI1R,SGI0R,ASGI1R}_EL1
Having injected an undefined instruction we don't want to also advance
pc. So return.
THe ICC_{SGI0R,ASGI1R}_EL1 case was previously missing a break, so
would have fallen through to the default case and injected a second
undef, corrupting SPSR_EL1 and ELR_EL1 for the guest.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 69b9513..99ceaea 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1908,7 +1908,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
{
dprintk(XENLOG_WARNING,
failed emulation of sysreg ICC_SGI1R_EL1 access\n);
-inject_undef64_exception(regs, hsr.len);
+return inject_undef64_exception(regs, hsr.len);
}
break;
case HSR_SYSREG_ICC_SGI0R_EL1:
@@ -1916,7 +1916,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* TBD: Implement to support secure grp0/1 SGI forwarding */
dprintk(XENLOG_WARNING,
Emulation of sysreg ICC_SGI0R_EL1/ASGI1R_EL1 not
supported\n);
-inject_undef64_exception(regs, hsr.len);
+return inject_undef64_exception(regs, hsr.len);
default:
{
const struct hsr_sysreg sysreg = hsr.sysreg;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 08/33] MAINTAINERS: move drivers/passthrough/device_tree.c in DEVICE TREE
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: Suggested-by: Jan Beulich jbeul...@suse.com Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Keir Fraser k...@xen.org Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ANNOUNCE] Project Raisin
Hi all, A few weeks ago I started hacking on a new project, consisting in a set of bash scripts to build xen-unstable and a few other useful elements. It is still in very early stages. The name of the new project is Raisin, from Raise Xen, pun intended ;-) It is a bit like DevStack[1] for Xen: its purpose is to simply and quickly retrieve and build Xen and any other related components from source, such as Libvirt and Grub2. Optionally it can install and configure the system for you. In the future it could also build and configure stub domains and driver domains. Another important goal of the project is to effectively act as a working guideline on how to setup a Xen system, so it is important that the code is easy to read and understand. See the README for more information. With the introduction of Raisin, keeping xen-unstable lightweight, clean and well suited for distro packages is going to be easier because we won't have to make compromises with the ease of installation from source. Raisin is going to take care of setting up a full Xen development environment from scratch. As an example, going forward we can move the QEMU build from xen-unstable to Raisin, and integrate Raisin in OSSTest. I would like Raisin to work on as many distros as possible. At the moment Raisin builds have been tested on Debian and Fedora. Installations and system configurations have been tested only on Debian. I would very much appreciate if anybody with expertise on Fedora, CentOS and other distros could help add proper support for them. The code is available here: git://xenbits.xen.org/people/sstabellini/raisin.git http://xenbits.xen.org/gitweb/?p=people/sstabellini/raisin.git Happy Hacking! - Stefano [1] https://github.com/openstack-dev/devstack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xenstore: document xs_set_permissions
Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com --- tools/xenstore/include/xenstore.h | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h index b4b113e..6af5978 100644 --- a/tools/xenstore/include/xenstore.h +++ b/tools/xenstore/include/xenstore.h @@ -149,8 +149,30 @@ struct xs_permissions *xs_get_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, unsigned int *num); -/* Set permissions of node (must be owner). - * Returns false on failure. +/* Set permissions of node (must be owner). Returns false on failure. + * + * Domain 0 may read / write anywhere in the store, regardless of + * permission settings. + * + * Note: + * The perms array is a list of (domid, permissions) pairs. The first + * element in the list specifies the owner of the list, plus the flags + * for every domain not explicitly specified subsequently. The + * subsequent entries are normal capabilities. + * + * Example C code: + * + * struct xs_permissions perms[2]; + * + * perms[0].id = dm_domid; + * perms[0].perms = XS_PERM_NONE; + * perms[1].id = guest_domid; + * perms[1].perms = XS_PERM_READ; + * + * It means the owner of the path is domain $dm_domid, all other + * domains (unless specified in subsequent pair) can neither read from + * nor write to that path. It then specifies domain $guest_domid can + * read from that path. */ bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, struct xs_permissions *perms, -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 06/33] xen/arm: Introduce xen, passthrough property
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: When a device is marked for passthrough (via the new property xen,passthrough), dom0 must not access to the device (i.e not loading a driver), but should be able to manage the MMIO/interrupt of the passthrough device. The latter part will allow the toolstack to map MMIO/IRQ when a device is pass through to a guest. The property xen,passthrough will be translated as 'status=disabled' in the device tree to avoid DOM0 using the device. We assume that DOM0 is able to cope with this property (already the case for Linux, and required by ePAPR). Rework the function map_device (renamed into handle_device) to: * For a given device node: - Give permission to manage IRQ/MMIO for this device - Retrieve the IRQ configuration (i.e edge/level) from the device tree * When the device is not marked for guest passthrough: - Assign the device to the guest if it's protected by an IOMMU - Map the IRQs and MMIOs regions to the guest Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] qemu-trad: fix indentation
On Mon, 30 Mar 2015, Wei Liu wrote: No functional change introduced. Signed-off-by: Wei Liu wei.l...@citrix.com Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com hw/xen_console.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/xen_console.c b/hw/xen_console.c index 80beb31..ef6dfab 100644 --- a/hw/xen_console.c +++ b/hw/xen_console.c @@ -201,13 +201,13 @@ static int con_init(struct XenDevice *xendev) } qemu_free(type); - output = xenstore_read_str(con-console, output); - /* output is a pty by default */ - if (output == NULL) - output = pty; - snprintf(label, sizeof(label), xencons%d, con-xendev.dev); - con-chr = qemu_chr_open(label, output, NULL); - xenstore_store_pv_console_info(con-xendev.dev, con-chr, output); +output = xenstore_read_str(con-console, output); +/* output is a pty by default */ +if (output == NULL) +output = pty; +snprintf(label, sizeof(label), xencons%d, con-xendev.dev); +con-chr = qemu_chr_open(label, output, NULL); +xenstore_store_pv_console_info(con-xendev.dev, con-chr, output); return 0; } -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] NULL pointers and PV guests.
On Mon, Mar 30, 2015 at 3:31 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, Mar 26, 2015 at 04:23:19PM +, Tim Deegan wrote: Hi, After XSA-109 (a null function-pointer dereference) we've been thinking about things we can do to make null pointers less dangerous in PV guests. This is a problem for pure PV only - when Xen is running HVM and PVH guests null pointer dereferences will fault. [ Disclaimer: it's sadly clear that I'm not going to have time to work on any of these ideas myself. :( But we could at least put them on the wish list. ] Idea 1: track PV pagetables so that we can tell which pagetables might map the zero address -- e.g. by adding a flag or new types at each level to indicate that we've seen this pagetable referenced from slot zero of a higer-level pagetable that also has the flag set. Then we could refuse any potential mapping of the bottom virtual 4k. This is probably OK as a general feature because most PV OSes will want to keep the bottom 4k free so that their own null pointers work. But it would potentially mean that the guest couldn't alias the same L1/2/3 pagetable at address 0 and some other address. Linux/BSD people, can you comment on how likely that is to be a problem? Is it totally mad? I would stay away from any pagetables manipulation as much as possible in Linux. Linus is already unhappy with the SHARED_PMD flag being disabled when running under Xen and wants to eliminate that. I'm pretty sure Tim is talking about tracking pagetables in Xen, not in Linux. The only restriction Idea 1 has in Linux would be that it couldn't, even during boot, be able to map something at VA 0, and Tim is asking realistically how often this is likely to be a problem. I know that *in general*, Linux doesn't allow processes to map anything to VA 0 either, for similar reasons; but that there are mechanisms in place to override that. I think we're probably OK with crashing a guest that runs one of these I need NULL pointers programs (or allowing the host admin to special-case permission for VMs she trusts); but there was a fear that there may be a phase during boot where VA 0 gets mapped that would be more difficult to avoid. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 29/33] tools/(lib)xl: Add partial device tree support for ARM
Hi Ian,
On 31/03/15 12:41, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
Let the user to pass additional nodes to the guest device tree. For
this purpose, everything in the node /passthrough from the partial
device tree will be copied into the guest device tree.
The node /aliases will be also copied to allow the user to define
aliases which can be used by the guest kernel.
A simple partial device tree will look like:
/dts-v1/;
/ {
#address-cells = 2;
#size-cells = 2;
passthrough {
compatible = simple-bus;
ranges;
#address-cells = 2;
#size-cells = 2;
/* List of your nodes */
}
};
Note that:
* The interrupt-parent property will be added by the toolstack in
the root node
* The properties compatible, ranges, #address-cells and #size-cells
in /passthrough are mandatory.
The helpers provided by the libfdt don't perform all the necessary
security check on a given device tree. Therefore, only trusted device
tree should be used.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
An example of the partial device tree, as long as how to passthrough
a non-pci device will be added to the tree in a follow-up patch.
A new LIBXL_HAVE_* will be added in the patch which add support for
non-PCI passthrough as both are tight.
Changes in v4:
- Mark the option as unsafe
- The _fdt_* helpers has been moved in a separate patch/file.
Only the prototype is declared
- The partial DT is considered valid. Remove some security check
which make the code cleaner
- Typoes
Changes in v3:
- Patch added
---
docs/man/xl.cfg.pod.5 | 10 +++
tools/libxl/libxl_arm.c | 171
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 1 +
Needs a #define LIBXL_HAVE in libxl.h for 3rd party users of the
library.
As said below the commit message:
A new LIBXL_HAVE_* will be added in the patch which add support for
non-PCI passthrough as both are tight.
Having the define in the patch #31.
4 files changed, 183 insertions(+)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 93cd7d2..bcbc277 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -453,6 +453,16 @@ not emulated.
Specify that this domain is a driver domain. This enables certain
features needed in order to run a driver domain.
+=item Bdevice_tree=PATH
+
+Specify a partial device tree (compiled via the Device Tree Compiler).
+Everything under the node /passthrough will be copied into the guest
+device tree. For convenience, the node /aliases is also copied to allow
+the user to defined aliases which can be used by the guest kernel.
+
+Given the complexity of verifying the validity of a device tree, this
+option should only be used with trusted device tree.
This warning should be in the libxl API docs (i.e. the header or IDL)
somewhere too, so that 3rd party toolstacks know about it. In that
context it should perhaps be a lot more prominent and scarier sounding
too.
I will add it to the IDL. Should I keep there too for the xl documentation?
+
=back
=head2 Devices
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 06e940b..54d197b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -542,6 +542,156 @@ out:
}
}
+/* Only FDT v17 is supported */
+#define FDT_REQUIRED_VERSION0x11
Are versions v17 broken? Or is there some other problem with being more
forward compatible?
(TBH, I've no idea how often this value changes, maybe it's unlikely to
now?)
It was necessary on the previous version of this patch because I was
doing some security check specific to the v17.
I think this check is useless now. So I will drop it.
+return (propoff != -FDT_ERR_NOTFOUND)? propoff : 0;
+}
+
+/*
+ * These functions are defined by libfdt or libxl_fdt.c if it's not
+ * present on the former.
+ */
+int fdt_next_subnode(const void *fdt, int offset);
+int fdt_first_subnode(const void *fdt, int offset);
Better to use the prototype from the libfdt header if it is present,
i.e. wrap these in the associated ifdef-s.
The prototype may be defined in the libfdt header but the function not
exported.
I didn't wrap them into ifdef in order to make sure that the compiler
will complain if the 2 prototypes are different.
I'm in two minds about suggesting putting all that into
libxl_libfdt_compat.h, up to you.
I didn't want to bother adding a new header file.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 31/33] libxl: Add support for non-PCI passthrough
Hi Ian, On 31/03/15 12:49, Ian Campbell wrote: On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: On ARM, every non-PCI device are described in the device tree. Each of them can be found via a path. This patch introduces a very basic support, only the IOMMU will be set up correctly. The user will have to: - Describe the device in the partial device tree - Map manually MMIO/IRQ This is a first approach, that will allow to have a basic non-PCI passthrough support in Xen. This could be improved later. Furthermore add LIBXL_HAVE_DEVICETREE_PASSTHROUGH to indicate we support non-PCI passthrough and partial device tree (introduced by a previous patch). Ah, you can ignore my comment on the previous patch then. The comment with the #define might be an OK place for the big-scary-warning I mentioned in the previous patch too? I think this IDL would be a more suitable place. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com --- Changes in v4: - Add LIBXL_HAVE_DEVICTREE_PASSTHROUGH to indicate we support non-PCI passthrough. This is also used in order to indicate partial device tree is supported - Remove libxl_dtdev.c as it contains only a 2 lines functions and call directly xc_* from libxl_create.c - Introduce domcreate_attach_dtdev Changes in v3: - Dynamic allocation has been dropped - Rework the commit message in accordance with the previous item Changes in v2: - Get DT infos earlier - Allocate/map IRQ in libxl__arch_domain_create rather than in libxl__device_dt_add - Use VIRQ rather than the PIRQ to construct the interrupts properties of the device tree - Correct cpumask in make_dtdev_node. We allow the interrupt to be used on the 8 CPUs - Fix LOGE when we map the MMIO region in the guest in libxl__device_dt_add. The domain and the IRQ were inverted - Calculate the number of SPIs to configure the VGIC - xc_physdev_dtdev_* helpers has been renamed to xc_dtdev_* - Rename libxl_device_dt to libxl_device_dtdev --- tools/libxl/libxl.h | 6 ++ tools/libxl/libxl_create.c | 32 tools/libxl/libxl_internal.h | 5 + tools/libxl/libxl_types.idl | 5 + 4 files changed, 48 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 6bc75c5..baaf06b 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -179,6 +179,12 @@ #define LIBXL_HAVE_BUILDINFO_HVM_MMIO_HOLE_MEMKB 1 /* + * libxl_domain_build_info has device_tree and libxl_device_dtdev + * exists. This mean non-PCI passthrough is supported for ARM Rather than non-PCI I'd say device tree here, since I'm sure you aren't supporting the new flargle-bus I've just invented... Ok + * +#define LIBXL_HAVE_DEVICETREE_PASSTHROUGH 1 + +/* * libxl ABI compatibility * * The only guarantee which libxl makes regarding ABI compatibility diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 15b464e..39c828b 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -751,6 +751,8 @@ static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret); static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs, int ret); +static void domcreate_attach_dtdev(libxl__egc *egc, + libxl__domain_create_state *dcs); static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); @@ -1444,6 +1446,36 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, } } +domcreate_attach_dtdev(egc, dcs); +return; + +error_out: +assert(ret); +domcreate_complete(egc, dcs, ret); +} + +static void domcreate_attach_dtdev(libxl__egc *egc, + libxl__domain_create_state *dcs) I know it isn't strictly needed, but I think for consistency this function should take a ret and check it + propagate it via domcreate_complete on error, like the other ones in the call chain do. The other caller have the ret because they use multidev. When it's not the case (such as domcreate_console_available), the ret parameter is not present. So I'm not keen to add a new unused parameter. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 33/33] docs/misc: arm: Add documentation about non-PCI passthrough
Hi Ian,
On 31/03/15 12:55, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
Note that the example is done on Midway whose SMMU driver is not
supported on Xen upstream.
Currently, I don't have other platform where I can test non-PCI
passthrough.
Please drop references to non-PCI in favour of talking about device tree
throughout.
Will do.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
Changes in v4:
- Patch added
---
docs/misc/arm/passthrough.txt | 58
+++
1 file changed, 58 insertions(+)
create mode 100644 docs/misc/arm/passthrough.txt
diff --git a/docs/misc/arm/passthrough.txt b/docs/misc/arm/passthrough.txt
new file mode 100644
index 000..cf6cc61
--- /dev/null
+++ b/docs/misc/arm/passthrough.txt
@@ -0,0 +1,58 @@
+Passthrough a non-pci device to a guest
+===
+
+The example will use the secondary network card for the midway server.
+
+1) Mark the device to let Xen knowns the device will be used for
passthrough.
s/knowns/know/
+This is done in the device tree node describing the device by adding the
+property xen,passthrough. The command to do it in U-Boot is:
+
+fdt set /soc/ethernet@fff51000 xen,passthrough
+
+2) Create the partial device tree describing the device. The IRQ are mapped
s/the/a/
+1:1 to the guest (i.e VIRQ == IRQ). For MMIO will have to find hole in the
s/MMIO will/MMIO you will/
s/find hole/find a hole/
+guest memory layout (see xen/include/public/arch-arm.h, noted the layout
s/noted/note that/
+is not stable and can change between 2 releases version of Xen).
s/between 2 releases version/versions/
+
+/dts-v1/;
+
+/ {
+/* #*cells are here to keep DTC happy */
+#address-cells = 2;
+#size-cells = 2;
+
+aliases {
+net = mac0;
+};
+
+passthrough {
+compatible = simple-bus;
+ranges;
+#address-cells = 2;
+#size-cells = 2;
+mac0: ethernet@1000 {
+compatible = calxeda,hb-xgmac;
+reg = 0 0x1000 0 0x1000;
+interrupts = 0 80 4 0 81 4 0 82 4;
Tabs vs spaces?
I think so. I will fix it.
Is it worth making reference to looking at the host entry and copying
some of the relevant bits of that, or would that be more confusing?
I don't understand the question here.
+};
+};
+};
+
+Note:
+* The interrupt-parent property will be added by the toolstack in the
+root node;
+* The properties compatible, ranges, #address-cells and #size-cells
+in /passthrough are mandatory.
The following properties are mandatory within the /passthrough node:
* compatible
* ranges
* ...
Are the values of any of them mandatory, i.e. simply-bus or empty
ranges?
simple-bus is mandatory. The empty ranges not.
+
+3) Compile the partial guest device with dtc (Device Tree Compiler).
+For our purpose, the compiled file will be called guest-midway.dtb and
+placed in /root in DOM0.
Can you give an example of the command line please, and
s/guest-midway/passthrough/ would be more generic.
I can.
+3) Add the following options in the guest configuration file:
Please expand to say add the dtdev, irqs and iomem options with values
corresponding to the resources used by the to-be-passedthrough device.
Perhaps also reference xl.cfg(5).
Ok.
+device_tree = /root/guest-midway.dtb
+dtdev = [ /soc/ethernet@fff51000 ]
+irqs = [ 112, 113, 114 ]
+iomem = [ 0xfff51,1@0x1 ]
+
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 00/33] xen/arm: Add support for non-PCI passthrough
Hi Ian, On 31/03/15 12:57, Ian Campbell wrote: On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: I think there is a healthy chunk at the start which is all acked and could be applied, could you let me know how far through the acked bit of the series you think it would be sensible to apply now? If there are any acked bits which follow unacked bits but which are independent then let me know and I'll see if they can be applied. Patch up to #15 (except #7 which miss an ack from Jan) can be pushed. Although some of them contains nits. If it convenient for you, I can resend the series with the nits fixed and patch sorted in order to apply the first part. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 1/2] xenbus_client: Extend interface to support multi-page ring
On Tue, Mar 31, 2015 at 02:36:43PM +0200, Juergen Gross wrote: On 03/31/2015 02:15 PM, Bob Liu wrote: From: Wei Liu wei.l...@citrix.com Originally Xen PV drivers only use single-page ring to pass along information. This might limit the throughput between frontend and backend. The patch extends Xenbus driver to support multi-page ring, which in general should improve throughput if ring is the bottleneck. Changes to various frontend / backend to adapt to the new interface are also included. Affected Xen drivers: * blkfront/back * netfront/back * pcifront/back What about pvscsi drivers? They are affected, too! When I wrote this patch pvscsi didn't exist upstream. It would be fairly easy to change that driver too. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 16/33] xen/arm: Let the toolstack configure the number of SPIs
On 31/03/15 12:59, Ian Campbell wrote: If not then I think we should just check against the architectural 1020 limit and leave it at that. I would have to check on 988 (1020 - 32) which I find less readable. I'd test nr_spis+32 1020, which I think is clear enough. I will do that. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xenstore: document xs_set_permissions
On Tue, Mar 31, 2015 at 01:08:32PM +0100, Ian Campbell wrote: On Tue, 2015-03-31 at 11:24 +0100, Wei Liu wrote: Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com One comment/suggestion: --- tools/xenstore/include/xenstore.h | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h index b4b113e..6af5978 100644 --- a/tools/xenstore/include/xenstore.h +++ b/tools/xenstore/include/xenstore.h @@ -149,8 +149,30 @@ struct xs_permissions *xs_get_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, unsigned int *num); -/* Set permissions of node (must be owner). - * Returns false on failure. +/* Set permissions of node (must be owner). Returns false on failure. + * + * Domain 0 may read / write anywhere in the store, regardless of + * permission settings. + * + * Note: + * The perms array is a list of (domid, permissions) pairs. The first + * element in the list specifies the owner of the list, plus the flags + * for every domain not explicitly specified subsequently. The + * subsequent entries are normal capabilities. + * + * Example C code: + * + * struct xs_permissions perms[2]; + * + * perms[0].id = dm_domid; + * perms[0].perms = XS_PERM_NONE; + * perms[1].id = guest_domid; + * perms[1].perms = XS_PERM_READ; + * + * It means the owner of the path is domain $dm_domid, Is it worth mentioning explicitly that the owner always gets an implicit XS_PERM_READ|XS_PERM_WRITE? No problem. I will send out v2 with this information and your ack. Wei. all other + * domains (unless specified in subsequent pair) can neither read from + * nor write to that path. It then specifies domain $guest_domid can + * read from that path. */ bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, struct xs_permissions *perms, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 125 (CVE-2015-2752) - Long latency MMIO mapping operations are not preemptible
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2015-2752 / XSA-125 version 3 Long latency MMIO mapping operations are not preemptible UPDATES IN VERSION 3 CVE assigned. Public release. ISSUE DESCRIPTION = The XEN_DOMCTL_memory_mapping hypercall allows long running operations without implementing preemption. This hypercall is used by the device model as part of the emulation associated with configuration of PCI devices passed through to HVM guests and is therefore indirectly exposed to those guests. This can cause a physical CPU to become busy for a significant period, leading to a host denial of service in some cases. If a host denial of service is not triggered then it may instead be possible to deny service to the domain running the device model, e.g. domain 0. This hypercall is also exposed more generally to all toolstacks. However the uses of it in libxl based toolstacks are not believed to open up any avenue of attack from an untrusted guest. Other toolstacks may be vulnerable however. IMPACT == The vulnerability is exposed via HVM guests which have a PCI device assigned to them. A malicious HVM guest in such a configuration can mount a denial of service attack affecting the whole system via its associated device model (qemu-dm). A guest is able to trigger this hypercall via operations which it is legitimately expected to perform, therefore running the device model as a stub domain does not offer protection against the host denial of service issue. However it does offer some protection against secondary issues such as denial of service against dom0. VULNERABLE SYSTEMS == The issue is exposed via x86 HVM VMs which have been assigned a PCI device. x86 PV domains, x86 HVM domains without passthrough devices and ARM domains do not expose this vulnerability. Xen 3.2.x and later are vulnerable. Xen 3.1.x and earlier have not been inspected. MITIGATION == Running only PV guests will avoid this issue. This issue can be avoided by not assigning devices with large MMIO regions to untrusted HVM guests. CREDITS === This issue was discovered by Konrad Rzeszutek Wilk of Oracle. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa125.patch Xen 4.5.x, xen-unstable xsa125-4.4.patch Xen 4.4.x xsa125-4.3.patch Xen 4.3.x xsa125-4.2.patch Xen 4.2.x $ sha256sum xsa125*.patch be0c7cceb1af4b7b1341f37c1e20cf804ea3ac7d3c2ca2e5599f936479d5e0de xsa125.patch 5f081407c2955787c6e40daa847f3c4131694dff3bb0bc0ee55495f555c7bb52 xsa125-4.2.patch 3b0641ef2a23f12872267940c408097cb353e57a6e0396a64cdf13592a14f65b xsa125-4.3.patch 2180e657b34d8628d4e0157adf2a36904bb6feaf55d53338e4457ef77d867a31 xsa125-4.4.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVGo5JAAoJEIP+FMlX6CvZlEAIAMdSMKpxum+J9IbUFCqcHFa4 F8zQDkz2hMCY3OjTAq9+n6KR2LLyKDn2hGDP0Mspbo67lRBEjSkp7KEXCoDrA294 YsVuJn8y0T3yPH9du3m0f2vi49MrhnxnUZLNyKCpkxTiClrC/7JX3OZxQTQIGpzf EIsjYP+/w9ava5XYbGKorwlLvGpjRmnZpCDTrZlqKV2bK2O6pWzyvp5zD99FORcJ YVRIGebKu8szbSHZs9ectt4xkZwYrzSjj0+PtryvwLSpSYi0zTWIu9rrgd/ZCXfL tgD+i9zoc2E1ydPlvdKRXEdRHY9gGcaimfbTqYn1ttJ6qQcnbMoRQor4X+v92NU= =m83F -END PGP SIGNATURE- xsa125.patch Description: Binary data xsa125-4.2.patch Description: Binary data xsa125-4.3.patch Description: Binary data xsa125-4.4.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 126 (CVE-2015-2756) - Unmediated PCI command register access in qemu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2015-2756 / XSA-126 version 3 Unmediated PCI command register access in qemu UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = HVM guests are currently permitted to modify the memory and I/O decode bits in the PCI command register of devices passed through to them. Unless the device is an SR-IOV virtual function, after disabling one or both of these bits subsequent accesses to the MMIO or I/O port ranges would - on PCI Express devices - lead to Unsupported Request responses. The treatment of such errors is platform specific. Furthermore (at least) devices under control of the Linux pciback driver in the host are handed to guests with the aforementioned bits turned off. This means that such accesses can similarly lead to Unsupported Request responses until these flags are set as needed by the guest. IMPACT == In the event that the platform surfaces aforementioned UR responses as Non-Maskable Interrupts, and either the OS is configured to treat NMIs as fatal or (e.g. via ACPI's APEI) the platform tells the OS to treat these errors as fatal, the host would crash, leading to a Denial of Service. VULNERABLE SYSTEMS == Xen versions 3.3 and onwards are vulnerable due to supporting PCI pass-through. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only HVM guests with their device model run in Dom0 can take advantage of this vulnerability. Any domain which is given access to a non-SR-IOV virtual function PCI Express device can take advantage of this vulnerability. MITIGATION == This issue can be avoided by not assigning PCI Express devices other than SR-IOV virtual functions to untrusted HVM guests. This issue can also be avoided by only using PV guests or HVM guests with their device model run in a separate (stub) domain. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa126-qemuu.patch qemu-upstream-unstable, Xen 4.5.x, Xen 4.4.x xsa126-qemuu-4.3.patch qemu-upstream-unstable, Xen 4.3.x xsa126-qemut.patch qemu-xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x For those already having the original patch in place, applying the appropriate attached incremental patch addresses the regression. xsa126-qemuu-incr.patch qemu-upstream-unstable, Xen 4.5.x, Xen 4.4.x xsa126-qemuu-4.3-incr.patch qemu-upstream-unstable, Xen 4.3.x xsa126-qemut-incr.patch qemu-xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x $ sha256sum xsa126*.patch bd69a0d18127793a9aa2097062ecaef76df6e6b8f729406d7d52cf66519e3b0d xsa126-qemut-incr.patch 2a9b8f73b2a4f0cfb6b724c9a0a72dbf08cae87cd382f61f563218c32d1036a7 xsa126-qemut.patch 658bc483d1110e4e04de2d70fba1cdb20c5cecdc2f419db2d82bddc3ae1690b6 xsa126-qemuu-4.3-incr.patch 090d9262a9e9d24f0f4eca35cb0d56831d5cec6a6ba38b4c7e276d767de660c1 xsa126-qemuu-4.3.patch 3f7b6737c08ff7e119bec16c8c3b3cb832429f1410e687edf622fab57a22842e xsa126-qemuu-incr.patch eb5b93600267639b2cda1c5e2f937ddbecbf6c8cbd19dbb355224c39c2e40d3e xsa126-qemuu.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVGo5NAAoJEIP+FMlX6CvZvt4IAIeNbTd6EQJE4CnuU6fH9lA3 0fO7FrUEMn7cfiptLy86y01C0d7YqF1MCbO3TKfJ0NJSjvl5CQ/WDuPwjdbD28eW Zi2NZFRRy0JnLM3bgHxYB5Ik7voO6QPm4+BSZxM9rdiOhKwOY1LLyDbRlC5GvsVr 5J87gm1tfcQVHNDkVZp6ZlzQh5Kl3iSFp6KvzwsIagoJucsPVEHsoBWF84I+3peu miT3gQqPeZg3PxplKNBkFZOr4hfE1vkYEmopnPY+ClSqsIB0XWM8XSbr8IByXI/E VBAAsssFYV3mwNSoVrip+CWumi32ocikfxly+GlZxNWiMO4T57La6CJcmjQqaEE= =wvTM -END PGP SIGNATURE- xsa126-qemut-incr.patch Description: Binary data xsa126-qemut.patch Description: Binary data xsa126-qemuu-4.3-incr.patch Description: Binary data xsa126-qemuu-4.3.patch Description: Binary data xsa126-qemuu-incr.patch Description: Binary
[Xen-devel] [PATCH v2 2/2] xen/block: add multi-page ring support
Extend xen/block to support multi-page ring, so that more requests can be issued
by using more than one pages as the request ring between blkfront and backend.
As a result, the performance can get improved significantly.
We got some impressive improvements on our highend iscsi storage cluster
backend.
If using 64 pages as the ring, the IOPS increased about 15 times for the
throughput testing and above doubled for the latency testing.
The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical drives,
32 was really not enough to keep them busy.
Change in V2:
* Rebased to 4.0-rc6
* Add description on how this protocol works into io/blkif.h
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c | 2 +-
drivers/block/xen-blkback/common.h | 3 +-
drivers/block/xen-blkback/xenbus.c | 83 ---
drivers/block/xen-blkfront.c| 111 +---
include/xen/interface/io/blkif.h| 13 +
5 files changed, 156 insertions(+), 56 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 0c8da82..072d15b 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -628,7 +628,7 @@ purge_gnt_list:
}
/* Shrink if we have more than xen_blkif_max_buffer_pages */
- shrink_free_pagepool(blkif, xen_blkif_max_buffer_pages);
+ shrink_free_pagepool(blkif, xen_blkif_max_buffer_pages *
blkif-nr_ring_pages);
if (log_stats time_after(jiffies, blkif-st_print))
print_stats(blkif);
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index 375d288..320ca35 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -254,7 +254,7 @@ struct backend_info;
#define PERSISTENT_GNT_WAS_ACTIVE 1
/* Number of requests that we can fit in a ring */
-#define XEN_BLKIF_REQS 32
+#define XEN_BLKIF_REQS (32 * XENBUS_MAX_RING_PAGES)
struct persistent_gnt {
struct page *page;
@@ -326,6 +326,7 @@ struct xen_blkif {
struct work_struct free_work;
/* Thread shutdown wait queue. */
wait_queue_head_t shutdown_wq;
+ int nr_ring_pages;
};
struct seg_buf {
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index ff30259..b75be66 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -193,8 +193,8 @@ fail:
return ERR_PTR(-ENOMEM);
}
-static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t gref,
-unsigned int evtchn)
+static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t *gref,
+unsigned int nr_grefs, unsigned int evtchn)
{
int err;
@@ -202,7 +202,7 @@ static int xen_blkif_map(struct xen_blkif *blkif,
grant_ref_t gref,
if (blkif-irq)
return 0;
- err = xenbus_map_ring_valloc(blkif-be-dev, gref, 1,
+ err = xenbus_map_ring_valloc(blkif-be-dev, gref, nr_grefs,
blkif-blk_ring);
if (err 0)
return err;
@@ -212,21 +212,21 @@ static int xen_blkif_map(struct xen_blkif *blkif,
grant_ref_t gref,
{
struct blkif_sring *sring;
sring = (struct blkif_sring *)blkif-blk_ring;
- BACK_RING_INIT(blkif-blk_rings.native, sring, PAGE_SIZE);
+ BACK_RING_INIT(blkif-blk_rings.native, sring, PAGE_SIZE *
nr_grefs);
break;
}
case BLKIF_PROTOCOL_X86_32:
{
struct blkif_x86_32_sring *sring_x86_32;
sring_x86_32 = (struct blkif_x86_32_sring *)blkif-blk_ring;
- BACK_RING_INIT(blkif-blk_rings.x86_32, sring_x86_32,
PAGE_SIZE);
+ BACK_RING_INIT(blkif-blk_rings.x86_32, sring_x86_32,
PAGE_SIZE * nr_grefs);
break;
}
case BLKIF_PROTOCOL_X86_64:
{
struct blkif_x86_64_sring *sring_x86_64;
sring_x86_64 = (struct blkif_x86_64_sring *)blkif-blk_ring;
- BACK_RING_INIT(blkif-blk_rings.x86_64, sring_x86_64,
PAGE_SIZE);
+ BACK_RING_INIT(blkif-blk_rings.x86_64, sring_x86_64,
PAGE_SIZE * nr_grefs);
break;
}
default:
@@ -588,6 +588,10 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
if (err)
goto fail;
+ err = xenbus_printf(XBT_NIL, dev-nodename, feature-multi-page-ring,
%u, 1);
+ if (err)
+ goto fail;
+
err = xenbus_switch_state(dev, XenbusStateInitWait);
if (err)
goto fail;
@@ -852,22 +856,61 @@ again:
static int connect_ring(struct backend_info
[Xen-devel] [PATCH v2] xenstore: document xs_set_permissions
Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com --- Change in v2: say explicitly owner has read and write permission --- tools/xenstore/include/xenstore.h | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h index b4b113e..43ee93f 100644 --- a/tools/xenstore/include/xenstore.h +++ b/tools/xenstore/include/xenstore.h @@ -149,8 +149,31 @@ struct xs_permissions *xs_get_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, unsigned int *num); -/* Set permissions of node (must be owner). - * Returns false on failure. +/* Set permissions of node (must be owner). Returns false on failure. + * + * Domain 0 may read / write anywhere in the store, regardless of + * permission settings. + * + * Note: + * The perms array is a list of (domid, permissions) pairs. The first + * element in the list specifies the owner of the list, plus the flags + * for every domain not explicitly specified subsequently. The + * subsequent entries are normal capabilities. + * + * Example C code: + * + * struct xs_permissions perms[2]; + * + * perms[0].id = dm_domid; + * perms[0].perms = XS_PERM_NONE; + * perms[1].id = guest_domid; + * perms[1].perms = XS_PERM_READ; + * + * It means the owner of the path is domain $dm_domid (hence it always + * has read and write permission), all other domains (unless specified + * in subsequent pair) can neither read from nor write to that + * path. It then specifies domain $guest_domid can read from that + * path. */ bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, struct xs_permissions *perms, -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 27/33] tools/libxl: Create a per-arch function to map IRQ to a domain
Hi Ian, On 31/03/15 12:26, Ian Campbell wrote: On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: ARM and x86 use a different hypercall to map an IRQ to a domain. The hypercall to give IRQ permission to the domain as also been moved has also been. on the x86 specific function as ARM guest won't be able to manage the IRQ. s/on the/to be an/? Yes, I will fix it in the next version. We may want to support it later. Signed-off-by: Julien Grall julien.gr...@linaro.org Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Wei Liu wei.l...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com Thanks, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 1/2] xenbus_client: Extend interface to support multi-page ring
On 03/31/2015 02:15 PM, Bob Liu wrote:
From: Wei Liu wei.l...@citrix.com
Originally Xen PV drivers only use single-page ring to pass along
information. This might limit the throughput between frontend and
backend.
The patch extends Xenbus driver to support multi-page ring, which in
general should improve throughput if ring is the bottleneck. Changes to
various frontend / backend to adapt to the new interface are also
included.
Affected Xen drivers:
* blkfront/back
* netfront/back
* pcifront/back
What about pvscsi drivers?
They are affected, too!
Juergen
The interface is documented, as before, in xenbus_client.c.
Change in V2:
* allow ring has arbitrary number of pages = XENBUS_MAX_RING_PAGES
Change in V3:
* update function prototypes
* carefully deal with types of different sizes
Change in V4:
* use PAGE_KERNEL instead of PAGE_KERNEL_IO to avoid breakage on Arm
Change in V5:
* fix off-by-one error and other minor glitches spotted by Mathew Daley
Signed-off-by: Wei Liu wei.l...@citrix.com
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Signed-off-by: Bob Liu bob@oracle.com
Cc: Konrad Wilk konrad.w...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
---
drivers/block/xen-blkback/xenbus.c | 5 +-
drivers/block/xen-blkfront.c | 5 +-
drivers/net/xen-netback/netback.c | 4 +-
drivers/net/xen-netfront.c | 9 +-
drivers/pci/xen-pcifront.c | 5 +-
drivers/xen/xen-pciback/xenbus.c | 2 +-
drivers/xen/xenbus/xenbus_client.c | 387 +++--
include/xen/xenbus.h | 20 +-
8 files changed, 317 insertions(+), 120 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index e3afe97..ff30259 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -193,7 +193,7 @@ fail:
return ERR_PTR(-ENOMEM);
}
-static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
+static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t gref,
unsigned int evtchn)
{
int err;
@@ -202,7 +202,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned
long shared_page,
if (blkif-irq)
return 0;
- err = xenbus_map_ring_valloc(blkif-be-dev, shared_page,
blkif-blk_ring);
+ err = xenbus_map_ring_valloc(blkif-be-dev, gref, 1,
+blkif-blk_ring);
if (err 0)
return err;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 37779e4..2c61cf8 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1245,6 +1245,7 @@ static int setup_blkring(struct xenbus_device *dev,
struct blkfront_info *info)
{
struct blkif_sring *sring;
+ grant_ref_t gref;
int err;
info-ring_ref = GRANT_INVALID_REF;
@@ -1257,13 +1258,13 @@ static int setup_blkring(struct xenbus_device *dev,
SHARED_RING_INIT(sring);
FRONT_RING_INIT(info-ring, sring, PAGE_SIZE);
- err = xenbus_grant_ring(dev, virt_to_mfn(info-ring.sring));
+ err = xenbus_grant_ring(dev, info-ring.sring, 1, gref);
if (err 0) {
free_page((unsigned long)sring);
info-ring.sring = NULL;
goto fail;
}
- info-ring_ref = err;
+ info-ring_ref = gref;
err = xenbus_alloc_evtchn(dev, info-evtchn);
if (err)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 997cf09..865203f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1782,7 +1782,7 @@ int xenvif_map_frontend_rings(struct xenvif_queue *queue,
int err = -ENOMEM;
err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(queue-vif),
-tx_ring_ref, addr);
+tx_ring_ref, 1, addr);
if (err)
goto err;
@@ -1790,7 +1790,7 @@ int xenvif_map_frontend_rings(struct xenvif_queue *queue,
BACK_RING_INIT(queue-tx, txs, PAGE_SIZE);
err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(queue-vif),
-rx_ring_ref, addr);
+rx_ring_ref, 1, addr);
if (err)
goto err;
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e9b960f..13f5e7f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1486,6 +1486,7 @@ static int setup_netfront(struct xenbus_device *dev,
{
struct xen_netif_tx_sring *txs;
struct xen_netif_rx_sring *rxs;
+ grant_ref_t gref;
int err;
queue-tx_ring_ref = GRANT_INVALID_REF;
@@ -1502,10 +1503,10 @@ static int setup_netfront(struct xenbus_device *dev,
SHARED_RING_INIT(txs);
Re: [Xen-devel] [PATCH v4 33/33] docs/misc: arm: Add documentation about non-PCI passthrough
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
Note that the example is done on Midway whose SMMU driver is not
supported on Xen upstream.
Currently, I don't have other platform where I can test non-PCI
passthrough.
Please drop references to non-PCI in favour of talking about device tree
throughout.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
Changes in v4:
- Patch added
---
docs/misc/arm/passthrough.txt | 58
+++
1 file changed, 58 insertions(+)
create mode 100644 docs/misc/arm/passthrough.txt
diff --git a/docs/misc/arm/passthrough.txt b/docs/misc/arm/passthrough.txt
new file mode 100644
index 000..cf6cc61
--- /dev/null
+++ b/docs/misc/arm/passthrough.txt
@@ -0,0 +1,58 @@
+Passthrough a non-pci device to a guest
+===
+
+The example will use the secondary network card for the midway server.
+
+1) Mark the device to let Xen knowns the device will be used for passthrough.
s/knowns/know/
+This is done in the device tree node describing the device by adding the
+property xen,passthrough. The command to do it in U-Boot is:
+
+fdt set /soc/ethernet@fff51000 xen,passthrough
+
+2) Create the partial device tree describing the device. The IRQ are mapped
s/the/a/
+1:1 to the guest (i.e VIRQ == IRQ). For MMIO will have to find hole in the
s/MMIO will/MMIO you will/
s/find hole/find a hole/
+guest memory layout (see xen/include/public/arch-arm.h, noted the layout
s/noted/note that/
+is not stable and can change between 2 releases version of Xen).
s/between 2 releases version/versions/
+
+/dts-v1/;
+
+/ {
+/* #*cells are here to keep DTC happy */
+#address-cells = 2;
+#size-cells = 2;
+
+aliases {
+net = mac0;
+};
+
+passthrough {
+compatible = simple-bus;
+ranges;
+#address-cells = 2;
+#size-cells = 2;
+ mac0: ethernet@1000 {
+ compatible = calxeda,hb-xgmac;
+reg = 0 0x1000 0 0x1000;
+ interrupts = 0 80 4 0 81 4 0 82 4;
Tabs vs spaces?
Is it worth making reference to looking at the host entry and copying
some of the relevant bits of that, or would that be more confusing?
+ };
+};
+};
+
+Note:
+* The interrupt-parent property will be added by the toolstack in the
+root node;
+* The properties compatible, ranges, #address-cells and #size-cells
+in /passthrough are mandatory.
The following properties are mandatory within the /passthrough node:
* compatible
* ranges
* ...
Are the values of any of them mandatory, i.e. simply-bus or empty
ranges?
+
+3) Compile the partial guest device with dtc (Device Tree Compiler).
+For our purpose, the compiled file will be called guest-midway.dtb and
+placed in /root in DOM0.
Can you give an example of the command line please, and
s/guest-midway/passthrough/ would be more generic.
+3) Add the following options in the guest configuration file:
Please expand to say add the dtdev, irqs and iomem options with values
corresponding to the resources used by the to-be-passedthrough device.
Perhaps also reference xl.cfg(5).
+device_tree = /root/guest-midway.dtb
+dtdev = [ /soc/ethernet@fff51000 ]
+irqs = [ 112, 113, 114 ]
+iomem = [ 0xfff51,1@0x1 ]
+
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 00/33] xen/arm: Add support for non-PCI passthrough
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: I think there is a healthy chunk at the start which is all acked and could be applied, could you let me know how far through the acked bit of the series you think it would be sensible to apply now? If there are any acked bits which follow unacked bits but which are independent then let me know and I'll see if they can be applied. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 17/33] xen/arm: vgic: Add spi_to_pending
Hi Ian, On 31/03/15 11:55, Ian Campbell wrote: On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote: Introduce spi_to_pending in order retrieve the irq_pending structure for a specific SPI. It's not possible to re-use irq_to_pending because it's required a VCPU it requires and some call of the new function may during domain destruction after the VCPUs are freed. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com Thanks. Although given the name I would expect it to take an spi (i.e. -32) not an irq. I can't think of a better name though and perhaps that just makes things harder for the caller.. It depends if you think relative or absolute. In this case, the absolute value is easier to use. FWIW, we already have SPI-specific function using absolute value. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 16/33] xen/arm: Let the toolstack configure the number of SPIs
On Tue, 2015-03-31 at 12:44 +0100, Julien Grall wrote:
Hi Ian,
On 31/03/15 11:54, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
@@ -68,16 +68,17 @@ static void vgic_init_pending_irq(struct pending_irq
*p, unsigned int virq)
p-irq = virq;
}
-int domain_vgic_init(struct domain *d)
+int domain_vgic_init(struct domain *d, unsigned int nr_spis)
{
int i;
d-arch.vgic.ctlr = 0;
[...]
+/* Limit the number of SPIs supported base on the hardware */
+if ( nr_spis (gic_number_lines() - NR_LOCAL_IRQS) )
+return -EINVAL;
Is there anything in the h/w which leads to this restriction?
The h/w accept an VirtualID 1020. Although, given that we can only
route a physical interrupt to the guest, it's pointless to support more
SPIs than the h/w does.
Right, but it's an artificial restriction at this level. Lets not
bother.
If not then I think we should just check against the architectural 1020
limit and leave it at that.
I would have to check on 988 (1020 - 32) which I find less readable.
I'd test nr_spis+32 1020, which I think is clear enough.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Tue, 2015-03-31 at 12:10 +0100, George Dunlap wrote: However we could make it easier to built libxl and blktap together, we could also add blktap to OSSTest and Raisin (http://marc.info/?l=xen-develm=142779794216955). I wouldn't mind moving all external repos (qemu-*, seabios, ovmf, blktap, c) out of the Xen tree as soon as Raisin is mature enough to do so. Given the intertwining of blktap2 with libxl etc making it a cloned-by-xen.git tree instead of in-xen.git might be a convenient first step? The raisin development would then proceed using the --with-system-blktap option and eventually the in tree stuff could be dropped. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xenstore: document xs_set_permissions
On Tue, 2015-03-31 at 11:24 +0100, Wei Liu wrote: Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com One comment/suggestion: --- tools/xenstore/include/xenstore.h | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h index b4b113e..6af5978 100644 --- a/tools/xenstore/include/xenstore.h +++ b/tools/xenstore/include/xenstore.h @@ -149,8 +149,30 @@ struct xs_permissions *xs_get_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, unsigned int *num); -/* Set permissions of node (must be owner). - * Returns false on failure. +/* Set permissions of node (must be owner). Returns false on failure. + * + * Domain 0 may read / write anywhere in the store, regardless of + * permission settings. + * + * Note: + * The perms array is a list of (domid, permissions) pairs. The first + * element in the list specifies the owner of the list, plus the flags + * for every domain not explicitly specified subsequently. The + * subsequent entries are normal capabilities. + * + * Example C code: + * + * struct xs_permissions perms[2]; + * + * perms[0].id = dm_domid; + * perms[0].perms = XS_PERM_NONE; + * perms[1].id = guest_domid; + * perms[1].perms = XS_PERM_READ; + * + * It means the owner of the path is domain $dm_domid, Is it worth mentioning explicitly that the owner always gets an implicit XS_PERM_READ|XS_PERM_WRITE? all other + * domains (unless specified in subsequent pair) can neither read from + * nor write to that path. It then specifies domain $guest_domid can + * read from that path. */ bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, const char *path, struct xs_permissions *perms, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 19/33] xen/arm: Implement hypercall DOMCTL_{, un}bind_pt_pirq
Hi Ian,
On 31/03/15 12:11, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
On x86, an IRQ is assigned in 2 steps to an HVM guest:
- The toolstack is calling PHYSDEVOP_map_pirq in order to create a
guest PIRQ (IRQ bound to an event channel)
- The emulator (QEMU) is calling DOMCTL_bind_pt_irq in order to
bind the IRQ
On ARM, there is no concept of PIRQ as the IRQ can be assigned to a
virtual IRQ using the interrupt controller.
It's not clear if we will need 2 different hypercalls on ARM to assign
IRQ and, for now, only the toolstack will manage IRQ.
In order to avoid re-using a fixed ABI hypercall (PHYSDEVOP_*) for a
different purpose and allow us more time to figure out the right out,
figure out the right way
only DOMCTL_{,un}bind_pt_pirq is implemented on ARM.
The DOMCTL is extended with a new type PT_IRQ_TYPE_SPI and only IRQ ==
vIRQ (i.e machine_irq == spi) is supported.
Concerning XSM, even if ARM is using one hypercall rather than 2, the
resulting check is nearly the same.
XSM PHYSDEVOP_map_pirq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to add the IRQ
3) Check if the target domain has permission to use the IRQ
XSM DOMCTL_bind_pirq_irq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to bind the IRQ
3) Check if the target domain has permission to use the IRQ
Rather than checking that the current domain can both add and bind the
IRQ, we only check the bind permission. I think this is not a big deal
because we don't have emulator on ARM and therefore no disaggregation is
required.
Is this because we don't have the add concept on arm?
We don't need the 2 concepts on ARM. So I choose on of them. The bind
concept is tight to DOMCTL_bind_irq on x86.
Although, thinking a bit more, it would make more sense to use check
add but not bind.
This is because on x86, add concept if for the toolstack and bind
for the emulator/stubdomain.
FWIW, the example policy give both add and bind right to the
toolstack domain.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 579d266..8243b70 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1764,7 +1764,7 @@ int xc_domain_bind_pt_irq(
uint8_t bus,
uint8_t device,
uint8_t intx,
-uint8_t isa_irq)
+uint16_t isa_irq)
This interface is pretty awful, taking the union of all the options
needed for each type as separate parameters. Reusing the isa_irq
parameter is making this worse along a different axis as well.
AFAICT its only user is qemu-trad with PT_IRQ_TYPE_MSI_TRANSLATE.
I didn't find any other caller. I could replace the usage in
xc_domain_update_msi_irq.
I think we should discourage any new uses of this function, and hide any
ugliness in an internal static function to be used by the more specific
xc_domain_bind_pt_isa_irq et al. i.e. make the current
xc_doamin_bind_pt_irq an internal helper with a new name and a new
spi_irq parameter and make the replacement xc_domain_bind_pt_irq a
wrapper which handles only the set of types which it handles today and a
new xc_domain_bind_pt_spi_irq which exposes the new functionality.
Hopefully we can eventually remove xc_domain_bind_pt_irq. If you are
minded to you could do that today, but it's not required I think.
IIRC, the libxc API is not stable so we could drop a function easily.
Every possible types of IRQ already have helpers. Making
xc_domain_bind_pt_irq static is the easiest things to do (compare to
clean the current function).
I will give a look.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 1/2] uboot: do not use readlink on xsm policy
Ian Campbell writes ([PATCH OSSTEST v2 1/2] uboot: do not use readlink on xsm policy): The policy is not a symlink, so readlink will return nothing. We cannot use readlink -f because that will return an absolute path and we need a path relative to the filesystem root (in this case /boot). Keep flaskpolicy=$flaskpolicy as a shell variable rather than unescaping the uses (so they are interpreted by Perl) to easy any future changes. Signed-off-by: Ian Campbell ian.campb...@citrix.com Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 26/33] xen/passthrough: Extend XEN_DOMCTL_*assign_device to support DT device
Hi Ian,
On 31/03/15 12:24, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
+int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
+ XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+int ret;
+struct dt_device_node *dev;
+
+/* TODO: How to deal with XSM? */
Looks like you do in the following code? Old comment?
Old comment. I forgot to drop it.
+/* TODO: Do we need to check is_dying? Mostly to protect against
+ * hypercall trying to passthrough a device while we are
+ * dying.
iommu_do_pci_domctl does in specific casses (i.e. assign device). I
guess you should follow that lead.
I'm not sure to fully understand when is_dying should be used or not.
Looking to the PCI code, the is_dying has been added when we add code to
deal with page.
I would be inclined to say it's only necessary when deadling with page.
Can someone confirm me?
Otherwise, I don't why is_dying should be check here and not in other call.
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 7f90150..a7cb272 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -475,12 +475,30 @@ typedef struct xen_domctl_sendtrigger
xen_domctl_sendtrigger_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_sendtrigger_t);
-/* Assign PCI device to HVM guest. Sets up IOMMU structures. */
+/* Assign a device to a guest. Sets up IOMMU structures. */
/* XEN_DOMCTL_assign_device */
/* XEN_DOMCTL_test_assign_device */
-/* XEN_DOMCTL_deassign_device */
+/*
+ * XEN_DOMCTL_deassign_device: The behavior of this DOMCTL differs
+ * between the different type of device:
+ * - PCI device (XEN_DOMCTL_DEV_PCI) will be reassigned to DOM0
+ * - non-PCI device (XEN_DOMCTL_DEV_PCI) will left unassigned. DOM0
Did you miss a ! before XEN_DOMCTL, or did you mean to say DT?
I intended to say XEN_DOMCTL_DT. I will fix it.
From an ease of review PoV it would have been nice to add dev and u.pci
first since that would be mechanical, but nevermind now.
Sorry, I was too lazy to do it.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 28/33] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt
Hi Ian,
On 31/03/15 12:35, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
The functions fdt_{fisrt,next}_subnode may not be available because:
first
diff --git a/tools/libxl/libxl_fdt.c b/tools/libxl/libxl_fdt.c
new file mode 100644
index 000..f88e9f1
--- /dev/null
+++ b/tools/libxl/libxl_fdt.c
Since this is effectively shims for missing libfdt functionality how
about libxl_libfdt_compat.c or some such?
I will rename the file.
If wee wanted any fdt specific helpers as part of libxl itself then
those would want to use the libxl_fdt.c name.
@@ -0,0 +1,84 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
Since this is libxl, which should be LGPL I think we must therefore be
taking the BSD option. Perhaps we should make that clear? I'm not sure.
After speaking with Ian J. I will:
- Drop the GPL license from the header as we use the BSD one
- Add the libxl header license
- Specify in the commit message why we chose the BSD license.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 19/33] xen/arm: Implement hypercall DOMCTL_{, un}bind_pt_pirq
On Tue, 2015-03-31 at 13:23 +0100, Julien Grall wrote:
Hi Ian,
On 31/03/15 12:11, Ian Campbell wrote:
On Thu, 2015-03-19 at 19:29 +, Julien Grall wrote:
On x86, an IRQ is assigned in 2 steps to an HVM guest:
- The toolstack is calling PHYSDEVOP_map_pirq in order to create a
guest PIRQ (IRQ bound to an event channel)
- The emulator (QEMU) is calling DOMCTL_bind_pt_irq in order to
bind the IRQ
On ARM, there is no concept of PIRQ as the IRQ can be assigned to a
virtual IRQ using the interrupt controller.
It's not clear if we will need 2 different hypercalls on ARM to assign
IRQ and, for now, only the toolstack will manage IRQ.
In order to avoid re-using a fixed ABI hypercall (PHYSDEVOP_*) for a
different purpose and allow us more time to figure out the right out,
figure out the right way
only DOMCTL_{,un}bind_pt_pirq is implemented on ARM.
The DOMCTL is extended with a new type PT_IRQ_TYPE_SPI and only IRQ ==
vIRQ (i.e machine_irq == spi) is supported.
Concerning XSM, even if ARM is using one hypercall rather than 2, the
resulting check is nearly the same.
XSM PHYSDEVOP_map_pirq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to add the IRQ
3) Check if the target domain has permission to use the IRQ
XSM DOMCTL_bind_pirq_irq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to bind the IRQ
3) Check if the target domain has permission to use the IRQ
Rather than checking that the current domain can both add and bind the
IRQ, we only check the bind permission. I think this is not a big deal
because we don't have emulator on ARM and therefore no disaggregation is
required.
Is this because we don't have the add concept on arm?
We don't need the 2 concepts on ARM. So I choose on of them. The bind
concept is tight to DOMCTL_bind_irq on x86.
Although, thinking a bit more, it would make more sense to use check
add but not bind.
This is because on x86, add concept if for the toolstack and bind
for the emulator/stubdomain.
OK.
FWIW, the example policy give both add and bind right to the
toolstack domain.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 579d266..8243b70 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1764,7 +1764,7 @@ int xc_domain_bind_pt_irq(
uint8_t bus,
uint8_t device,
uint8_t intx,
-uint8_t isa_irq)
+uint16_t isa_irq)
This interface is pretty awful, taking the union of all the options
needed for each type as separate parameters. Reusing the isa_irq
parameter is making this worse along a different axis as well.
AFAICT its only user is qemu-trad with PT_IRQ_TYPE_MSI_TRANSLATE.
I didn't find any other caller. I could replace the usage in
xc_domain_update_msi_irq.
I think we should discourage any new uses of this function, and hide any
ugliness in an internal static function to be used by the more specific
xc_domain_bind_pt_isa_irq et al. i.e. make the current
xc_doamin_bind_pt_irq an internal helper with a new name and a new
spi_irq parameter and make the replacement xc_domain_bind_pt_irq a
wrapper which handles only the set of types which it handles today and a
new xc_domain_bind_pt_spi_irq which exposes the new functionality.
Hopefully we can eventually remove xc_domain_bind_pt_irq. If you are
minded to you could do that today, but it's not required I think.
IIRC, the libxc API is not stable so we could drop a function easily.
Yes, I just didn't want to say that you must shave that yakk here, if
you are keen to do so them please have at it!
Every possible types of IRQ already have helpers. Making
xc_domain_bind_pt_irq static is the easiest things to do (compare to
clean the current function).
I will give a look.
Thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 50273: regressions - FAIL
flight 50273 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/50273/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 36514 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 9 guest-start fail REGR. vs. 36514 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 36514 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass build-armhf-xsm 5 xen-buildfail never pass test-armhf-armhf-xl-cubietruck 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass build-amd64-xsm 5 xen-buildfail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 71cba2a07bb541f25390cdd3546c9ee296a7257b baseline version: xen 3a28f760508fb35c430edac17a9efde5aff6d1d5 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Boris Ostrovsky boris.ostrov...@oracle.com Daniel De Graaf dgde...@tycho.nsa.gov Dario Faggioli dario.faggi...@citrix.com Don Slutz dsl...@verizon.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com JeHyeon Yeon tom.y...@windriver.com Jim Fehlig jfeh...@suse.com Juergen Gross jgr...@suse.com Kevin Tian kevin.t...@intel.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Koushik Chakravarty koushik.chakrava...@citrix.com Olaf Hering o...@aepfle.de Pramod Devendra pramod.deven...@citrix.com Quan Xu quan...@intel.com Riku Voipio riku.voi...@linaro.org Roger Pau Monné roger@citrix.com Ross Lagerwall ross.lagerw...@citrix.com Tim Deegan t...@xen.org Vijaya Kumar K vijaya.ku...@caviumnetworks.com Vijaya Kumar Kvijaya.ku...@caviumnetworks.com Wei Liu wei.l...@citrix.com Wen Congyang we...@cn.fujitsu.com Yang Hongyang yan...@cn.fujitsu.com Yang Zhang yang.z.zh...@intel.com jobs: build-amd64-xsm
Re: [Xen-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind
On 2015/3/30 17:19, Ian Campbell wrote:
On Mon, 2015-03-30 at 09:28 +0800, Chen, Tiejun wrote:
Sounds it should be a legacy fix to qemu-xen-tranditional :) So lets do
it now,
@@ -326,6 +326,10 @@ static char **
libxl__build_device_model_args_old(libxl__gc *gc,
}
if (libxl_defbool_val(b_info-u.hvm.gfx_passthru)) {
flexarray_append(dm_args, -gfx_passthru);
+if (b_info-u.hvm.gfx_passthru_kind
+LIBXL_GFX_PASSTHRU_KIND_IGD)
+LOG(ERROR, unsupported device type for
\gfx_passthru\.\n);
+return NULL;
I'd rather not encode any ordering constraints if we don't have to. I
think this is preferable:
if (libxl_defbool_val(b_info-u.hvm.gfx_passthru)) {
switch (b_info-u.hvm.gfx_passthru_kind) {
case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
case LIBXL_GFX_PASSTHRU_KIND_IGD:
flexarray_append(dm_args, -gfx_passthru);
break;
default:
LOG(ERROR, unsupported gfx_passthru_kind.\n);
return NULL;
}
}
(notice that the error message above doesn't refer to the xl specific
option naming).
Sorry for this delay response.
This looks reasonable and I regenerate this patch based on this comment:
libxl: introduce gfx_passthru_kind
Although we already have 'gfx_passthru' in b_info, this doesn't suffice
after we want to handle IGD specifically. Now we define a new field of
type, gfx_passthru_kind, to indicate we're trying to pass IGD. Actually
this means we can benefit this to support other specific devices just
by extending gfx_passthru_kind. And then we can cooperate with
gfx_passthru to address IGD cases as follows:
gfx_passthru = 0= sets build_info.u.gfx_passthru to false
gfx_passthru = 1= sets build_info.u.gfx_passthru to true and
build_info.u.gfx_passthru_kind to DEFAULT
gfx_passthru = igd= sets build_info.u.gfx_passthru to true
and build_info.u.gfx_passthru_kind to IGD
Here if gfx_passthru_kind = DEFAULT, we will call
libxl__is_igd_vga_passthru() to check if we're hitting that table to need
to pass that option to qemu. But if gfx_passthru_kind = igd we always
force to pass that.
And now gfx_passthru is supported both with the qemu-xen-traditional
device-model and upstream qemu-xen device-model. But when given as a
string this option describes the type of device to enable. Note this
behavior is only supported with the upstream qemu-xen device-model.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
docs/man/xl.cfg.pod.5 | 34 +
tools/libxl/libxl.h | 6 ++
tools/libxl/libxl_dm.c | 46
+
tools/libxl/libxl_types.idl | 6 ++
tools/libxl/xl_cmdimpl.c| 14 --
5 files changed, 96 insertions(+), 10 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 408653f..dfde92d 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -671,7 +671,7 @@ through to this VM. See Lseize|/seize_boolean above.
devices passed through to this VM. See Lpower_mgt|/power_mgmt_boolean
above.
-=item Bgfx_passthru=BOOLEAN
+=item Bgfx_passthru=BOOLEAN|STRING
Enable graphics device PCI passthrough. This option makes an assigned
PCI graphics card become primary graphics card in the VM. The QEMU
@@ -699,9 +699,35 @@ working graphics passthrough. See the
XenVGAPassthroughTestedAdapters
Lhttp://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters wiki page
for currently supported graphics cards for gfx_passthru.
-gfx_passthru is currently only supported with the qemu-xen-traditional
-device-model. Upstream qemu-xen device-model currently does not have
-support for gfx_passthru.
+gfx_passthru is currently supported both with the qemu-xen-traditional
+device-model and upstream qemu-xen device-model.
+
+When given as a boolean the Bgfx_passthru option either disables gfx
+passthru or enables autodetection.
+
+But when given as a string the Bgfx_passthru option describes the type
+of device to enable. Note this behavior is only supported with the upstream
+qemu-xen device-model.
+
+Currently, valid options are:
+
+=over 4
+
+=item Bgfx_passthru=0
+
+Disables graphics device PCI passthrough.
+
+=item Bgfx_passthru=1, Bgfx_passthru=default
+
+Enables graphics device PCI passthrough and autodetects the type of device
+which is being used.
+
+=item igd
+
+Enables graphics device PCI passthrough but forcing the type
+of device to Intel Graphics Device.
+
+=back
Note that some graphics adapters (AMD/ATI cards, for example) do not
necessarily require gfx_passthru option, so you can use the normal Xen
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 5eec092..1144c5e 100644
--- a/tools/libxl/libxl.h
+++
Re: [Xen-devel] [OSSTEST Nested PATCH v7 1/6] parsing grub which has 'submenu' primitive
-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: Tuesday, March 31, 2015 9:44 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com;
Hu, Robert
Subject: Re: [OSSTEST Nested PATCH v7 1/6] parsing grub which has 'submenu'
primitive
On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote:
From a hvm kernel build from Linux stable Kernel tree,
the auto generated grub2 menu will have 'submenu' primitive, upon the
'menuentry' items. Xen boot entries will be grouped into a submenu. This
patch adds capability to support such grub formats.
Signed-off-by: longtao.pang longtaox.p...@intel.com
---
Changes in v7:
Remove the reformatting change for Debian.pm and keep the original format.
Thank you.
---
Osstest/Debian.pm | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 6784024..35163a0 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -398,10 +398,18 @@ sub setupboot_grub2 () {
my $count= 0;
my $entry;
+my $submenu;
while ($f) {
next if m/^\s*\#/ || !m/\S/;
if (m/^\s*\}\s*$/) {
-die unless $entry;
+die unless $entry || $submenu;
+if(!defined $entry defined $submenu){
+logm(Met end of a submenu starting from .
+$submenu-{StartLine}. .
+Our want kern is $want_kernver);
+$submenu=undef;
+next;
+}
my (@missing) =
grep { !defined $entry-{$_} }
(defined $xenhopt
@@ -432,21 +440,24 @@ sub setupboot_grub2 () {
$entry= { Title = $1, StartLine = $., Number =
$count };
$count++;
}
-if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
+if (m/^submenu\s+[\'\](.*)[\'\].*\{\s*$/) {
+$submenu={ StartLine =$.};
+}
This looks reasonable enough to support a single nesting, I suppose we
can leave more deeply nested submenus for another time.
So in that regard this patch looks ok to me.
+if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
die unless $entry;
$entry-{Hv}= $1;
}
-if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
+if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
What are these changes all about? I think they must be unrelated to the
use of submenu (perhaps relate to having a separate /boot or not?). If
so then please do in a separate patch.
You're right. This has nothing to do with submenu.
Going to separate it out in another patch.
If this is somehow to do with submenu then please explain how/why in the
commit log.
BTW, your regex as it stand will accept /boot/boot/boot/boot/vmlinuz. I
think you maybe meant to add (?:\/boot)? to match zero or one
occurrences?
Yes, this is a potential bug. Thanks for point out!
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-multivcpu
branch xen-unstable xen branch xen-unstable job test-amd64-amd64-xl-multivcpu test guest-localmigrate Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: d639e6a05a0f8ee0e61c6cc4eebba78934ef3648 Bug not present: 88a2372c6ba44dd42b915a95a823cf9d4d260e25 commit d639e6a05a0f8ee0e61c6cc4eebba78934ef3648 Author: Jan Beulich jbeul...@suse.com Date: Mon Mar 23 16:51:14 2015 +0100 x86: allow 64-bit PV guest kernels to suppress user mode exposure of M2P Xen L4 entries being uniformly installed into any L4 table and 64-bit PV kernels running in ring 3 means that user mode was able to see the read-only M2P presented by Xen to the guests. While apparently not really representing an exploitable information leak, this still very certainly was never meant to be that way. Building on the fact that these guests already have separate kernel and user mode page tables we can allow guest kernels to tell Xen that they don't want user mode to see this table. We can't, however, do this by default: There is no ABI requirement that kernel and user mode page tables be separate. Therefore introduce a new VM-assist flag allowing the guest to control respective hypervisor behavior: - when not set, L4 tables get created with the respective slot blank, and whenever the L4 table gets used as a kernel one the missing mapping gets inserted, - when set, L4 tables get created with the respective slot initialized as before, and whenever the L4 table gets used as a user one the mapping gets zapped. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Tim Deegan t...@xen.org For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-multivcpu.guest-localmigrate.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 36772 fail [host=scape-moth] / 36622 [host=potato-beetle] 36540 [host=fire-frog] 36514 [host=bush-cricket] 35957 [host=field-cricket] 35887 [host=grain-weevil] 35810 [host=bush-cricket] 35556 ok. Failure / basis pass flights: 36772 / 35556 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest 8a5f782c33c04ea5c9b3ca6fb32d6039e2e5c0c9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a4b276b4ce49c8d70dd841ff885b900ec652b994 42ffdf360dd9df66b0a4a7ada059c02a3cf3a8de 84066dd4ef4bb5983e246c629a26ef4f3394e5d5 Basis pass a74f1d1204a5c892466b52ac68ee6443c1e459d7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a4b276b4ce49c8d70dd841ff885b900ec652b994 0d37748342e29854db7c9f6c47d7f58c6cfba6b2 befe0a0da90d7ac063fd8b5891c7d0cafa5f Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#a74f1d1204a5c892466b52ac68ee6443c1e459d7-8a5f782c33c04ea5c9b3ca6fb32d6039e2e5c0c9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#a4b276b4ce49c8d70dd841ff885b900ec652b994-a4b276b4ce49c8d70dd841ff885b900ec652b994 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0d37748342e29854db7c9f6c47d7f58c6cfba6b2-42ffdf360dd9df66b0a4a7ada059c02a3cf3a8de git://xenbits.xen.org/xen.git#befe0a0da90d7ac063fd8b5891c7d0cafa5f-84066dd4ef4bb5983e246c629a26ef4f3394e5d5 + exec + sh -xe + cd /export/home/osstest/repos/linux-pvops + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/qemu-upstream-unstable + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/xen + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/linux-pvops + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git + git fetch -p origin
[Xen-devel] [PATCH] x86: Factor out common CPU initialization code
Some of x86 bare-metal and Xen CPU initialization code is common between the two
and therefore can be factored out to avoid code duplication.
As a side effect, doing so will also extend the fix provided by commit
a7fcf28d431e (x86/asm/entry: Replace this_cpu_sp0() with current_top_of_stack()
to x86_32) to 32-bit Xen PV guests.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/include/asm/smp.h | 1 +
arch/x86/kernel/smpboot.c | 39 +++
arch/x86/xen/smp.c | 14 +-
3 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index a5cb4f6..17a8dce 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -153,6 +153,7 @@ void cpu_disable_common(void);
void native_smp_prepare_boot_cpu(void);
void native_smp_prepare_cpus(unsigned int max_cpus);
void native_smp_cpus_done(unsigned int max_cpus);
+void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_disable(void);
int common_cpu_die(unsigned int cpu);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index e0e9c26..203aee1 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -776,6 +776,27 @@ out:
return boot_error;
}
+void common_cpu_up(unsigned int cpu, struct task_struct *idle)
+{
+ /* Just in case we booted with a single CPU. */
+ alternatives_enable_smp();
+
+ per_cpu(current_task, cpu) = idle;
+
+#ifdef CONFIG_X86_32
+ /* Stack for startup_32 can be just as for start_secondary onwards */
+ irq_ctx_init(cpu);
+ per_cpu(cpu_current_top_of_stack, cpu) =
+ (unsigned long)task_stack_page(idle) + THREAD_SIZE;
+#else
+ clear_tsk_thread_flag(idle, TIF_FORK);
+ initial_gs = per_cpu_offset(cpu);
+#endif
+ per_cpu(kernel_stack, cpu) =
+ (unsigned long)task_stack_page(idle) -
+ KERNEL_STACK_OFFSET + THREAD_SIZE;
+}
+
/*
* NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
* (ie clustered apic addressing mode), this is a LOGICAL apic ID.
@@ -793,25 +814,9 @@ static int do_boot_cpu(int apicid, int cpu, struct
task_struct *idle)
int cpu0_nmi_registered = 0;
unsigned long timeout;
- /* Just in case we booted with a single CPU. */
- alternatives_enable_smp();
-
idle-thread.sp = (unsigned long) (((struct pt_regs *)
(THREAD_SIZE + task_stack_page(idle))) - 1);
- per_cpu(current_task, cpu) = idle;
-#ifdef CONFIG_X86_32
- /* Stack for startup_32 can be just as for start_secondary onwards */
- irq_ctx_init(cpu);
- per_cpu(cpu_current_top_of_stack, cpu) =
- (unsigned long)task_stack_page(idle) + THREAD_SIZE;
-#else
- clear_tsk_thread_flag(idle, TIF_FORK);
- initial_gs = per_cpu_offset(cpu);
-#endif
- per_cpu(kernel_stack, cpu) =
- (unsigned long)task_stack_page(idle) -
- KERNEL_STACK_OFFSET + THREAD_SIZE;
early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu);
initial_code = (unsigned long)start_secondary;
stack_start = idle-thread.sp;
@@ -955,6 +960,8 @@ int native_cpu_up(unsigned int cpu, struct task_struct
*tidle)
/* the FPU context is blank, nobody can own it */
__cpu_disable_lazy_restore(cpu);
+ common_cpu_up(cpu, tidle);
+
err = do_boot_cpu(apicid, cpu, tidle);
if (err) {
pr_err(do_boot_cpu failed(%d) to wakeup CPU#%u\n, err, cpu);
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 1c5e760..8648438 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -441,15 +441,7 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct
*idle)
{
int rc;
- per_cpu(current_task, cpu) = idle;
-#ifdef CONFIG_X86_32
- irq_ctx_init(cpu);
-#else
- clear_tsk_thread_flag(idle, TIF_FORK);
-#endif
- per_cpu(kernel_stack, cpu) =
- (unsigned long)task_stack_page(idle) -
- KERNEL_STACK_OFFSET + THREAD_SIZE;
+ common_cpu_up(cpu, idle);
xen_setup_runstate_info(cpu);
xen_setup_timer(cpu);
@@ -470,10 +462,6 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct
*idle)
if (rc)
return rc;
- if (num_online_cpus() == 1)
- /* Just in case we booted with a single CPU. */
- alternatives_enable_smp();
-
rc = xen_smp_intr_init(cpu);
if (rc)
return rc;
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 07/33] xen: guestcopy: Provide an helper to safely copy string from guest
On 31/03/15 14:49, Andrew Cooper wrote: On 31/03/15 14:30, Julien Grall wrote: Furthermore, two size parameters serves no useful purpose. The caller must always be in a position to decide a plausible upper bound. I don't understand the problem to have two size parameters... The first one is the size given by the guest while the second one if the upper bound. The maximum size may change from every caller. Hence the second size parameter. The caller shouldn't even be calling safe_copy_string_from_guest() with a guest-controlled-implausibly-large size. The caller should be doing something like: if ( usersize PLAUSIBLE_UPPER_BOUND ) ... fail else data = safe_copy_string_from_guest(hnd, usersize). Mixing plausibility checks and string copying in a single function is a antipattern, and IMO should not be moved into a common helper function like this. Why it's an antipattern? It's exactly the same as checking the validity of the buffer in copy_from_guest... safe_copy-string_from_guest will fail if the size is too high. Caller of this function may forget to do the check and introduce a security issue. Having the check in safe_copy_string_from_guest avoid this problem. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 3/6] sg-report-flight: Sort email output by results, not job name
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-report-flight | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index d2aff58..2adc8a8 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -541,16 +541,21 @@ END
my $text= (sprintf %-${jl}s %2s %-${sl}s %-${rl}s ,
$j-{job}, $s-{stepno}, $s-{testid}, $s-{status});
-$text .= in $failv-{Flight} if $heisenflightp;
-$text .= $failv-{Summary} if defined $failv-{Summary};
+ my $xstatus = '';
+$xstatus .= in $failv-{Flight} if $heisenflightp;
+$xstatus .= $failv-{Summary} if defined $failv-{Summary};
+ $text .= $xstatus;
$text =~ s/ *$//;
while (length($text) $cw) { last unless $text =~ s/(.* ) /$1/; }
-$notsucceeds{$cat} .= $text.\n;
+ push @{ $notsucceeds{$cat} }, [ $s-{status} $xstatus, $text ];
}
foreach my $cat (sort keys %notsucceeds) {
$cat =~ m/^\w+ / or die;
-print \n$'\n$notsucceeds{$cat} or die $!;
+print \n$'\n or die $!;
+ foreach (sort { $a-[0] cmp $b-[0] } @{ $notsucceeds{$cat} }) {
+ print $_-[1], \n or die $!;
+ }
}
if (!%{ $r-{Failures} }) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 5/6] ts-host-ping-check: New ubiquitous test step
Check that packet loss is within acceptable levels.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-run-job |2 ++
ts-host-ping-check | 39 +++
2 files changed, 41 insertions(+)
create mode 100755 ts-host-ping-check
diff --git a/sg-run-job b/sg-run-job
index a1ff24b..3bdb5aa 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -51,8 +51,10 @@ proc run-job {job} {
if {$ok} { setstatus running }
per-host-ts broken host-install/@(*) ts-host-install-twice
+per-host-ts . host-ping-check-native/@ ts-host-ping-check
per-host-ts . xen-install/@ ts-xen-install
per-host-ts . xen-boot/@ts-host-reboot
+per-host-ts . host-ping-check-xen/@ ts-host-ping-check
per-host-ts . =(*) {ts-leak-check basis}
diff --git a/ts-host-ping-check b/ts-host-ping-check
new file mode 100755
index 000..74c008c
--- /dev/null
+++ b/ts-host-ping-check
@@ -0,0 +1,39 @@
+#!/usr/bin/perl -w
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+use strict qw(vars);
+use Osstest;
+use DBI;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+$_ = `ping -D -i 0.2 -c 100 $ho-{Ip} | tee /dev/stderr`;
+
+m/\b([0-9.]+)% packet loss\b/ or die $_ ?;
+
+my $loss= $1;
+
+logm(packet loss $loss\%);
+
+die if $loss 1;
+
+logm(ok.);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 0/6] Un-pushed support patches for new colo
These 6 patches were developed as part of deploying the new colo, and have been used ad-hoc by me in my own ~, but not yet sent into production. They can also be found in: xenbits.xen.org:/home/iwj/ext/osstest#colo.2015-03-31 Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 4/6] sg-report-flight: Produce better output for running jobs.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-report-flight |8
1 file changed, 8 insertions(+)
diff --git a/sg-report-flight b/sg-report-flight
index 2adc8a8..18a5afa 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -664,6 +664,14 @@ END
print MRO broken-step $s-{job} $s-{testid}\n;
}
+ if ($st eq 'running') {
+ print MRO running $j-{job} $s-{testid}\n;
+ print DEBUG running, unjustifiable\n;
+ $failv-{Summary}= '';
+ $failv-{Blocker}= 'unfinished';
+ next;
+ }
+
if (!($st eq 'fail' or $st eq 'broken')) {
print MRO broken $j-{job} $s-{testid} $st\n;
print DEBUG not a fail, unjustifiable\n;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 0/2] (Re)Add production config for Cambridge instance
Although it is no longer the production instance I'd like to be able to use it for ad-hoc testing. I don't think there are so many other osstest instances in the world that we cannot tolerate having all of their configurations in the main repo if that is desired by the owners of the instances. (I don't know who else has such an instance, or I would CC them) Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
