[Xen-devel] [PATCH v7 0/2] add new p2m type class and new p2m type

[Yu Zhang]

XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory pages used by guest graphics
driver as PPGTT(per-process graphics translation table). We added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations on these graphic page tables. 

Handling of this new p2m type are similar with existing p2m_ram_ro
in most condition checks, with only difference on final policy of
emulation vs. drop. For p2m_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the p2m_mmio_write_dm type pages, writes will go to the
device model via ioreq-server.

Previously, the conclusion in our v3 patch review is to provide a
more generalized HVMOP_map_io_range_to_ioreq_server hypercall, by
seperating rangesets inside a ioreq server to read-protected/write-
protected/both-prtected. Yet, after offline discussion with Paul,
we believe a more simplified solution may suffice. We can keep the 
existing HVMOP_map_io_range_to_ioreq_server hypercall, and let the 
user decide whether or not a p2m type change is necessary, because
in most cases the emulator will already use the p2m_mmio_dm type.


Changes from v6:
 - Handle the new p2m type in the shadow-pagetable code.

Changes from v5:
 - Stricter type checks for p2m type transitions;
 - One code style change.

Changes from v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

Changes from v3:
 - Use the existing HVMOP_map_io_range_to_ioreq_server hypercall
   to add write protected range;
 - Modify the HVMOP_set_mem_type hypercall to support the new p2m
   type for this range.

Changes from v2:
 - Remove excute attribute of the new p2m type p2m_mmio_write_dm;
 - Use existing rangeset for keeping the write protection page range
   instead of introducing hash table;
 - Some code style fix.

Changes from v1:
 - Changes the new p2m type name from p2m_ram_wp to p2m_mmio_write_dm.
   This means that we treat the pages as a special mmio range instead
   of ram;
 - Move macros to c file since only this file is using them.
 - Address various comments from Jan.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c  | 25 ++---
 xen/arch/x86/mm/p2m-ept.c   |  1 +
 xen/arch/x86/mm/p2m-pt.c|  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h   |  9 -
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v2] domctl: fix IRQ permission granting/revocation

[Jan Beulich]

Commit 545607eb3c (x86: fix various issues with handling guest IRQs)
wasn't really consistent in one respect: The granting of access to an
IRQ shouldn't assume the pIRQ-IRQ translation to be the same in both
domains. In fact it is wrong to assume that a translation is already/
still in place at the time access is being granted/revoked.

What is wanted is to translate the incoming pIRQ to an IRQ for
the invoking domain (as the pIRQ is the only notion the invoking
domain has of the IRQ), and grant the subject domain access to
the resulting IRQ.

Signed-off-by: Jan Beulich jbeul...@suse.com
---
v2: Also fix initial range check to use current-domain, adjust code
structure, and extend description (all requested by Ian). Along
the lines of the first mentioned change, also pass the Xen IRQ
number to the XSM hook (confirmed okay by Daniel).
Note that I would hope for this to make unnecessary Stefano's proposed
tools side change
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
 
 case XEN_DOMCTL_irq_permission:
 {
-unsigned int pirq = op-u.irq_permission.pirq;
+unsigned int pirq = op-u.irq_permission.pirq, irq;
 int allow = op-u.irq_permission.allow_access;
 
-if ( pirq = d-nr_pirqs )
+if ( pirq = current-domain-nr_pirqs )
+{
 ret = -EINVAL;
-else if ( !pirq_access_permitted(current-domain, pirq) ||
-  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
+break;
+}
+irq = pirq_access_permitted(current-domain, pirq);
+if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
 ret = -EPERM;
 else if ( allow )
-ret = pirq_permit_access(d, pirq);
+ret = irq_permit_access(d, irq);
 else
-ret = pirq_deny_access(d, pirq);
+ret = irq_deny_access(d, irq);
 }
 break;
 
--- a/xen/include/xen/iocap.h
+++ b/xen/include/xen/iocap.h
@@ -28,22 +28,11 @@
 #define irq_access_permitted(d, i)  \
 rangeset_contains_singleton((d)-irq_caps, i)
 
-#define pirq_permit_access(d, i) ({ \
-struct domain *d__ = (d);   \
-int i__ = domain_pirq_to_irq(d__, i);   \
-i__  0 ? rangeset_add_singleton(d__-irq_caps, i__)\
-: -EINVAL;  \
-})
-#define pirq_deny_access(d, i) ({   \
-struct domain *d__ = (d);   \
-int i__ = domain_pirq_to_irq(d__, i);   \
-i__  0 ? rangeset_remove_singleton(d__-irq_caps, i__)\
-: -EINVAL;  \
-})
 #define pirq_access_permitted(d, i) ({  \
 struct domain *d__ = (d);   \
-rangeset_contains_singleton(d__-irq_caps,  \
-domain_pirq_to_irq(d__, i));\
+int irq__ = domain_pirq_to_irq(d__, i); \
+irq__  0  irq_access_permitted(d__, irq__)   \
+? irq__ : 0;\
 })
 
 #endif /* __XEN_IOCAP_H__ */




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

Re: [Xen-devel] Few Comments on the Xen SMMU ARM code

[Ian Campbell]

On Thu, 2014-12-11 at 10:02 -0800, manish jaggi wrote:
 This is the complete smmu.c file which you can refer for PCI
 passthrough (http://pastebin.com/QDX8fpDu)

I'm afraid that as Julien says this is basically no help.

 Just FYI this is not a patch, we are still testing on our board and
 can post a patch only after our testing is complete.

Please post whatever patch(es) you have now with a WIP (Work In
Progress) tag in the subject. It does not need to be complete, working,
tested or clean. You can put a big fat warning on the commit log if you
like. See for example
http://article.gmane.org/gmane.comp.emulators.xen.devel/220265 where I
did exactly this with some very dirty patches I was halfway through
writing[0] (I used incomplete rather than WIP, the exact words don't
really matter).

If you have any design documentation then please include that as well,
e.g. in the 0/N mail.

IMHO seeing what you have actually done which is leading to the
questions you are asking is a prerequisite to having any sort of
constructive discussion about the design decisions going forward. I'd
certainly want to see the code before any call takes place.

Cheers,
Ian.

[0] in this case because I wasn't going to be able to finish them soon
and it was better to get them onto the list than rotting in my dev tree.


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

Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission granting/revocation

[Ian Campbell]

On Fri, 2014-12-12 at 11:03 +, Jan Beulich wrote:
  On 12.12.14 at 11:49, andrew.coop...@citrix.com wrote:
  On 12/12/14 10:24, Jan Beulich wrote:
  Commit 545607eb3c (x86: fix various issues with handling guest IRQs)
  wasn't really consistent in one respect: The granting of access to an
  IRQ shouldn't assume the pIRQ-IRQ translation to be the same in both
  domains. In fact it is wrong to assume that a translation is already/
  still in place at the time access is being granted/revoked.
 
  What is wanted is to translate the incoming pIRQ to an IRQ for
  the invoking domain (as the pIRQ is the only notion the invoking
  domain has of the IRQ), and grant the subject domain access to
  the resulting IRQ.
 
  Signed-off-by: Jan Beulich jbeul...@suse.com
  
  Should domain_pirq_to_irq() be using 0 as its default invalid value,
  rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
  passed through to a guest.
 
 Not on x86. If another architecture would ever need this, I think
 we'd need to audit all current users of domain_pirq_to_irq() before
 doing such a change.

FWIW on ARM (at least the versions we support, i.e. with the generic IRQ
controller) IRQ0 is an SGI (what x86 would call an IPI). It seems
unlikely we'd want to pass one of those through...

Ian.


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

Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd

[Olaf Hering]

On Fri, Dec 12, Ian Campbell wrote:

 Seems ok. I wonder if the wrapper ought to source
 @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
 rather than relying on the initscript and unit file to do so. Especially
 in the initscript case it looks a bit ugly to have to manually propagate
 things.

It seems all that wrapping is of no use because SELinux can not deal
with it. I will see if ExecStart=/bin/ary --no-fork $ENVVAR can be
used to pass additional arguments. If so, the current XENSTORED_TRACE
handling has to be removed in favour of XENSTORED_ARGS=.

Olaf

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

[Xen-devel] [xen-unstable test] 32245: tolerable FAIL - PUSHED

[xen . org]

flight 32245 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32245/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32198

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail 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
 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-qemuu-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-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 xen  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
baseline version:
 xen  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db


People who touched revisions under test:
  Daniel De Graaf dgde...@tycho.nsa.gov
  Ian Campbell ian.campb...@citrix.com
  Ian Jackson ian.jack...@eu.citrix.com
  Julien Grall julien.gr...@linaro.org
  Olaf Hering o...@aepfle.de


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   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-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
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-rumpuserxen-i386   

[Xen-devel] [PATCH for-4.6 3/4] xen/arm: vgic: notice if the vIRQ is not allocated when the guest enable it

[Julien Grall]

This help for guest interrupts debugging. If the vIRQ is not allocate,
this means that nothing is wired to it.

Signed-off-by: Julien Grall julien.gr...@linaro.org
---
 xen/arch/arm/vgic.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index dbfc259..719cb9f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -282,6 +282,10 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 if ( !list_empty(p-inflight)  !test_bit(GIC_IRQ_GUEST_VISIBLE, 
p-status) )
 gic_raise_guest_irq(v_target, irq, p-priority);
 spin_unlock_irqrestore(v_target-arch.vgic.lock, flags);
+
+if ( !test_bit(irq, d-arch.vgic.allocated_irqs) )
+gdprintk(XENLOG_DEBUG, vIRQ %u is not allocated\n, irq);
+
 if ( p-desc != NULL )
 {
 irq_set_affinity(p-desc, cpumask_of(v_target-processor));
-- 
2.1.3


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

[Xen-devel] [PATCH for-4.6 1/4] xen/arm: vgic: Rename nr_lines into nr_spis

[Julien Grall]

The field nr_lines in the arch_domain vgic structure contains the number of
SPIs for the emulated GIC. Using the nr_lines make confusion with the GIC
code, where it means the number of IRQs. This can lead to coding error.

Also introduce vgic_nr_lines to get the number of IRQ handled by the emulated
GIC.

Signed-off-by: Julien Grall julien.gr...@linaro.org
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com

---
It was part of the platform device passthrough series: 
https://patches.linaro.org/34661/

Stefano: I've kept your ack from the previous version. Let me know
if there is any issue.

Changes in v3:
- Add acked-by from Stefano.
- Update the patch to also modify GICv3 code which has been
pushed recently

Changes in v2:
- Patch added.
---
 xen/arch/arm/gic-v2.c|  2 --
 xen/arch/arm/gic-v3.c|  2 +-
 xen/arch/arm/vgic-v2.c   |  2 +-
 xen/arch/arm/vgic-v3.c   |  2 +-
 xen/arch/arm/vgic.c  | 15 ++-
 xen/include/asm-arm/domain.h |  2 +-
 xen/include/asm-arm/vgic.h   |  4 +++-
 7 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..31fb81a 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -432,8 +432,6 @@ static int gicv2v_setup(struct domain *d)
 d-arch.vgic.cbase = GUEST_GICC_BASE;
 }
 
-d-arch.vgic.nr_lines = 0;
-
 /*
  * Map the gic virtual cpu interface in the gic cpu interface
  * region of the guest.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..ec48fc1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -922,7 +922,7 @@ static int gicv_v3_init(struct domain *d)
 d-arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
 }
 
-d-arch.vgic.nr_lines = 0;
+d-arch.vgic.nr_spis = 0;
 
 return 0;
 }
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 1369f78..039e19a 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -54,7 +54,7 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info)
 /* No secure world support for guests. */
 vgic_lock(v);
 *r = ( (v-domain-max_vcpus  5)  GICD_TYPE_CPUS )
-|( ((v-domain-arch.vgic.nr_lines / 32))  GICD_TYPE_LINES );
+|( ((v-domain-arch.vgic.nr_spis / 32))  GICD_TYPE_LINES );
 vgic_unlock(v);
 return 1;
 case GICD_IIDR:
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ff99e50..2785c10 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -668,7 +668,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info)
 if ( dabt.size != DABT_WORD ) goto bad_width;
 /* No secure world support for guests. */
 *r = (((v-domain-max_vcpus  5)  GICD_TYPE_CPUS ) |
-  ((v-domain-arch.vgic.nr_lines / 32)  GICD_TYPE_LINES));
+  ((v-domain-arch.vgic.nr_spis / 32)  GICD_TYPE_LINES));
 return 1;
 case GICD_STATUSR:
 /*
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..75cb7ff 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -66,13 +66,10 @@ int domain_vgic_init(struct domain *d)
 
 d-arch.vgic.ctlr = 0;
 
-/* Currently nr_lines in vgic and gic doesn't have the same meanings
- * Here nr_lines = number of SPIs
- */
 if ( is_hardware_domain(d) )
-d-arch.vgic.nr_lines = gic_number_lines() - 32;
+d-arch.vgic.nr_spis = gic_number_lines() - 32;
 else
-d-arch.vgic.nr_lines = 0; /* We don't need SPIs for the guest */
+d-arch.vgic.nr_spis = 0; /* We don't need SPIs for the guest */
 
 switch ( gic_hw_version() )
 {
@@ -96,11 +93,11 @@ int domain_vgic_init(struct domain *d)
 return -ENOMEM;
 
 d-arch.vgic.pending_irqs =
-xzalloc_array(struct pending_irq, d-arch.vgic.nr_lines);
+xzalloc_array(struct pending_irq, d-arch.vgic.nr_spis);
 if ( d-arch.vgic.pending_irqs == NULL )
 return -ENOMEM;
 
-for (i=0; id-arch.vgic.nr_lines; i++)
+for (i=0; id-arch.vgic.nr_spis; i++)
 {
 INIT_LIST_HEAD(d-arch.vgic.pending_irqs[i].inflight);
 INIT_LIST_HEAD(d-arch.vgic.pending_irqs[i].lr_queue);
@@ -218,7 +215,7 @@ void arch_move_irqs(struct vcpu *v)
 struct vcpu *v_target;
 int i;
 
-for ( i = 32; i  (d-arch.vgic.nr_lines + 32); i++ )
+for ( i = 32; i  vgic_num_irqs(d); i++ )
 {
 v_target = vgic_get_target_vcpu(v, i);
 p = irq_to_pending(v_target, i);
@@ -344,7 +341,7 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
gic_sgi_mode irqmode, int
 struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 {
 struct pending_irq *n;
-/* Pending irqs allocation strategy: the first vgic.nr_lines irqs
+/* Pending irqs allocation strategy: the first vgic.nr_spis irqs
  * are used for SPIs; the 

[Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a PPI for the DOM0 event channel interrupt

[Julien Grall]

Use the new vgic interface to know which virtual PPI is free and use it
for the event channel code.

At the DOM0 creation time, Xen still don't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So allocate
when the hypervisor node is created.

It's safe to defer the allocation because no vIRQ can be injected as
long as the vCPU is not online.

Also correct the check in arch_domain_create to use is_hardware_domain.

Signed-off-by: Julien Grall julien.gr...@linaro.org
---
 xen/arch/arm/domain.c| 13 ++---
 xen/arch/arm/domain_build.c  | 10 ++
 xen/arch/arm/platform.c  |  7 ---
 xen/arch/arm/platforms/xgene-storm.c |  1 -
 xen/include/asm-arm/platform.h   |  4 
 5 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..7d14377 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags)
 if ( (rc = domain_vtimer_init(d)) != 0 )
 goto fail;
 
-if ( d-domain_id )
+/*
+ * The hardware domain will get a PPI later in
+ * arch/arm/domain_build.c  depending on the
+ * interrupt map of the hardware.
+ */
+if ( !is_hardware_domain(d) )
+{
 d-arch.evtchn_irq = GUEST_EVTCHN_PPI;
-else
-d-arch.evtchn_irq = platform_dom0_evtchn_ppi();
+/* At this stage vgic_reserve_virq should never fail */
+BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
+}
 
 /*
  * Virtual UART is only used by linux early printk and decompress code.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c238c8f..8dedc60 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -625,6 +625,16 @@ static int make_hypervisor_node(struct domain *d,
 return res;
 
 /*
+ * The allocation of the event channel IRQ has been deferred until
+ * now. At this time, all PPIs use by DOM0 has been registered
+ */
+res = vgic_allocate_virq(d, 0);
+if ( res  0 )
+return -FDT_ERR_XEN(ENOSPC);
+
+d-arch.evtchn_irq = res;
+
+/*
  * interrupts is evtchn upcall:
  *  - Active-low level-sensitive
  *  - All cpus
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..d016797 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -160,13 +160,6 @@ bool_t platform_device_is_blacklisted(const struct 
dt_device_node *node)
 return dt_match_node(blacklist, node);
 }
 
-unsigned int platform_dom0_evtchn_ppi(void)
-{
-if ( platform  platform-dom0_evtchn_ppi )
-return platform-dom0_evtchn_ppi;
-return GUEST_EVTCHN_PPI;
-}
-
 void platform_dom0_gnttab(paddr_t *start, paddr_t *size)
 {
 if ( platform  platform-dom0_gnttab_size )
diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 416d42c..b0808b8 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -232,7 +232,6 @@ PLATFORM_START(xgene_storm, APM X-GENE STORM)
 .quirks = xgene_storm_quirks,
 .specific_mapping = xgene_storm_specific_mapping,
 
-.dom0_evtchn_ppi = 24,
 .dom0_gnttab_start = 0x1f80,
 .dom0_gnttab_size = 0x2,
 PLATFORM_END
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index eefaca6..4eba37b 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -38,10 +38,6 @@ struct platform_desc {
  */
 const struct dt_device_match *blacklist_dev;
 /*
- * The IRQ (PPI) to use to inject event channels to dom0.
- */
-unsigned int dom0_evtchn_ppi;
-/*
  * The location of a region of physical address space which dom0
  * can use for grant table mappings. If size is zero defaults to
  * 0xb000-0xb002.
-- 
2.1.3


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

Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN

[Andrew Cooper]

On 12/12/14 12:27, Chao Peng wrote:
 Hi all, we plan to bring Intel CAT into XEN. This is the initial
 design for that. Comments/suggestions are welcome.

 Background
 ==
 Traditionally, all Virtual Machines (VMs) share the same set of system
 cache resources. There is no hardware support to control allocation or
 availability of cache resources to individual VMs. The lack of such
 partition mechanism for cache resource makes the cache utilization for
 different types of VMs inefficient. While on the other side, more and
 more cache resources become available on modern server platforms.

 With the introduction of Intel Cache Allocation Technology (CAT), now
 Virtualization Machine Monitor (VMM) has the ability to partition the
 cache allocation per VM, based on the priority of VM.


 CAT Introduction
 
 Generally speaking, CAT introduces a mechanism for software to enable
 cache allocation based on application priority or Class of Service
 (COS). Cache allocation for the respective applications is then
 restricted based on the COS with which they are associated. Each COS can
 be configured using capacity bitmasks (CBM) which represent cache
 capacity and indicate the degree of overlap and isolation between
 classes. For each logical processor there is a register
 exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
 application, thread or VM is scheduled. Cache allocation for the
 indicated application/thread/VM is then controlled automatically by the
 hardware based on the COS and the CBM associated with that class.
 Hardware initializes COS of each logical processor to 0 and the
 corresponding CBM is set to all-ones, means all the system cache
 resource can be used for each application.

 For more information please refer to Section 17.15 in the Intel SDM [1].


 Design Overview
 ===
 - Domain COS/CBM association
 When enforcing cache allocation for VMs, the minimum granularity is
 defined as the domain. All Virtual CPUs (VCPUs) of a domain have the
 same COS, and therefore, correspond to the same CBM. COS is used only in
 hypervisor and is transparent to tool stack/user. System administrator
 can specify the initial CBM for each domain or change it at runtime using 
 tool stack. Hypervisor then choses a free COS to associate it with that
 CBM or find a existed COS which has the same CBM.

 - VCPU Schedule
 When VCPU is scheduled on the physical CPU (PCPU), its COS value is
 then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
 the new COS. The cache allocation is then enforced by hardware.

 - Multi-Socket
 In multi-socket environment, each VCPU may be scheduled on different
 sockets. The hardware CAT ability(such as maximum supported COS and length
 of CBM) maybe different among sockets. For such system, per-socket COS/CBM
 configuration of a domain is specified. Hypervisor then use this per-socket
 CBM information for VCPU schedule.


 Implementation Description
 ==
 In this design, one principal is that only implementing the cache
 enforcement mechanism in hypervisor but leaving the cache allocation
 policy to user space tool stack. In this way some complex governors then
 can be implemented in tool stack. 

 In summary, hypervisor changes include:
 1) A new field cat_info in domain structure to indicate the CAT
information for each socket. It points to array of structure:
struct domain_socket_cat_info {
unsigned int cbm; /* CBM specified by toolstack  */
unsigned int cos; /* COS allocated by Hypervisor */
}
 2) A new SYSCTL to expose the CAT information to tool stack:
  * Whether CAT is enabled;
  * Max COS supported;
  * Length of CBM;
  * Other needed information from host cpuid;
 3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
for each socket.
 4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
 5) XSM policy to restrict the functions visibility to control domain only.

 Hypervisor interfaces:
 1) Boot line param: psr=cat to enable the feature.
 2) SYSCTL: XEN_SYSCTL_psr_cat_op
  - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
 3) DOMCTL: XEN_DOMCTL_psr_cat_op
  - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
  - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.

 xl interfaces:
 1) psr-cat-show: Show system/runtime CAT information.
  = XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
 2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
  = XEN_DOMCTL_PSR_CAT_OP_CBM_SET


 Hardware Limitation  Performance Improvement
 =
 As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
 switch. If the change is frequent then hardware may fail to strictly
 enforce the cache allocation basing on the specified COS. Due to this
 the strict placement characteristic would soften if VCPU is 

Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd

[Olaf Hering]

On Fri, Dec 12, Olaf Hering wrote:

 This works:
 ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS
 
 This fails:
 ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS

But this will likely work:
ExecStart=/usr/bin/env $XENSTORED --no-fork $XENSTORED_ARGS


Let me know how to proceed...

Olaf

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

Re: [Xen-devel] Porting document

[Ian Campbell]

On Mon, 2014-12-08 at 15:47 +, Frediano Ziglio wrote:
 Hi,
   while I was porting D01 platform
 (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
 trying to describe the step I made and problems I encountered hoping
 it could useful to other people. The idea is to put such documentation
 in a wiki page or in the docs directory.
 
 Let me know what do you think.

I've only skimmed the headings etc but I see no harm in posting it
somewhere publicly. I don't know if wiki or in tree docs would be
better. Maybe just post it on the list? At least then it will be in the
archives.

Ian.



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

Re: [Xen-devel] xenstored crashes with SIGSEGV

[Philipp Hahn]

Hello,

On 13.11.2014 10:12, Ian Campbell wrote:
 On Thu, 2014-11-13 at 08:45 +0100, Philipp Hahn wrote:
 To me this looks like some memory corruption by some unknown code
 writing into some random memory space, which happens to be the tdb here.
 
 I wonder if running xenstored under valgrind would be useful. I think
 you'd want to stop xenstored from starting during normal boot and then
 launch it with:
 valgrind /usr/local/sbin/xenstored -N
 -N is to stay in the foreground, you might want to do this in a screen
 session or something, alternatively you could investigate the --log-*
 options in the valgrind manpage, together with the various
 --trace-children* in order to follow the processes over its
 daemonization.

We did enable tracing and now have the xenstored-trace.log of one crash:
It contains 1.6 billion lines and is 83 GiB.
It just shows xenstored to crash on TRANSACTION_START.

Is there some tool to feed that trace back into a newly launched xenstored?

My hope would be that xenstored crashes again, because then we could use
all those other tools like valgrind more easily.

 3. the crash happens rarely and the host run fine most of the time. The
 crash mostly happens around midnight and seem to be guest-triggered, as
 the logs on the host don't show any activity like starting new or
 destroying running VMs. So far the problem only showed on host running
 Linux VMs. Other host running Windows VMs so far never showed that crash.

Now we also observed a crash on a host running Windows VMs.

 If it is really mostly happening around midnight then it might be worth
 digging into the host and guest configs for cronjobs and the like, e.g.
 log rotation stuff like that which might be tweaking things somehow.
 
 Does this happen on multiple hosts, or just the one?

Multiple host in two different data centers.

 Do you rm the xenstore db on boot? It might have a persistent
 corruption, aiui most folks using C xenstored are doing so or even
 placing it on a tmpfs for performance reasons.

We're using a tmpfs for /var/lib/xenstored/, as we had some sever
performance problem with something updating
/local/domain/0/backend/console/*/0/uuid too often, which put xenstored
in permanent D state.

 If you are running 4.1.x then I think oxenstored isn't an option, but it
 might be something to consider when you upgrade.

Thank you for the hint, I'll have another look at the Ocaml version.

Thank you again.
Philipp Hahn

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

Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design

[Ian Campbell]

On Tue, 2014-12-09 at 20:46 -0700, Chun Yan Liu wrote:
 
  On 12/9/2014 at 07:11 PM, in message 
  1418123518.14361.20.ca...@citrix.com,
 Ian Campbell ian.campb...@citrix.com wrote: 
  On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote: 
   Partly. At least for domain disk snapshot create/delete, I prefer using 
   qmp commands instead of calling qemu-img one by one. Using qmp 
   commands, libvirt will need libxl's help. Of course, if libxl doesn't 
   supply that, libvirt can call qemu-img to each disk one by one, 
   not preferred but can do. 
   
  You can't use qmp unless the domain is active, for an inactive domain 
  there is no qemu to talk to, so you have to use qemu-img anyway in that 
  case. Does libvirt not have existing code to do all this sort of thing? 
  (I thought so, but it turns out I may be wrong, see below). 
 
 No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through
 qemu monitor commands.

Is this just the code for the actual act of taking a snapshot or is it a
complete snapshotting infrastructure in the driver itself?

I would hope/assume that there was a split between the common code which
drives everything and tracks all the state etc and the specific driver
backend which is used to make state changes to active domains. Is that
the case or is everything snapshot related in the libvirt qemu_driver?

  And for an active domain I expect that *must* use qmp, since it seems 
  unlikely that you can go around changing things under the feet of an 
  active process (maybe I'm wrong?).
 
 For active domain, I tried 'qemu-img snapshot' after pausing a domain,
 the commands succeeded. But I also think using qmp commands is better
 since qemu supplies transaction qmp, it avoids the trouble to roll back
 status when using qemu-img to do disk snapshot one by one but only part of
 disks succeed.

Yes, using qmp for an active domain seems sensible.

But you can't use qmp on an inactive domain. Does libvirt deal with this
in common code or does it require two code paths in the backend driver,
one for active and one for inactive domains?

 So, if disk snapshot functions can be provided to both libvirt and xl usage,
 it's very helpful to libvirt side. In this way, I may prefer to put disk 
 snapshot
 functions to libxlu.

The actual command to snapshot a disk of an active+paused domain is fine
to go into libxl. In fact due to the proposed use of qmp it would have
to be.

Anything to do with the subsequent management of snapshots most likely
doesn't belong in libxl. Whether that stuff belongs in libxlu, xl or
libvirt depends on what scope there is for multiple toolstacks to use a
given helper function.

  My understanding was that your primary aim here was to enable snapshots 
  via libvirt and that xl support was just a nice to have. Is that right? 
 
 We hope both :-)

OK, thanks for clarifying.

 Libvirt side already has some codes as I know and hopes to integrate with
 libxl to enable snapshots. Of course the two toolstacks can have some
 differences in commands, that's OK.
 
 Libvirt side, to use unified virsh commands, it will supply
 snapshot-create/delete/revert/list.

This is what I expected you were aiming for.

 Xl side, if it's better to supply snapshot-create/revert, we can implement
 like that. Then it IS much easier since no need to manage snapshots in xl,
 then no save/retrieve json file things and no snapshot chain things. Do
 we want/decide to follow this?

The xl snapshot functionality should be kept as simple as possible and
following the existing xl idioms of managing storage and saved VM images
via existing CLI command (qemu-img, lvcreate, ls, mv, cp etc).

Ian.


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

Re: [Xen-devel] patches pending acks (or naks)

[Konrad Rzeszutek Wilk]

On Fri, Dec 12, 2014 at 09:45:17AM +, Jan Beulich wrote:
  On 11.12.14 at 20:41, konrad.w...@oracle.com wrote:
  On Thu, Dec 11, 2014 at 03:38:39PM +, Jan Beulich wrote:
   On 11.12.14 at 16:18, konrad.w...@oracle.com wrote:
   A proper fix would be to automatically adjust based on memmap and CPU 
   but 
   that could be too complex.
  
  The problem isn't the complexity, but the chicken-and-egg problem
  as far as CPU count is concerned. The memory map size would be
  known early enough.
  
  Let me explain my thought process:
   - There are existing knobs that can be used to change this (conring_size=X)
   - But we would like an awesome release where those knobs don't have to
 be used.
   - The patch you posted could be reworked to fully address memmap and CPU.
 
 Not really, unless we separate parsing and printing of the ACPI
 tables. Again, the CPU count is known only after that parsing.

Right, the logic of increasing the buffer based on CPU count is an
excellent addition.
 
   - I don't know what your time constraints are for said patch and you
 might not have the energy to rework it.
   - I don't want to put pressure on you or Daniel on having to write new
 patches - especially as folks are going on vacation soon.
  
  Hence as a fallback I believe that Daniel's patch should go in and
  Jan's patch can go in too. However if Jan (or somebody else) wants to
  rework the v2 (or a new one) to address the memmap issue then that
  patch would go in - instead of Daniel's or v2 of Jan patch.
 
 Which memmap issue? You confirmed in your reply that you understand
 that the memmap gets printed late enough for the change in v2 to
 take effect. Plus those are info-level messages, and hence don't get

Correct. The count of memmap entries can be high even with an
small amount of CPUs. Meaning your patch would not modify the
size of the circular buffer in such case (and we would lose some
of the memmap entries being printed). Daniel's patch would
provide a cushion by expanding the default size, however ..

 printed at all by default. And if somebody alters the log levels, (s)he
 can surely be expected to also adjust the ring size. (The log level
 aspect is actually another argument against Daniel's patch.)

... your point about the need to use 'loglvl' points out that
Daniel's patch does not fix the all-generic case.

/me puts on the Xen 4.6 todo 'adjust log buffer based on memmap size'

And your patch is:
Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com


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

Re: [Xen-devel] [PATCH for-4.5] reset PCI devices on force removal even when QEMU returns error

[Konrad Rzeszutek Wilk]

On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
 Hi Konrad,
 
 This doesn't seem to be applied yet, nor does it seem to have a 
 release-(N)ACK 
 from you ?

Hm, Stefano:

- Is this a regression?

- What are the risks of this not going in? I presume that it just means
  we haven't reset it in sysfs. But the xc_deassign_device operation
  if not done will not affect the hypervisor - which will move the
  device to dom0 upon guest teardown.

 
 --
 Sander
 
 
 
 Friday, November 28, 2014, 5:53:09 PM, you wrote:
 
  On do_pci_remove when QEMU returns error, we just bail out early without
  resetting the device. On domain shutdown we are racing with QEMU exiting
  and most often QEMU closes the QMP connection before executing the
  requested command.
 
  In these cases if force=1, it makes sense to go ahead with rest of the
  PCI device removal, that includes resetting the device and calling
  xc_deassign_device. Otherwise we risk not resetting the device properly
  on domain shutdown.
 
  Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
 
  diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
  index 316643c..0ac0b93 100644
  --- a/tools/libxl/libxl_pci.c
  +++ b/tools/libxl/libxl_pci.c
  @@ -1243,7 +1245,7 @@ static int do_pci_remove(libxl__gc *gc, uint32_t 
  domid,
   rc = ERROR_INVAL;
   goto out_fail;
   }
  -if (rc) {
  +if (rc  !force) {
   rc = ERROR_FAIL;
   goto out_fail;
   }
 
 

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

Re: [Xen-devel] Xen's Linux kernel config options

[David Vrabel]

On 12/12/14 13:17, Juergen Gross wrote:
 
 
 As a first draft I'd suggest the following:

Some rough thoughts below.

 Option  Selects Depends
 --
 XEN SWIOTLB_XEN(arm,arm64)

XEN should get you basic support for making hypercalls and allowing
guest to identify themselves as running on Xen.  I don't think it should
select SWIOTLB_XEN even on ARM as it is only needed for guests with
access to real hardware.

   XEN_PV(x86)   XEN_HAVE_PVMMU
 PARAVIRT
 PARAVIRT_CLOCK
   XEN_PVH(x86)  XEN_PVHVM
 PARAVIRT
 PARAVIRT_CLOCK
   XEN_BACKEND   XEN_PV(x86) ||
 XEN_PVH(x86) ||
 XEN_PVHVM
 XEN_BLKDEV_BACKEND
 XEN_PCIDEV_BACKEND(x86)
 XEN_SCSI_BACKEND
 XEN_NETDEV_BACKEND
[...]
 XEN_PVHVM

Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.

 XEN_FRONTENDXEN_PV ||
 XEN_PVH ||
 XEN_PVHVM

This enables all the basic infrastructure for frontends: event channels,
grant tables and Xenbus.

Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
possible to have frontend drivers without support for any of the
PV/PVHVM/PVH guest types.  Frontends only need event channels, grant
table and xenbus.

Perhaps have XEN_FRONTEND select XEN instead?

You need an additional option to enable the Xen platform PCI device.
This should depend on XEN_FRONTEND.

   XEN_XENBUS_FRONTEND

Fold this into XEN_FRONTEND?

   XEN_FBDEV_FRONTENDXEN_XENBUS_FRONTEND
 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND   XEN_XENBUS_FRONTEND
   HVC_XEN_FRONTEND  XEN_XENBUS_FRONTEND
 HVC_XEN
   TCG_XEN   XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND   PCI_XEN
 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND XEN_XENBUS_FRONTEND
   XEN_NETDEV_FRONTEND   XEN_XENBUS_FRONTEND
 
 There might be some further adjustments needed (should XEN_DEV_EVTCHN
 and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
 main difference to the current status is the XEN setting no longer
 controlling all other options.

XEN_DEV_EVTCH and XEN_GNTDEV are useful to non-backends (e.g., for
interdomain comms).

David

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

Re: [Xen-devel] xenstored crashes with SIGSEGV

[Ian Campbell]

(adding Ian J who knows a bit more about C xenstored than me...)

 On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
 Hello Ian,
 
 On 12.12.2014 17:56, Ian Campbell wrote:
  On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
  On 12.12.2014 17:32, Ian Campbell wrote:
  On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
  We did enable tracing and now have the xenstored-trace.log of one crash:
  It contains 1.6 billion lines and is 83 GiB.
  It just shows xenstored to crash on TRANSACTION_START.
 
  Is there some tool to feed that trace back into a newly launched 
  xenstored?
 
  Not that I know of I'm afraid.
 
  Okay, then I have to continue with my own tool.
  
  If you do end up developing a tool to replay a xenstore trace then I
  think that'd be something great to have in tree!
 
 I just need to figure out how to talk to xenstored on the wire: for some
 strange reason xenstored is closing the connection to the UNIX socket on
 the first write inside a transaction.
 Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...
 
  Do you get a core dump when this happens? You might need to fiddle with
  ulimits (some distros disable by default). IIRC there is also some /proc
  nob which controls where core dumps go on the filesystem.
 
  Not for that specific trace: We first enabled generating core files, but
  only then discovered that this is not enough.
  
  How wasn't it enough? You mean you couldn't use gdb to extract a
  backtrace from the core file? Or was something else wrong?
 
 The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
 
 (gdb) bt full
 #0  talloc_chunk_from_ptr (ptr=0xff) at talloc.c:116
 tc = value optimized out
 #1  0x00407edf in talloc_free (ptr=0xff) at talloc.c:551
 tc = value optimized out
 #2  0x0040a348 in tdb_open_ex (name=0x1941fb0
 /var/lib/xenstored/tdb.0x1935bb0,

This is interesting actually. There are only a small number of calls to
talloc_free in tdb_open_ex (all wrapped in SAFE_FREE) and they are all
in after the fail: error exit path. So I think the reason the crash is
rare is that you have to hit some other failure first.

About half of the goto fail statements are preceded by a TDB_LOG
statement. But given the presence of logfn=null_log_fn in the trace
that doesn't seem likely to be helpful right now.

It might be worth splurging some debug of your own before each of those
failure points and/or wiring up the tdb log function to xenstores
logging.

The calls to SAFE_FREE are
SAFE_FREE(tdb-map_ptr);
SAFE_FREE(tdb-name);
SAFE_FREE(tdb-locked);
SAFE_FREE(tdb);

I think those should all have been allocated by the time we get to fail
though, so not sure where 0xff00 in the trace comes from.

I've timed out for tonight will try and have another look next week.

Ian.

 hash_size=value optimized out, tdb_flags=0, open_flags=value
 optimized out, mode=value optimized out,
 log_fn=0x4093b0 null_log_fn, hash_fn=value optimized out) at
 tdb.c:1958
 tdb = 0x1921270
 st = {st_dev = 17, st_ino = 816913342, st_nlink = 1, st_mode =
 33184, st_uid = 0, st_gid = 0, __pad0 = 0,
   st_rdev = 0, st_size = 303104, st_blksize = 4096, st_blocks =
 592, st_atim = {tv_sec = 1415748063,
 tv_nsec = 87562634}, st_mtim = {tv_sec = 1415748063, tv_nsec
 = 87562634}, st_ctim = {
 tv_sec = 1415748063, tv_nsec = 87562634}, __unused = {0, 0, 0}}
 rev = value optimized out
 locked = 4232112
 vp = value optimized out
 #3  0x0040a684 in tdb_open (name=0xff Address
 0xff out of bounds, hash_size=0,
 tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
 No locals.
 #4  0x0040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
 /var/lib/xenstored/tdb.0x1935bb0)
 at tdb.c:2124
 fd = value optimized out
 saved_errno = value optimized out
 copy = 0x0
 #5  0x00406c2d in do_transaction_start (conn=0x1939550,
 in=value optimized out)
 at xenstored_transaction.c:164
 trans = 0x1935bb0
 exists = value optimized out
 id_str =
 \300L\222\001\000\000\000\000\330!@\000\000\000\000\000P\225\223\001
 #6  0x004045ca in process_message (conn=0x1939550) at
 xenstored_core.c:1214
 trans = value optimized out
 #7  consider_message (conn=0x1939550) at xenstored_core.c:1261
 No locals.
 #8  handle_input (conn=0x1939550) at xenstored_core.c:1308
 bytes = value optimized out
 in = value optimized out
 #9  0x00405170 in main (argc=value optimized out, argv=value
 optimized out) at xenstored_core.c:1964
 
 A 3rd trace is somewhere completely different:
 (gdb) bt
 #0  0x7fcbf066088d in _IO_vfprintf_internal (s=0x7fff46ac3010,
 format=value optimized out, ap=0x7fff46ac3170)
 at vfprintf.c:1617
 #1  0x7fcbf0682732 in _IO_vsnprintf (string=0x7fff46ac318f ,
 maxlen=value 

[Xen-devel] [PATCH for-4.5] docs/commandline: Minor formatting fixes and clarifications

[Andrew Cooper]

`font` had a trailing single quote which was out of place.

`gnttab_max_frames` was missing escapes for the underscores which caused the
underscores to take their markdown meaning, causing 'max' in the middle to be
italicised.  Escape the underscores, and make all command line parameters
bold, to be consistent with the existing style.

Clarify how the default for `nmi` changes between debug and non debug builds
of Xen.

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com

---
Requesting for 4.5, under the strictly a documentation change allowance
---
 docs/misc/xen-command-line.markdown |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 1e8c024..152ae03 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -614,7 +614,7 @@ to use the default.
  `= integer`
 
 ### font
- `= height` where height is `8x8 | 8x14 | 8x16 '`
+ `= height` where height is `8x8 | 8x14 | 8x16`
 
 Specify the font size when using the VESA console driver.
 
@@ -648,13 +648,13 @@ Specify the maximum number of frames per grant table 
operation.
  `= integer`
 
 Specify the maximum number of maptrack frames domain.
-The default value is 8 times gnttab_max_frames.
+The default value is 8 times **gnttab\_max\_frames**.
 
 ### gnttab\_max\_nr\_frames
  `= integer`
 
 *Deprecated*
-Use gnttab\_max\_frames and gnttab\_max\_maptrack\_frames instead.
+Use **gnttab\_max\_frames** and **gnttab\_max\_maptrack\_frames** instead.
 
 Specify the maximum number of frames per grant table operation and the
 maximum number of maptrack frames domain.
@@ -986,7 +986,7 @@ of the ACPI based one.
 ### nmi
  `= ignore | dom0 | fatal`
 
- Default: `nmi=fatal`
+ Default: `fatal` for a debug build, or `dom0` for a non-debug build
 
 Specify what Xen should do in the event of an NMI parity or I/O error.
 `ignore` discards the error; `dom0` causes Xen to report the error to
-- 
1.7.10.4


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

[Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU

[Boris Ostrovsky]

We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try dereference it in
the future, when VCPU is gone.

Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
 xen/arch/x86/hvm/vpmu.c |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

This needs to be backported to 4.3 and 4.4 as well

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..6d39680 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
 }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+struct vcpu *v = (struct vcpu *)arg;
+
+if ( this_cpu(last_vcpu) == v )
+this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+{
+/* Need to clear last_vcpu in case it points to v */
+if ( vpmu-last_pcpu != smp_processor_id() )
+on_selected_cpus(cpumask_of(vpmu-last_pcpu),
+ vpmu_clear_last, (void *)v, 1);
+else
+{
+local_irq_disable();
+vpmu_clear_last((void *)v);
+local_irq_enable();
+}
+}
+
 if ( vpmu-arch_vpmu_ops  vpmu-arch_vpmu_ops-arch_vpmu_destroy )
 vpmu-arch_vpmu_ops-arch_vpmu_destroy(v);
 }
-- 
1.7.1


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

[Xen-devel] [xen-4.3-testing test] 32282: tolerable FAIL - PUSHED

[xen . org]

flight 32282 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32282/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install  fail like 31934

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-amd64-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-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-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 xen  5cd7ed02530eb86ffee6f5b9c7f04743c726754f
baseline version:
 xen  e0921ec746410f0a07eb3767e95e5eda25d4934a


People who touched revisions under test:
  Andrew Cooper andrew.coop...@citrix.com
  Dietmar Hahn dietmar.h...@ts.fujitsu.com
  George Dunlap george.dun...@eu.citrix.com
  Jan Beulich jbeul...@suse.com
  Juergen Gross jgr...@suse.com
  Keir Fraser k...@xen.org
  Tim Deegan t...@xen.org


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  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 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
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 

Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for generating hypercall depending symbols

[Boris Ostrovsky]

On 12/11/2014 01:04 PM, Juergen Gross wrote:

diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out=$1
+shift
+in=$@
+
+for i in $in; do
+   eval $CPP $LINUXINCLUDE -dD -imacros $i -x c /dev/null
+done | \
+awk '$1 == #define  $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+   END {for (i in v) if (!(v[i] in v))
+   print HYPERCALL(substr(v[i], 14))}' | sort -u $out


Why do you 'sort -u'? Do you expect multiple definitions of the same 
hypercall?


-boris

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

[Xen-devel] [seabios test] 32285: tolerable FAIL - PUSHED

[xen . org]

flight 32285 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32285/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf  5 xen-bootfail pass in 32215
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 32215 pass in 
32285
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 32215 pass in 
32285

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32126

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  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-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 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-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass

version targeted for testing:
 seabios  ed675ad4193bc7f929e5b39074d50672970aefa3
baseline version:
 seabios  56b252ea737c1514916d6df4493f89ff71322f60


People who touched revisions under test:
  Kevin O'Connor ke...@koconnor.net


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 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
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-xl-pcipt-intel  fail
 test-amd64-i386-rhel6hvm-intel   pass
 test-amd64-i386-qemut-rhel6hvm-intel pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt fail
 test-amd64-i386-libvirt  fail
 test-amd64-i386-xl-multivcpu pass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair fail
 test-amd64-amd64-xl-sedf-pin pass   

[Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()

[Mark Pryor]

Instead of tracking down which commit involving libxl* which prints all kind of 
noiseto stderr, I will post a workaround. 

If you build, install, and use 4.5 this bug will drive you mad, so here it is:
 snip -
--- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomains.in
@@ -175,7 +175,7 @@ contains_something()
 # read name from xen config file
 rdname()
 {
-    NM=$($CMD create --quiet --dryrun --defconfig $1 |
+    NM=$($CMD create --quiet --dryrun --defconfig $1 21 |
  sed -n 's/^.*(name \(.*\))$/\1/p;s/^.*name: \(.*\),$/\1/p')
 }


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

[Xen-devel] [V0 PATCH 2/6] AMD-PVH: cpuid intercept

[Mukesh Rathor]

Call pv_cpuid for pvh cpuid intercept. Note, we modify
svm_vmexit_do_cpuid instead of the intercept switch because the guest
eip needs to be adjusted for pvh also.

Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
 xen/arch/x86/hvm/svm/svm.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 71b8a6a..4ff4a96 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1517,18 +1517,22 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs 
*regs)
 if ( (inst_len = __get_instruction_length(current, INSTR_CPUID)) == 0 )
 return;
 
-eax = regs-eax;
-ebx = regs-ebx;
-ecx = regs-ecx;
-edx = regs-edx;
-
-svm_cpuid_intercept(eax, ebx, ecx, edx);
+if ( is_pvh_vcpu(current) )
+pv_cpuid(regs);
+else
+{
+eax = regs-eax;
+ebx = regs-ebx;
+ecx = regs-ecx;
+edx = regs-edx;
 
-regs-eax = eax;
-regs-ebx = ebx;
-regs-ecx = ecx;
-regs-edx = edx;
+svm_cpuid_intercept(eax, ebx, ecx, edx);
 
+regs-eax = eax;
+regs-ebx = ebx;
+regs-ecx = ecx;
+regs-edx = edx;
+}
 __update_guest_eip(regs, inst_len);
 }
 
-- 
1.8.3.1


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

[Xen-devel] [V0 PATCH 4/6] AMD-PVH: Do not get/set vlapic TPR

[Mukesh Rathor]

PVH doesn't use apic emulation hence vlapic-regs ptr is not set for it.

Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
 xen/arch/x86/hvm/svm/svm.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dac16f4..4bb4ff2 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1052,7 +1052,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
 hvm_asid_flush_vcpu(v);
 }
 
-if ( !vcpu_guestmode )
+if ( !vcpu_guestmode  vcpu_vlapic(v)-regs )
 {
 vintr_t intr;
 
@@ -2247,7 +2247,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * NB. We need to preserve the low bits of the TPR to make checked builds
  * of Windows work, even though they don't actually do anything.
  */
-if ( !vcpu_guestmode ) {
+if ( !vcpu_guestmode  vcpu_vlapic(v)-regs ) {
 intr = vmcb_get_vintr(vmcb);
 vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
((intr.fields.tpr  0x0F)  4) |
@@ -2628,15 +2628,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 }
 
   out:
-if ( vcpu_guestmode )
-/* Don't clobber TPR of the nested guest. */
-return;
-
-/* The exit may have updated the TPR: reflect this in the hardware vtpr */
-intr = vmcb_get_vintr(vmcb);
-intr.fields.tpr =
-(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI)  0xFF)  4;
-vmcb_set_vintr(vmcb, intr);
+/* Don't clobber TPR of the nested guest. */
+if ( vcpu_guestmode  vcpu_vlapic(v)-regs )
+{
+/*
+ * The exit may have updated the TPR: reflect this in the hardware
+ * vtpr.
+ */
+intr = vmcb_get_vintr(vmcb);
+intr.fields.tpr =
+(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI)  0xFF)  4;
+vmcb_set_vintr(vmcb, intr);
+}
 }
 
 void svm_trace_vmentry(void)
-- 
1.8.3.1


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

[Xen-devel] [V0 PATCH 6/6] AMD-PVH: enable pvh if requirements met

[Mukesh Rathor]

Finally, enable pvh if the cpu supports NPT and svm decode.

Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
 xen/arch/x86/hvm/svm/svm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4bb4ff2..8b27a76 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1390,6 +1390,9 @@ const struct hvm_function_table * __init start_svm(void)
 svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
 ((cpuid_edx(0x8001)  0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
 
+if ( cpu_has_svm_npt   cpu_has_svm_decode )
+svm_function_table.pvh_supported = 1;
+
 return svm_function_table;
 }
 
-- 
1.8.3.1


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

[Xen-devel] [V0 PATCH 1/6] AMD-PVH: construct vmcb changes

[Mukesh Rathor]

PVH guest starts in Long 64bit paging mode. This patch modifies
construct_vmcb for that.

Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
 xen/arch/x86/hvm/svm/vmcb.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 21292bb..5df5f36 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -138,6 +138,8 @@ static int construct_vmcb(struct vcpu *v)
 
 /* Guest EFER. */
 v-arch.hvm_vcpu.guest_efer = 0;
+if ( is_pvh_vcpu(v) )
+v-arch.hvm_vcpu.guest_efer |= EFER_LMA;   /* PVH 32bitfixme */
 hvm_update_guest_efer(v);
 
 /* Guest segment limits. */
@@ -162,7 +164,12 @@ static int construct_vmcb(struct vcpu *v)
 vmcb-ds.attr.bytes = 0xc93;
 vmcb-fs.attr.bytes = 0xc93;
 vmcb-gs.attr.bytes = 0xc93;
-vmcb-cs.attr.bytes = 0xc9b; /* exec/read, accessed */
+
+if ( is_pvh_vcpu(v) )
+/* CS.L == 1, exec, read/write, accessed. PVH 32bitfixme. */
+vmcb-cs.attr.bytes = 0xa9b;
+else
+vmcb-cs.attr.bytes = 0xc9b; /* exec/read, accessed */
 
 /* Guest IDT. */
 vmcb-idtr.base = 0;
@@ -184,12 +191,17 @@ static int construct_vmcb(struct vcpu *v)
 vmcb-tr.limit = 0xff;
 
 v-arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
+/* PVH domains start in paging mode */
+if ( is_pvh_vcpu(v) )
+v-arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG;
 hvm_update_guest_cr(v, 0);
 
-v-arch.hvm_vcpu.guest_cr[4] = 0;
+v-arch.hvm_vcpu.guest_cr[4] = is_pvh_vcpu(v) ? X86_CR4_PAE : 0;
 hvm_update_guest_cr(v, 4);
 
-paging_update_paging_modes(v);
+/* For pvh, paging mode is updated by arch_set_info_guest(). */
+if ( is_hvm_vcpu(v) )
+paging_update_paging_modes(v);
 
 vmcb-_exception_intercepts =
 HVM_TRAP_MASK
-- 
1.8.3.1


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

[Xen-devel] [V0 PATCH 5/6] AMD-PVH: Support TSC_MODE_NEVER_EMULATE for PVH

[Mukesh Rathor]

On AMD, MSR_AMD64_TSC_RATIO must be set for rdtsc instruction in guest
to properly read the cpu tsc. To that end, set tsc_khz in struct domain.

Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
 xen/arch/x86/time.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bd89219..7512aa4 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1908,6 +1908,7 @@ void tsc_set_info(struct domain *d,
  * but always_emulate does not for some reason.  Figure out
  * why.
  */
+d-arch.tsc_khz = cpu_khz;
 switch ( tsc_mode )
 {
 case TSC_MODE_NEVER_EMULATE:
-- 
1.8.3.1


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

[Xen-devel] [qemu-mainline test] 32294: regressions - FAIL

[xen . org]

flight 32294 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32294/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair  8 xen-boot/dst_host fail REGR. vs. 32194

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 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-qemuu-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 14 guest-stopfail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass

version targeted for testing:
 qemuub141290478f847ecaa25561f3b31fbf1ddde95e6
baseline version:
 qemuu45e1611de8be0eae55967694dd6e627c2dc354f2


People who touched revisions under test:
  Alex Bennée alex.ben...@linaro.org
  Anton Blanchard an...@samba.org
  Bastian Koppelmann kbast...@mail.uni-paderborn.de
  Christoffer Dall christoffer.d...@linaro.org
  Fabian Aggeler aggel...@ethz.ch
  Fam Zheng f...@redhat.com
  Gerd Hoffmann kra...@redhat.com
  Gonglei arei.gong...@huawei.com
  Greg Bellows greg.bell...@linaro.org
  Jeff Cody jc...@redhat.com
  Kevin Wolf kw...@redhat.com
  Liviu Ionescu i...@livius.net
  Markus Armbruster arm...@redhat.com
  Max Reitz mre...@redhat.com
  Michael Mueller m...@linux.vnet.ibm.com
  Nikita Belov zod...@ispras.ru
  Paolo Bonzini pbonz...@redhat.com
  Peter Maydell peter.mayd...@linaro.org
  Sergey Fedorov s.fedo...@samsung.com
  Stefan Hajnoczi stefa...@redhat.com
  zhanghailiang zhang.zhanghaili...@huawei.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
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 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
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 

[Xen-devel] [xen-4.2-testing test] 32291: tolerable FAIL - PUSHED

[xen . org]

flight 32291 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32291/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 31897

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   5 rumpuserxen-buildfail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail never pass
 test-i386-i386-libvirt9 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 build-i386-rumpuserxen5 rumpuserxen-buildfail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail 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-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check 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-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 xen  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen  3e5c06aeea1ff91c3f2247baae372936b67cf411


People who touched revisions under test:
  Andrew Cooper andrew.coop...@citrix.com
  Keir Fraser k...@xen.org


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-i386-i386-xlpass
 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
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-qemuu-freebsd10-amd64pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 

[Xen-devel] [xen-4.4-testing test] 32298: regressions - FAIL

[xen . org]

flight 32298 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32298/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  7 windows-install  fail REGR. vs. 32231

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32231

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 xen  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
baseline version:
 xen  de6313ab40a2858693609338db935cb689380361


People who touched revisions under test:
  Frediano Ziglio frediano.zig...@huawei.com
  Ian Campbell ian.campb...@citrix.com
  Julien Grall julien.gr...@linaro.org
  Stefano Stabellini stefano.stabell...@eu.citrix.com


jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 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  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 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
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64