Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

[Chen, Tiejun]

On 2014/11/18 16:01, Jan Beulich wrote:

On 18.11.14 at 04:08, tiejun.c...@intel.com wrote:

Here I tried to implement what you want. Note just pick two key
fragments since others have no big deal.

#1:

@@ -898,14 +898,25 @@ int
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
   {
   struct acpi_rmrr_unit *rmrr;
   int rc = 0;
+unsigned int i;
+u32 id;
+u16 bdf;

   list_for_each_entry(rmrr, acpi_rmrr_units, list)
   {
-rc = func(PFN_DOWN(rmrr-base_address),
-  PFN_UP(rmrr-end_address) - PFN_DOWN(rmrr-base_address),
-  ctxt);
-if ( rc )
-break;
+for (i = 0; (bdf = rmrr-scope.devices[i]) 
+i  rmrr-scope.devices_cnt  !rc; i++)
+{
+id = PCI_SBDF(rmrr-segment, bdf);
+rc = func(PFN_DOWN(rmrr-base_address),
+   PFN_UP(rmrr-end_address) -
+PFN_DOWN(rmrr-base_address),
+   id,
+   ctxt);
+if ( rc  0 )
+return rc;
+}
+rc = 0;


Getting close - the main issue is that (as previously mentioned) you
should avoid open-coding for_each_rmrr_device(). It also doesn't


Sorry, are you saying these lines?

 +for (i = 0; (bdf = rmrr-scope.devices[i]) 
 +i  rmrr-scope.devices_cnt  !rc; i++)

So without lookuping devices[i], how can we call func() for each sbdf as 
you mentioned?



look like you really need the local variable 'id'.


Okay, I can pass PCI_SBDF(rmrr-segment, bdf) directly.

Thanks
Tiejun

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

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq

[Jan Beulich]

 On 17.11.14 at 23:40, li...@eikelenboom.it wrote:
 OK, i still don't get why the output of debug-key 'i' reports +47 as pirq 
 here instead of the guest value 
 (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a 
 MSI with the PIRQ ?

No - as you said yourself, it's a matter of who uses which numbers.
Xen can't know the IRQ number the guest OS choses internally. It
can only tell you the number the hypervisor uses internally and the
one it told the guest to use to refer to it (the former is what we
commonly refer to as IRQ, while the latter is the pIRQ). Pin-based
(i.e. IO-APIC) interrupts should always use the same number for
both; MSI ones could only happen to have them match up, but
would use distinct numbers normally.

 I am puzzled by the driver binding twice to the same interrupt, but perhaps 
 that
 is just a buggy driver.
 
 Doesn't that happen more often like with integrated USB controllers ?
   17:  4  0  0  0  0  0  
 xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
   18:   4385  0  0  0  0  0  
 xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, 
 ohci_hcd:usb7

No, these are all distinct devices - if you look at you lspci output,
you should find multiple EHCI and OHCI controller instances. It's
slightly odd that each kind gets grouped onto a single IO-APIC pin,
but that's a (legal) BIOS decision.

Jan


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

[Xen-devel] [linux-linus test] 31610: regressions - trouble: blocked/broken/fail/pass

[xen . org]

flight 31610 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31610/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start   fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start fail REGR. vs. 31241
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 31241

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 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-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-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-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-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-winxpsp3 14 guest-stop   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-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 linux5f01feb8b97a4d65caa1456cb12f0f770497347f
baseline version:
 linux9f76628da20f96a179ca62b504886f99ecc29223


543 people touched revisions under test,
not listing them all


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-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 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  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   fail
 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

Re: [Xen-devel] [PATCH] libxl: avoid bringing up vcpus already online

[Chao Peng]

On Mon, Nov 17, 2014 at 09:41:17AM +, Wei Liu wrote:
 On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
  Avoid sending duplicated qmp commands and eliminate the confusing error
  messages like Unable to add CPU: 0, it already exists.
  
  Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
  ---
   tools/libxl/libxl.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
  index f7961f6..d040e5c 100644
  --- a/tools/libxl/libxl.c
  +++ b/tools/libxl/libxl.c
  @@ -5450,7 +5450,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, 
  uint32_t domid,
   LOGE(ERROR, getting domain info list);
   return ERROR_FAIL;
   }
  -for (i = 0; i = info.vcpu_max_id; i++) {
  +for (i = info.vcpu_online; i = info.vcpu_max_id; i++) {
 
 I don't think this is right. You're making an assumption that vcpu 0 to
 vcpu info.vcpu_online are online, which might not be true in hotplug /
 hot-unplug scenario.
 
You are right. Though the assumption is true right now as QEMU has not
implemented cpu hot-unplug.

The problem is: There is no way to obtain the vcpu online status in xl
as cpu hot-plug/hot-unplug for HVM are all done in QEMU. I guess it's
hard to fix it now. While it's also a minor issue :-)

Chao
 
   if (libxl_bitmap_test(cpumap, i)) {
   /* Return value is ignore because it does not tell anything 
  useful
* on the completion of the command.
  -- 
  1.7.9.5
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

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

Re: [Xen-devel] xl mem-max error

[Ian Campbell]

On Mon, 2014-11-17 at 15:03 -0500, Zhigang Wang wrote:
 On 11/12/2014 07:03 AM, Ian Campbell wrote:
  On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
  OK. Let me try my best:
 
  I'm confused by the description of what's going on, in particular the
  mixing of mem-max commands and target xenstore nodes (since the former
  doesn't really affect the latter).
 
  How was the domain started (memory= and maxmem=).
 
  xl create with 'memory = 700', no maxmem been set. I think it means maxmem 
  = memory for this case.
 
  What were static-max and target at the point?
 
   /local/domain/3/memory/static-max = 716800
   /local/domain/3/memory/target = 716801
 
  What did they change to when xl mem-max was issued? 
 
  When I issue 'xl mem-max domid 700', static-max and target in xenstore 
  will not change, but it will cause the command to fail.
 
  Because: libxl: error: libxl.c:4549:libxl_domain_setmaxmem: 
  memory_static_max must be greater than or or equal to memory_dynamic_max
 
  What did you expect them to change to instead?
 
  I expect I can set the maxmem to the same value I initially set (700).
  
  OK, thanks, got it. I think the use of xl mem-max is a bit of a
  red-herring, the issue here is that static-max  target at start of day.
  
  I suspect there is either a rounding error somewhere or because of
  LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
  somewhere along the line.
  
  We had been planning[0] to remove this early in the 4.5 cycle, but as
  ever it never floated to the top of anyone's list. For 4.5 we should
  probably look at applying this fudge more consistently.
  
  Ian.
  
  [0] http://bugs.xenproject.org/xen/bug/23
 
 Here is more info (correct me if something wrong):
 
 1. libxl_types.idl:
 
 (video_memkb, MemKB)
 
 MemKB = UInt(64, init_val = LIBXL_MEMKB_DEFAULT, json_gen_fn = 
 libxl__uint64_gen_json)
 
   libxl.h: #define LIBXL_MEMKB_DEFAULT ~0ULL
 
   So video_memkb = -1 by default.
 
 2. For hvm, we will set it into: 0, 16M, 8M according to hvm.vga.kind 
 (libxl_create.c)
 
 3. For pv guest, we will use default (-1).
 
 4. When we calculate static-max and target memory:
 
 ents[0] = memory/static-max;
 ents[1] = GCSPRINTF(%PRId64, info-max_memkb);
 ents[2] = memory/target;
 ents[3] = GCSPRINTF(%PRId64, info-target_memkb - info-video_memkb);
 
   So target = static-max - (-1):

Aha, well spotted!
   
   /local/domain/3/memory/static-max = 716800
   /local/domain/3/memory/target = 716801
 
   Maybe this is the root cause why we include LIBXL_MAXMEM_CONSTANT.

I don't think so, LIBXL_MAXMEM_CONSTANT is the result of some
not-well-understood folklore which predates libxl entirely.

 
 Potential solutions:
 
 1. Set b_info-video_memkb = 0; for pv guest.

We should do this one, in the libxl_domain_build_info_setdefault
function.

 2. Set LIBXL_MEMKB_DEFAULT = 0 (instead of -1): this will affect a lot things.

Yeah, we can't do that since it would disallow setting certain kinds of
memory to 0, which can make sense.

 3. Also add LIBXL_MAXMEM_CONSTANT before doing comparison. (we should avoid 
 this as we want to remove LIBXL_MAXMEM_CONSTANT)

Agreed, lets not to this.

Ian.


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

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq

[Jan Beulich]

 On 17.11.14 at 19:01, li...@eikelenboom.it wrote:
 (XEN) [2014-11-17 17:54:18.695] CPU00:
 (XEN) [2014-11-17 17:54:18.705] CPU01:
 (XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628 
 count, 
 [prev:83054ef57e70, next:83054ef57e70] 83051b904428NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:18.765] d16 OK-raise   112msec ago, state:1, 2628 
 count, [prev:00200200, next:00100100] 83051b904428NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:18.815] CPU02:
 (XEN) [2014-11-17 17:54:18.825] d17 OK-softirq 500msec ago, state:1, 3439 
 count, [prev:83054ef47e70, next:83054ef47e70] 83051a1c8c28NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:18.875] d17 OK-raise   549msec ago, state:1, 3439 
 count, [prev:00200200, next:00100100] 83051a1c8c28NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:18.924] CPU03:
 (XEN) [2014-11-17 17:54:18.935] d16 OK-softirq 313msec ago, state:1, 3533 
 count, [prev:83054ef37e70, next:83054ef37e70] 83051b904428NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:18.984] d16 OK-raise   363msec ago, state:1, 3533 
 count, [prev:00200200, next:00100100] 83051b904428NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:19.034] CPU04:
 (XEN) [2014-11-17 17:54:19.044] d16 OK-softirq 359msec ago, state:1, 3691 
 count, [prev:83054ef27e88, next:83054ef27e88] 83051b904428NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:19.094] d16 OK-raise   408msec ago, state:1, 3691 
 count, [prev:00200200, next:00100100] 83051b904428NULL 
 MAPPED_SHIFT GUEST_MSI_SHIFT  PIRQ:87
 (XEN) [2014-11-17 17:54:19.143] CPU05:
 (XEN) [2014-11-17 17:54:19.154] d16 OK-softirq 458msec ago, state:1, 52039 
 count, [prev:83054ef283e0, next:83054ef283e0] 
 83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 (XEN) [2014-11-17 17:54:19.205] d16 OK-raise   489msec ago, state:1, 52049 
 count, [prev:00200200, next:00100100] 
 83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 (XEN) [2014-11-17 17:54:19.257] d16 ERR-poison 561msec ago, state:0, 1 count, 
 [prev:00200200, next:00100100] 83051b95fd28MACH_PCI_SHIFT 
 MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 (XEN) [2014-11-17 17:54:19.307] d16 Z-softirq  731msec ago, state:3, 3 count, 
 [prev:83054ef283e0, next:83054ef283e0] 83051b95fd28MACH_PCI_SHIFT 
 MAPPED_SHIFT GUEST_PCI_SHIFT  PIRQ:0
 (XEN) [2014-11-17 17:54:19.356] domain_crash called from io.c:938
 (XEN) [2014-11-17 17:54:19.356] Domain 16 reported crashed by domain 32767 on 
 cpu#5:

I think what would help establishing the sequence of events would
be to at the very least calculate the times printed above relative to
a single NOW() invocation done in dump_debug() rather than
dump_record(). That may, however, yield meaningless values when
done at millisecond granularity. Hence, either using nanosecond
granularity or not using time values but a simple sequence counter
might be a desirable approach.

What puzzles me additionally is that for list_del() to encounter an
already removed entry, I'd expect the entry to (mistakenly) have
got added twice. Yet there's no sign of that (the most recent
OK-raise entry shows the list entry still having poisoned pointers).
Or it would need to have got inserted a second time on another
CPU, but the track record thereof having got overwritten. Perhaps
now that we suspect the legacy IRQ to be the problematic one the
patch could be adjusted to track only operations on non-MSI IRQs
(or separately all three PT_IRQ_TYPE_*)?

Jan


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

Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

[Jan Beulich]

 On 18.11.14 at 09:16, tiejun.c...@intel.com wrote:
 On 2014/11/18 16:01, Jan Beulich wrote:
 On 18.11.14 at 04:08, tiejun.c...@intel.com wrote:
 Here I tried to implement what you want. Note just pick two key
 fragments since others have no big deal.

 #1:

 @@ -898,14 +898,25 @@ int
 intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
struct acpi_rmrr_unit *rmrr;
int rc = 0;
 +unsigned int i;
 +u32 id;
 +u16 bdf;

list_for_each_entry(rmrr, acpi_rmrr_units, list)
{
 -rc = func(PFN_DOWN(rmrr-base_address),
 -  PFN_UP(rmrr-end_address) - PFN_DOWN(rmrr-base_address),
 -  ctxt);
 -if ( rc )
 -break;
 +for (i = 0; (bdf = rmrr-scope.devices[i]) 
 +i  rmrr-scope.devices_cnt  !rc; i++)
 +{
 +id = PCI_SBDF(rmrr-segment, bdf);
 +rc = func(PFN_DOWN(rmrr-base_address),
 +   PFN_UP(rmrr-end_address) -
 +PFN_DOWN(rmrr-base_address),
 +   id,
 +   ctxt);
 +if ( rc  0 )
 +return rc;
 +}
 +rc = 0;

 Getting close - the main issue is that (as previously mentioned) you
 should avoid open-coding for_each_rmrr_device(). It also doesn't
 
 Sorry, are you saying these lines?
 
   +for (i = 0; (bdf = rmrr-scope.devices[i]) 
   +i  rmrr-scope.devices_cnt  !rc; i++)
 
 So without lookuping devices[i], how can we call func() for each sbdf as 
 you mentioned?

You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.

Jan


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

Re: [Xen-devel] [PATCH for-4.5] libxl: remove existence check for PCI device hotplug

[Ian Campbell]

On Mon, 2014-11-17 at 12:10 +, Wei Liu wrote:
 The existence check is to make sure a device is not added to a guest
 multiple times.
 
 PCI device backend path has different rules from vif, disk etc. For
 example:
 /local/domain/0/backend/pci/9/0/dev-1/:03:10.1
 /local/domain/0/backend/pci/9/0/key-1/:03:10.1
 /local/domain/0/backend/pci/9/0/dev-2/:03:10.2
 /local/domain/0/backend/pci/9/0/key-2/:03:10.2
 
 The devid for PCI devices is hardcoded 0.

FWIW I think devid here is effectively the PCI bus ID, and no
toolstack I know of has ever supported multiple PCI buses. In theory it
would be possible though. This means that the 0 corresponds to the
: too, I think.

This doesn't invalidate your reasoning, just FYI.

  libxl__device_exists only
 checks up to /local/.../9/0 so it always returns true even the device is
 assignable.
 
 Remove invocation of libxl__device_exists. We're sure at this point that
 the PCI device is assignable (hence no xenstore entry or JSON entry).
 The check is done before hand. For HVM guest it's done by calling
 xc_test_assign_device and for PV guest it's done by calling
 pciback_dev_is_assigned.
 
 Reported-by: Li, Liang Z liang.z...@intel.com
 Signed-off-by: Wei Liu wei.l...@citrix.com

Acked-by: Ian Campbell ian.campb...@citrix.com

 Cc: Ian Jackson ian.jack...@eu.citrix.com
 Cc: Konrad Wilk konrad.w...@oracle.com
 ---
 This patch fixes a regression in 4.5.
 
 The risk is that I misunderstood semantics of xc_test_assign_device and
 pciback_dev_is_assigned and end up adding several entries to JSON config
 template. But if the assignable tests are incorrect I think we have a
 bigger problem to worry about than duplicated entries in JSON template.
 
 It would be good for someone to have PCI hotplug setup to run a quick test.  I
 think Liang confirmed (indrectly) that xc_test_assign_device worked well for
 him so I think there's won't be multiple JSON template entries for HVM guests.
 However PV side still remains to be tested.

I don't think you need any kind of special h/w support to do PV pci
hotplug to guests, do you?

Ian.



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

Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 17:25 + on 17 Nov (1416241517), Andrew Cooper wrote:
 On 17/11/14 17:00, Tim Deegan wrote:
  At 16:40 + on 17 Nov (1416238835), Andrew Cooper wrote:
  On 17/11/14 16:30, Tim Deegan wrote:
  At 16:24 + on 17 Nov (1416237888), Jan Beulich wrote:
  On 17.11.14 at 16:39, ian.jack...@eu.citrix.com wrote:
  Liang Li writes ([PATCH] libxc: Expose the pdpe1gb cpuid flag to 
  guest):
  If hardware support the pdpe1gb flag, expose it to guest by default.
  Users don't have to use a 'cpuid= ' option in config file to turn
  it on.
  I don't understand what this flag does.  I guess from the name it
  turns on 1G pages.  I guess these are supported ?
 
  I would like to see comment from an x86 hypervisor maintainer.
  Yes, we support 1Gb pages. The purpose of the patch is to not
  unconditionally hide the flag from guests. (I had commented on
  v1, but sadly this one wasn't tagged as v2, nor was I included on
  the Cc list, hence I didn't spot the new version.)
 
  The one thing I'm not certain about is shadow mode: Only 2Mb
  pages may be supported there. Tim?
  Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
  guest_supports_1G_superpages()-hvm_pse1gb_supported()-paging_mode_hap()
  This is yet another case which proves that libxc is the wrong place to
  be choosing the cpuid flags exposed to a domain.
 
  Furthermore, guest_supports_1G_superpages() is insufficient as it only
  checks whether the host is capable of providing 1G superpages, not
  whether the guest has been permitted to use it.
 
  This causes a problem when migrating between hap-capable and
  hap-incapable systems.
  There's no notion of 'permitted' to use 1G pages, AFAICS, much like
  other CPU features.  But of course a _well-behaved_ guest that has
  been told in cpuid not to use 1G superpages will have no problems. :)
 
 That is my point.
 
 If 1GB pages are not supported (i.e. not present in cpuid), then the PS
 bit in an L3 is reserved, must be 0, and cause a pagefault if used.
 
 Nothing in Xen currently enforces this because
 guest_supports_1G_superpages() doesn't check domain_cpuid().

For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
HVM cpuid handler, so we don't advertise a feature we can't support.

For HAP mode, we _could_ add a cpuid check to the pagetable walker
but...

 It does however make me wonder how VMX/SVM non-root mode would enforce
 this as it would see the host cpuid, not guest cpuid when performing
 paging internally.

...non-emulated PT walks will get to use 1GB superpages anyway.
This is the same for other features (new instructions c).  We
can mask them out of CPUID but by and large we can't make them fault.

Tim.

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

Re: [Xen-devel] Xen 4.5 random freeze question

[Andrii Tseglytskyi]

Hi Stefano,

On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
 Hi Stefano,

 Thank you for your answer.

 On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
  Although it is possible that that patch is the cause of your problem,
  unfortunately it is part of a significant rework of the GIC driver in
  Xen and I am afraid that testing with only a portion of that patch
  series might introduce other subtle bugs.  For your reference the series
  starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
  commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
 

 Yes, I tested with and without the whole series.

 And the result is that the series causes the problem?


Yes.


  If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
  problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
  might not work correctly on your platform. It wouldn't be the first time
  that we see hardware behaving that way, especially if you are using the
  GIC secure registers instead of the non-secure register as GICH_LRn.HW
  can only deactivate non-secure interrupts. This is usually due to a
  configuration error in u-boot.
 
  Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
  platform?
 

 I tried this. Unfortunately it doesn't help.

 Could you try the following patch on top of
 5495a512b63bad868c147198f7f049c2617d468c ?

 diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
 index 302c031..a286376 100644
 --- a/xen/arch/arm/gic.c
 +++ b/xen/arch/arm/gic.c
 @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct pending_irq 
 *p,
  BUG_ON(lr  0);
  BUG_ON(state  ~(GICH_LR_STATE_MASKGICH_LR_STATE_SHIFT));

 -lr_val = state | ((p-priority  3)  GICH_LR_PRIORITY_SHIFT) |
 +lr_val = state | GICH_LR_MAINTENANCE_IRQ | ((p-priority  3)  
 GICH_LR_PRIORITY_SHIFT) |
  ((p-irq  GICH_LR_VIRTUAL_MASK)  GICH_LR_VIRTUAL_SHIFT);
 -if ( p-desc != NULL )
 -lr_val |= GICH_LR_HW | (p-desc-irq  GICH_LR_PHYSICAL_SHIFT);

  GICH[GICH_LR + lr] = lr_val;

 @@ -622,6 +620,12 @@ out:
  return;
  }

 +static void gic_irq_eoi(void *info)
 +{
 +int virq = (uintptr_t) info;
 +GICC[GICC_DIR] = virq;
 +}
 +
  static void gic_update_one_lr(struct vcpu *v, int i)
  {
  struct pending_irq *p;
 @@ -639,7 +643,10 @@ static void gic_update_one_lr(struct vcpu *v, int i)
  irq = (lr  GICH_LR_VIRTUAL_SHIFT)  GICH_LR_VIRTUAL_MASK;
  p = irq_to_pending(v, irq);
  if ( p-desc != NULL )
 +{
 +gic_irq_eoi((void*)(uintptr_t)irq);
  p-desc-status = ~IRQ_INPROGRESS;
 +}
  clear_bit(GIC_IRQ_GUEST_VISIBLE, p-status);
  if ( test_bit(GIC_IRQ_GUEST_PENDING, p-status) 
  test_bit(GIC_IRQ_GUEST_ENABLED, p-status))


It helps! Thank you a lot!
I did about ~30 reboots and got no hangs. The only what is needed - is
to rebase these changes on top of xen/master branch.
Changes in patch can be applied only on top of
5495a512b63bad868c147198f7f049c2617d468c
Will you do this change? Is it acceptable for baseline?

Regards,
Andrii

-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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

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

[xen . org]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 30603

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   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-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-win7-amd64 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-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:
 qemuu4e70f9271dabc58fbf14680843bfac510c193152
baseline version:
 qemuub00a0ddb31a393b8386d30a9bef4d9bbb249e7ec


People who touched revisions under test:
  Adam Crume adamcr...@gmail.com
  Alex Bennée alex.ben...@linaro.org
  Alex Williamson alex.william...@redhat.com
  Alexander Graf ag...@suse.de
  Alexey Kardashevskiy a...@ozlabs.ru
  Amit Shah amit.s...@redhat.com
  Amos Kong ak...@redhat.com
  Andreas Färber afaer...@suse.de
  Andrew Jones drjo...@redhat.com
  Ard Biesheuvel ard.biesheu...@linaro.org
  Aurelien Jarno aurel...@aurel32.net
  Bastian Koppelmann kbast...@mail.uni-paderborn.de
  Bharata B Rao bhar...@linux.vnet.ibm.com
  Bin Wu wu.wu...@huawei.com
  Chao Peng chao.p.p...@linux.intel.com
  Chen Fan chen.fan.f...@cn.fujitsu.com
  Chen Gang gang.chen.5...@gmail.com
  Chenliang chenlian...@huawei.com
  Chris Johns chr...@rtems.org
  Chris Spiegel chris.spie...@cypherpath.com
  Christian Borntraeger borntrae...@de.ibm.com
  Claudio Fontana claudio.font...@huawei.com
  Cole Robinson crobi...@redhat.com
  Corey Minyard cminy...@mvista.com
  Cornelia Huck cornelia.h...@de.ibm.com
  David Gibson da...@gibson.dropbear.id.au
  David Hildenbrand d...@linux.vnet.ibm.com
  Denis V. Lunev d...@openvz.org
  Don Slutz dsl...@verizon.com
  Dongxue Zhang elta@gmail.com
  Dr. David Alan Gilbert dgilb...@redhat.com
  Edgar E. Iglesias edgar.igles...@xilinx.com
  Eduardo Habkost ehabk...@redhat.com
  Eduardo Otubo eduardo.ot...@profitbricks.com
  Fabian Aggeler aggel...@ethz.ch
  Fam Zheng f...@redhat.com
  Frank Blaschka blasc...@linux.vnet.ibm.com
  Gal Hammer gham...@redhat.com
  Gerd Hoffmann kra...@redhat.com
  Gonglei arei.gong...@huawei.com
  Greg Bellows greg.bell...@linaro.org
  Gu Zheng guz.f...@cn.fujitsu.com
  Hannes Reinecke h...@suse.de
  Heinz Graalfs graa...@linux.vnet.ibm.com
  Igor Mammedov imamm...@redhat.com
  James Harper james.har...@ejbdigital.com.au
  James Harper ja...@ejbdigital.com.au
  Jan Kiszka jan.kis...@siemens.com
  Jan Vesely jano.ves...@gmail.com
  Jens Freimann jf...@linux.vnet.ibm.com
  Joel Schopp jsch...@linux.vnet.ibm.com
  John Snow js...@redhat.com
  Jonas Gorski j...@openwrt.org
  Jonas Maebe jonas.ma...@elis.ugent.be
  Juan Quintela quint...@redhat.com
  Juan Quintela quint...@trasno.org
  Jun Li junm...@gmail.com
  Kevin Wolf kw...@redhat.com
  KONRAD Frederic fred.kon...@greensocs.com
  Laszlo Ersek ler...@redhat.com
  Leon Alrae leon.al...@imgtec.com
  Li Liang liang.z...@intel.com
  Li Liu john.li...@huawei.com
  Luiz Capitulino lcapitul...@redhat.com
  Maciej W. Rozycki ma...@codesourcery.com
  Magnus Reftel ref...@spotify.com
  Marc-André Lureau marcandre.lur...@gmail.com
  Marcel Apfelbaum marce...@redhat.com
  Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
  Markus Armbruster arm...@redhat.com
  Martin Decky mar...@decky.cz
  Martin Simmons mar...@lispworks.com
  Max Filippov jcmvb...@gmail.com
  Max Reitz mre...@redhat.com
  Michael 

Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem

[Tamas K Lengyel]

On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich jbeul...@suse.com wrote:

  On 17.11.14 at 18:06, tamas.leng...@zentific.com wrote:
  On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich jbeul...@suse.com wrote:
 
   On 12.11.14 at 16:48, andrew.coop...@citrix.com wrote:
   On 12/11/14 15:31, Tamas K Lengyel wrote:
xen/include/public/domctl.h |  44 +--
xen/include/public/hvm/params.h |   2 +-
xen/include/public/mem_event.h  | 134 ---
xen/include/public/memory.h |   6 +-
xen/include/public/vm_event.h   | 179 +
  
   While in principle I think this series is a very good thing, there is
 a
   problem with editing the pubic header files.
  
   The contents of mem_event.h is not currently hidden behind #ifdef
   __XEN_TOOLS__
  
   As a result, it is strictly speaking part of the VM-visible public
   API/ABI and not permitted to change in a backwards incompatible manor.
  
   Having said that, it is currently only usable by privileged domains,
 so
   there is an argument to be made for declaring that it should have been
   hidden behind __XEN_TOOLS__ in the first place, making it permittable
 to
   change.
 
  I'm not sure I agree - the meaning of tools here would seem quite a
  bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
  an old consumer (remember that for many of these we have at best
  fake consumers in the tree) would deal with the now differently
  arranged data. I don't see any versioning of the interface, and hence
  I can't see how tools would know which of the formats to expect.
 
  The lack of versioning is a real concern which I have aired during the
 4.5
  development process. For example, when we switched from HVMEM_access_* to
  XENMEM_access_* a customer had to do a bunch of manual configure checks
 to
  determine what is supported and what isn't. Furthermore, many of the
  related APIs have changed quite radically between Xen 4.1-4.5, some being
  abandoned midway just to resurface later in a different context. Going
  forward having a clear VM_EVENT_VERSION definition would be very helpful
  and would be the cleanest solution IMHO.

 That's a concern different from mine - source compatibility may be
 acceptable to get broken. Undetectable binary incompatibilities are
 what worry me more.

 Jan


To be fair, I don't think there ever was backwards compatibility
established with the usage of that struct in source or binary form. A quick
glance at git log shows that it had been shuffled around and extended quite
a bit over the years. Going forward it would be best to start with
something that's clean before backwards compatibility is enforced IMHO.

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

Re: [Xen-devel] Xen 4.5 random freeze question

[Andrii Tseglytskyi]

OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
everything works fine
The following 2 patches fixes xen/master for my platform.

Stefano, could you please take a look to these changes?

commit 3628a0aa35706a8f532af865ed784536ce514eca
Author: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
Date:   Tue Nov 18 14:20:42 2014 +0200

xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag

Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..093ecdb 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
pending_irq *p,
   GICH_V2_LR_PRIORITY_SHIFT) |
   ((p-irq  GICH_V2_LR_VIRTUAL_MASK) 
GICH_V2_LR_VIRTUAL_SHIFT));

-if ( p-desc != NULL )
+if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
 {
-if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
-lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
-else
-lr_reg |= GICH_V2_LR_HW | ((p-desc-irq 
GICH_V2_LR_PHYSICAL_MASK )
- GICH_V2_LR_PHYSICAL_SHIFT);
+lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
+}
+else if ( p-desc != NULL )
+{
+lr_reg |= GICH_V2_LR_HW | ((p-desc-irq  GICH_V2_LR_PHYSICAL_MASK )
+GICH_V2_LR_PHYSICAL_SHIFT);
 }

 writel_gich(lr_reg, GICH_LR + lr * 4);

commit 110ad1914f04a5e52ec9d49a9aeb7df488f524b1
Author: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
Date:   Tue Nov 18 12:14:42 2014 +0200

xen/arm: dra7: add PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI

Change-Id: Ic6285d5aea803fb0bfef50ffcc35e20b5bfb7a77
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com

diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index 9d6e504..fb6686f 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -166,6 +166,11 @@ static const struct dt_device_match
dra7_blacklist_dev[] __initconst =
 { /* sentinel */ },
 };

+static uint32_t dra7_quirks(void)
+{
+return PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI;
+}
+
 PLATFORM_START(omap5, TI OMAP5)
 .compatible = omap5_dt_compat,
 .init_time = omap5_init_time,
@@ -186,6 +191,7 @@ PLATFORM_START(dra7, TI DRA7)
 .dom0_gnttab_start = 0x4b00,
 .dom0_gnttab_size = 0x2,
 .blacklist_dev = dra7_blacklist_dev,
+.quirks = dra7_quirks,
 PLATFORM_END

 /*

On Tue, Nov 18, 2014 at 1:31 PM, Andrii Tseglytskyi
andrii.tseglyts...@globallogic.com wrote:
 Strange - looks like baseline code already does the same, that you
 sent me yesterday. The only what is needed - is to set
 PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
 But baseline contains an issue. And in the same time changes on top of
 5495a512b63bad868c147198f7f049c2617d468c work fine.

 Regards,
 Andrii

 On Tue, Nov 18, 2014 at 12:41 PM, Andrii Tseglytskyi
 andrii.tseglyts...@globallogic.com wrote:
 Hi Stefano,

 On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
 On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
 Hi Stefano,

 Thank you for your answer.

 On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
  Although it is possible that that patch is the cause of your problem,
  unfortunately it is part of a significant rework of the GIC driver in
  Xen and I am afraid that testing with only a portion of that patch
  series might introduce other subtle bugs.  For your reference the series
  starts at commit 6f91502be64a05d0635454d629118b96ae38b50f and ends at
  commit 72eaf29e8d70784aaf066ead79df1295a25ecfd0.
 

 Yes, I tested with and without the whole series.

 And the result is that the series causes the problem?


 Yes.


  If 5495a512b63bad868c147198f7f049c2617d468c is really the cause of your
  problem, one idea that comes to mind is that GICH_LR_MAINTENANCE_IRQ
  might not work correctly on your platform. It wouldn't be the first time
  that we see hardware behaving that way, especially if you are using the
  GIC secure registers instead of the non-secure register as GICH_LRn.HW
  can only deactivate non-secure interrupts. This is usually due to a
  configuration error in u-boot.
 
  Could you please try to set PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI for your
  platform?
 

 I tried this. Unfortunately it doesn't help.

 Could you try the following patch on top of
 5495a512b63bad868c147198f7f049c2617d468c ?

 diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
 index 302c031..a286376 100644
 --- a/xen/arch/arm/gic.c
 +++ b/xen/arch/arm/gic.c
 @@ -557,10 +557,8 @@ static inline void gic_set_lr(int lr, struct 
 pending_irq *p,
  BUG_ON(lr  0);
  BUG_ON(state  ~(GICH_LR_STATE_MASKGICH_LR_STATE_SHIFT));

 -lr_val = state | ((p-priority  3) 

Re: [Xen-devel] [BUGFIX][PATCH for 2.2 1/1] hw/ide/core.c: Prevent SIGSEGV during migration

[Stefano Stabellini]

Konrad,
I think we should have this fix in Xen 4.5. Should I go ahead and
backport it?

On Mon, 17 Nov 2014, Don Slutz wrote:
 The other callers to blk_set_enable_write_cache() in this file
 already check for s-blk == NULL.
 
 Signed-off-by: Don Slutz dsl...@verizon.com
 ---
 
 I think this is a bugfix that should be back ported to stable
 releases.
 
 I also think this should be done in xen's copy of QEMU for 4.5 with
 back port(s) to active stable releases.
 
 Note: In 2.1 and earlier the routine is
 bdrv_set_enable_write_cache(); variable is s-bs.
 
  hw/ide/core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/hw/ide/core.c b/hw/ide/core.c
 index 00e21cf..d4af5e2 100644
 --- a/hw/ide/core.c
 +++ b/hw/ide/core.c
 @@ -2401,7 +2401,7 @@ static int ide_drive_post_load(void *opaque, int 
 version_id)
  {
  IDEState *s = opaque;
  
 -if (s-identify_set) {
 +if (s-blk  s-identify_set) {
  blk_set_enable_write_cache(s-blk, !!(s-identify_data[85]  (1  
 5)));
  }
  return 0;
 -- 
 1.8.4
 

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

Re: [Xen-devel] [qemu-mainline test] 31651: regressions - FAIL

[Ian Jackson]

xen.org writes ([qemu-mainline test] 31651: regressions - FAIL):
 flight 31651 qemu-mainline real [real]
 http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/
 
 Regressions :-(
 
 Tests which did not succeed and are blocking,
 including tests which could not be run:
  test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 
 30603

This was the swiotlb bnx2/mptsas bug.  I have force pushed it.

Ian.

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

Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Ian Campbell]

On Tue, 2014-11-18 at 11:41 +, Zhang, Yang Z wrote:
  Hmm - this is a pitfall waiting to happen.
  
  In the case that there is a heterogeneous setup with one 1G capable
  and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
  pages on the capable hardware.  Any VM which guesses at hardware
  support by means other than cpuid features is liable to explode on migrate.
 
 But a normal guest shouldn't to guess it, right?

IMHO any guest which does not use the mechanism explicitly provided for
feature detection deserves to break randomly.

It's basically equivalent to a physical system where the BIOS masks this
cpuid bit because of some hardware errata or something, the underlying
feature might appear to be present but will have more or less subtle
issues.

Ian.


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

[Xen-devel] [qemu-upstream-4.3-testing test] 31652: tolerable FAIL - PUSHED

[xen . org]

flight 31652 qemu-upstream-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31652/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail never pass
 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-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail 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-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-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-qemut-win7-amd64 14 guest-stop  fail 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-qemuu-winxpsp3-vcpus1 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:
 qemuu580b1d06aa3eed3ae9c12b4225a1ea1c192ab119
baseline version:
 qemuue16435c95be86244bd92c5c26579bd4298aa65a6


People who touched revisions under test:
  Roger Pau Monne roger@citrix.com
  Roger Pau Monné roger@citrix.com
  Stefano Stabellini stefano.stabell...@eu.citrix.com


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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 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 pass
 test-amd64-amd64-xl-sedf-pin pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-xl-sedf pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
 test-amd64-i386-xl-winxpsp3-vcpus1 

Re: [Xen-devel] [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE [and 1 more messages]

[Ian Jackson]

Konrad Rzeszutek Wilk writes (Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE):
 On Fri, Nov 14, 2014 at 06:52:37PM +, Ian Jackson wrote:
  The structural considerations, error handling patterns, and so on, in
  libxl have remained undocumented.  This has been a problem during
  recent code submissions and reviews.
 
 Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

Wei Liu writes (Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE):
 Acked-by: Wei Liu wei.l...@citrix.com

Thanks, pushed.

Ian.

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

Re: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated

[Ian Jackson]

Chunyan Liu writes ([PATCH v2] fix rename: xenstore not fully updated):
 Currently libxl__domain_rename only update /local/domain/domid/name,
 still some places in xenstore are not updated, including:
 /vm/uuid/name and /local/domain/0/backend/device/domid/.../domain.

Thanks.  The principle is correct now and so is the broad approach.

 This patch updates /vm/uuid/name in xenstore, and removes the unusual
 'domain' field under backend directory (the affected are backend/console,
 backend/vfb, backend/vkb).

I think this should be a separate patch.

 Signed-off-by: Chunyan Liu cy...@suse.com
 ---
 Changes:
   * remove unusual 'domain' field from backend dir
   * get uuid from hypervisor rather then from xenstore
 
  tools/libxl/libxl.c | 23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)
 
 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
 index f7961f6..197433c 100644
 --- a/tools/libxl/libxl.c
 +++ b/tools/libxl/libxl.c
 @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 +/* update /vm/uuid/name */
 +rc = libxl_domain_info(ctx, info, domid);
 +if (rc) {
 +LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
 +  fail to get domain info for domain %d, domid);
 +goto x_fail;
 +}

I don't think you need to log here since libxl_domain_info already
does so.  Likewise libxl__xs_write_checked.  But before deleting this,
please let's wait and see whether Wei and Ian C agree.

If you do want to add logging here, it's probably better to use use
LOG rather than LIBXL__LOG.

 +uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
 +vm_name_path = GCSPRINTF(/vm/%s/name, uuid);
 +if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
 +LIBXL__LOG(ctx, LIBXL__LOG_ERROR, failed to write new name `%s'
 +to %s, new_name, vm_name_path);
 +goto x_fail;

I don't think it is necessary to LIBXL__LOG here, since
libxl__xs_write_checked does so.  (See the doc comment in
libxl_internal.h.)

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2] fix rename: xenstore not fully updated

[Ian Campbell]

On Tue, 2014-11-18 at 14:49 +, Ian Jackson wrote:
 Chunyan Liu writes ([PATCH v2] fix rename: xenstore not fully updated):
  Currently libxl__domain_rename only update /local/domain/domid/name,
  still some places in xenstore are not updated, including:
  /vm/uuid/name and /local/domain/0/backend/device/domid/.../domain.
 
 Thanks.  The principle is correct now and so is the broad approach.
 
  This patch updates /vm/uuid/name in xenstore, and removes the unusual
  'domain' field under backend directory (the affected are backend/console,
  backend/vfb, backend/vkb).
 
 I think this should be a separate patch.
 
  Signed-off-by: Chunyan Liu cy...@suse.com
  ---
  Changes:
* remove unusual 'domain' field from backend dir
* get uuid from hypervisor rather then from xenstore
  
   tools/libxl/libxl.c | 23 ++-
   1 file changed, 18 insertions(+), 5 deletions(-)
  
  diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
  index f7961f6..197433c 100644
  --- a/tools/libxl/libxl.c
  +++ b/tools/libxl/libxl.c
  @@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
  +/* update /vm/uuid/name */
  +rc = libxl_domain_info(ctx, info, domid);
  +if (rc) {
  +LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
  +  fail to get domain info for domain %d, domid);
  +goto x_fail;
  +}
 
 I don't think you need to log here since libxl_domain_info already
 does so.  Likewise libxl__xs_write_checked.  But before deleting this,
 please let's wait and see whether Wei and Ian C agree.

I'm all for removing redundant logging.

Ian

 
 If you do want to add logging here, it's probably better to use use
 LOG rather than LIBXL__LOG.
 
  +uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
  +vm_name_path = GCSPRINTF(/vm/%s/name, uuid);
  +if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name)) {
  +LIBXL__LOG(ctx, LIBXL__LOG_ERROR, failed to write new name `%s'
  +to %s, new_name, vm_name_path);
  +goto x_fail;
 
 I don't think it is necessary to LIBXL__LOG here, since
 libxl__xs_write_checked does so.  (See the doc comment in
 libxl_internal.h.)
 
 Thanks,
 Ian.



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

Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Ian Jackson]

Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 
for domU):
 I need to create an empty structure. Is the dummy field really needed?

Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
would be very surprised if clang didn't support them too.

AIUI our policy, gcc extensions are fine except in the Xen public
headers.

 If so, did you meant?
 
 struct
 {
int :0;
 }

Whatever you do, don't do this!

Ian.

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

Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 14:26 + on 18 Nov (1416317209), Ian Campbell wrote:
 On Tue, 2014-11-18 at 11:41 +, Zhang, Yang Z wrote:
   Hmm - this is a pitfall waiting to happen.
   
   In the case that there is a heterogeneous setup with one 1G capable
   and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
   pages on the capable hardware.  Any VM which guesses at hardware
   support by means other than cpuid features is liable to explode on 
   migrate.
  
  But a normal guest shouldn't to guess it, right?
 
 IMHO any guest which does not use the mechanism explicitly provided for
 feature detection deserves to break randomly.

Yes, that's a reasonable position (notwithstanding that we know such
software exists).

In this case, the guest is entitled to _expect_ pagefaults on 1GB
mappings if CPUID claims they are not supported.  That sounds like an
unlikely thing for the guest to be relying on, but Xen itself does
something similar for the SHOPT_FAST_FAULT_PATH (and now also for
IOMMU entries for the deferred caching attribute updates).

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Julien Grall]

On 11/18/2014 03:10 PM, Ian Jackson wrote:
 Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 
 for domU):
 I need to create an empty structure. Is the dummy field really needed?
 
 Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
 would be very surprised if clang didn't support them too.

AFAIK, clang doesn't complain about empty structures.

 AIUI our policy, gcc extensions are fine except in the Xen public
 headers.

We have at least 2 empty structure on the ARM public header.

 If so, did you meant?

 struct
 {
int :0;
 }
 
 Whatever you do, don't do this!

Would something like below be better?

struct
{
  int dummy:1
};

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.

[Don Koch]

If we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that used
that area (e.g. during a context switch). Since the vcpu's xsave
area is never zeroed after the initial allocation, that data is
still there. Since we are told that said area was not written to
during the save or migration, there is no need to restore it.

Signed-off-by: Don Koch dk...@verizon.com
---
Turns out the assertion that the unused xsave area is zero
is wrong. Unfortunately, that leaves the following as the
only way I can think of to work around it (and is no worse
than xsave/xrestore during context switches). Alternate
suggestions welcome.

 xen/arch/x86/hvm/hvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..b2c0bc4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 printk(XENLOG_G_WARNING
HVM%d.%u restore mismatch: xsave length %#x  %#x 
(non-zero data at %#x)\n,
d-domain_id, vcpuid, desc-length, size, i);
-return -EOPNOTSUPP;
+break;
 }
 }
 printk(XENLOG_G_WARNING
-- 
1.8.3.1


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

[Xen-devel] libxl: Is the nic param to libxl_network_device_add an (in)_out parameter?

[Euan Harris]

Hi,

If I call libxl_device_nic_add and pass in a mostly-default
libxl_device_nic structure, the function fills in the unspecified default
config fields with data for the NIC which it has just created:

libxl_device_nic nic;
libxl_device_nic_init(nic);
/* 
   nic.devid == -1 
   nic.mac == 00:00:00:00:00:00 
   nic.model == null
   etc.
 */

libxl_device_nic_add(ctx, domid, nic, NULL);
/* 
   nic.devid == 3 
   nic.mac == 00:16:3e:1b:7b:12
   nic.model == rtl8139
   etc.
 */

Is this behaviour an intentional part of the API which I can rely on,
or just an artefact of the current implementation?  In other words, is
nic meant to be an (in)_out parameter?  If it's not, what is the correct
way to find out the device ID which was allocated for the new device,
for example?

Thanks,
Euan

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

Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Ian Jackson]

Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 
for domU):
 On 11/18/2014 03:10 PM, Ian Jackson wrote:
  Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
  would be very surprised if clang didn't support them too.
 
 AFAIK, clang doesn't complain about empty structures.

Right.

  AIUI our policy, gcc extensions are fine except in the Xen public
  headers.
 
 We have at least 2 empty structure on the ARM public header.

That ought to be fixed, in case anyone ever wants to build ARM guests
with Norcroft C or something.

Does the size of these structs matter ?

 Would something like below be better?
 
 struct
 {
   int dummy:1
 };

I don't see why you wouldn't just do
   struct blah { char dummy; };
or even int dummy;

Ian.

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

Re: [Xen-devel] libxl: Is the nic param to libxl_network_device_add an (in)_out parameter?

[Ian Campbell]

On Tue, 2014-11-18 at 15:28 +, Euan Harris wrote:
 Hi,
 
 If I call libxl_device_nic_add and pass in a mostly-default
 libxl_device_nic structure, the function fills in the unspecified default
 config fields with data for the NIC which it has just created:
 
   libxl_device_nic nic;
   libxl_device_nic_init(nic);
   /* 
  nic.devid == -1 
  nic.mac == 00:00:00:00:00:00 
nic.model == null
  etc.
*/
 
   libxl_device_nic_add(ctx, domid, nic, NULL);
   /* 
  nic.devid == 3 
  nic.mac == 00:16:3e:1b:7b:12
nic.model == rtl8139
  etc.
*/
 
 Is this behaviour an intentional part of the API which I can rely on,
 or just an artefact of the current implementation?  In other words, is
 nic meant to be an (in)_out parameter?

I believe so, yes. The comment under Devices in libxl.h probably ought
to be adjusted to say so explicitly.

Ian (J) -- do you agree?

   If it's not, what is the correct
 way to find out the device ID which was allocated for the new device,
 for example?

You would have to libxl_device_type_list and look for it, which is
clearly suboptimal.

Ian.


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

Re: [Xen-devel] Xen 4.5 random freeze question

[Stefano Stabellini]

On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
 OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
 everything works fine
 The following 2 patches fixes xen/master for my platform.
 
 Stefano, could you please take a look to these changes?
 
 commit 3628a0aa35706a8f532af865ed784536ce514eca
 Author: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
 Date:   Tue Nov 18 14:20:42 2014 +0200
 
 xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
 
 Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
 Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
 
 diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
 index 31fb81a..093ecdb 100644
 --- a/xen/arch/arm/gic-v2.c
 +++ b/xen/arch/arm/gic-v2.c
 @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
 pending_irq *p,
GICH_V2_LR_PRIORITY_SHIFT) |
((p-irq  GICH_V2_LR_VIRTUAL_MASK) 
 GICH_V2_LR_VIRTUAL_SHIFT));
 
 -if ( p-desc != NULL )
 +if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
  {
 -if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
 -lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
 -else
 -lr_reg |= GICH_V2_LR_HW | ((p-desc-irq 
 GICH_V2_LR_PHYSICAL_MASK )
 - GICH_V2_LR_PHYSICAL_SHIFT);
 +lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
 +}
 +else if ( p-desc != NULL )
 +{
 +lr_reg |= GICH_V2_LR_HW | ((p-desc-irq  GICH_V2_LR_PHYSICAL_MASK )
 +GICH_V2_LR_PHYSICAL_SHIFT);
  }
 
  writel_gich(lr_reg, GICH_LR + lr * 4);

Actually in case p-desc == NULL (the irq is not an hardware irq, it
could be the virtual timer irq or the evtchn irq), you shouldn't need
the maintenance interrupt, if the bug was really due to GICH_LR_HW not
working correctly on OMAP5. This changes might only be better at
hiding the real issue.

Maybe the problem is exactly the opposite: the new scheme for avoiding
maintenance interrupts doesn't work for software interrupts.
The commit that should make them work correctly after the
no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
If you look at the changes to gic_update_one_lr in that commit, you'll
see that is going to set a software irq as PENDING if it is already ACTIVE.
Maybe that doesn't work correctly on OMAP5.

Could you try this patch on top of
394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
if the problem is specifically with software irqs.


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..d8a17c9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8
 
-#undef GIC_DEBUG
+#define GIC_DEBUG 1
 
 static void gic_update_one_lr(struct vcpu *v, int i);
 
@@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
 ((p-irq  GICH_LR_VIRTUAL_MASK)  GICH_LR_VIRTUAL_SHIFT);
 if ( p-desc != NULL )
 lr_val |= GICH_LR_HW | (p-desc-irq  GICH_LR_PHYSICAL_SHIFT);
+else
+lr_val |= GICH_LR_MAINTENANCE_IRQ;
 
 GICH[GICH_LR + lr] = lr_val;
 

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

Re: [Xen-devel] Xen 4.5 random freeze question

[Andrii Tseglytskyi]

What if I try on top of current master branch the following code:

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..6764ab7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -36,6 +36,8 @@
 #include asm/io.h
 #include asm/gic.h

+#define GIC_DEBUG 1
+
 /*
  * LR register definitions are GIC v2 specific.
  * Moved these definitions from header file to here
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bcaded9..c03d6a6 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);

 #define lr_all_full() (this_cpu(lr_mask) == ((1 
gic_hw_ops-info-nr_lrs) - 1))

-#undef GIC_DEBUG
+#define GIC_DEBUG 1

 static void gic_update_one_lr(struct vcpu *v, int i);

It is equivalent to what you proposing - my code contains
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
be executed:
 lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function

regards,
Andrii

On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
 OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
 everything works fine
 The following 2 patches fixes xen/master for my platform.

 Stefano, could you please take a look to these changes?

 commit 3628a0aa35706a8f532af865ed784536ce514eca
 Author: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
 Date:   Tue Nov 18 14:20:42 2014 +0200

 xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag

 Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
 Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com

 diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
 index 31fb81a..093ecdb 100644
 --- a/xen/arch/arm/gic-v2.c
 +++ b/xen/arch/arm/gic-v2.c
 @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
 pending_irq *p,
GICH_V2_LR_PRIORITY_SHIFT) |
((p-irq  GICH_V2_LR_VIRTUAL_MASK) 
 GICH_V2_LR_VIRTUAL_SHIFT));

 -if ( p-desc != NULL )
 +if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
  {
 -if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
 -lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
 -else
 -lr_reg |= GICH_V2_LR_HW | ((p-desc-irq 
 GICH_V2_LR_PHYSICAL_MASK )
 - GICH_V2_LR_PHYSICAL_SHIFT);
 +lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
 +}
 +else if ( p-desc != NULL )
 +{
 +lr_reg |= GICH_V2_LR_HW | ((p-desc-irq  GICH_V2_LR_PHYSICAL_MASK 
 )
 +GICH_V2_LR_PHYSICAL_SHIFT);
  }

  writel_gich(lr_reg, GICH_LR + lr * 4);

 Actually in case p-desc == NULL (the irq is not an hardware irq, it
 could be the virtual timer irq or the evtchn irq), you shouldn't need
 the maintenance interrupt, if the bug was really due to GICH_LR_HW not
 working correctly on OMAP5. This changes might only be better at
 hiding the real issue.

 Maybe the problem is exactly the opposite: the new scheme for avoiding
 maintenance interrupts doesn't work for software interrupts.
 The commit that should make them work correctly after the
 no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
 If you look at the changes to gic_update_one_lr in that commit, you'll
 see that is going to set a software irq as PENDING if it is already ACTIVE.
 Maybe that doesn't work correctly on OMAP5.

 Could you try this patch on top of
 394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
 if the problem is specifically with software irqs.


 diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
 index b7516c0..d8a17c9 100644
 --- a/xen/arch/arm/gic.c
 +++ b/xen/arch/arm/gic.c
 @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
  /* Maximum cpu interface per GIC */
  #define NR_GIC_CPU_IF 8

 -#undef GIC_DEBUG
 +#define GIC_DEBUG 1

  static void gic_update_one_lr(struct vcpu *v, int i);

 @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct pending_irq 
 *p,
  ((p-irq  GICH_LR_VIRTUAL_MASK)  GICH_LR_VIRTUAL_SHIFT);
  if ( p-desc != NULL )
  lr_val |= GICH_LR_HW | (p-desc-irq  GICH_LR_PHYSICAL_SHIFT);
 +else
 +lr_val |= GICH_LR_MAINTENANCE_IRQ;

  GICH[GICH_LR + lr] = lr_val;




-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Jan Beulich]

 On 18.11.14 at 16:00, julien.gr...@linaro.org wrote:
 On 10/31/2014 09:02 AM, Jan Beulich wrote:
 On 30.10.14 at 19:51, julien.gr...@linaro.org wrote:
 The naming suggests that the #if really should be around just the
 gic_version field (with a dummy field in the #else case to be C89
 compatible, e.g. a zero width unnamed bitfield) and the
 corresponding #define-s above, ...
 
 Not really related to this patch... but the way to improve it (via
 extending createdomain).
 
 I need to create an empty structure. Is the dummy field really needed?
 If so, did you meant?
 
 struct
 {
int :0;
 }

Yes.

 The C spec declare this kind of structure as undefined.

I can't find anything saying so.

 Would an empty structure and used it be better?

Empty structures (and unions) aren't valid in standard C afaics, up to
and including C11. That was the whole point of suggesting the above
alternative, with me (maybe wrongly) believing that this would be valid.

Jan


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

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq

[Konrad Rzeszutek Wilk]

 Without #define DIFF_LIST 1:
 1) The guest still crashes (xl-dmesg-not-defined.txt)

AHA!

 --MARK--
  0: 8305085ffd28 [p:83054ef27e88, n:83054ef27e88]
  1: 8305085ffd28 [p:0200200200200200, n:0100100100100100]

The same pirq_dpci structure is put twice on the list. That
will surely make it unhappy. The reason the #define DIFF_LIST 1
would work is that it has code to deal with that odd scenario.

But .. more importantly - the code should not allow you to
put _two_ of the same 'pirq_dpci' structures on the list.

 CPU00: 
 d16 OK-softirq 186msec ago, state:1, 3257 count, [prev:82d0802e7e88, 
next:82d0802e7e88] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 d16 OK-raise   236msec ago, state:1, 3257 count, [prev:0200200200200200, 
next:0100100100100100] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 CPU01: 
 d16 OK-softirq 232msec ago, state:1, 2978 count, [prev:83054ef57e70, 
next:83054ef57e70] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 d16 OK-raise   281msec ago, state:1, 2978 count, [prev:0200200200200200, 
next:0100100100100100] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 CPU02: 
 d16 OK-softirq 373msec ago, state:1, 2378 count, [prev:83054ef47e70, 
next:83054ef47e70] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 d16 OK-raise   423msec ago, state:1, 2378 count, [prev:0200200200200200, 
next:0100100100100100] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 CPU03: 
 d16 OK-softirq 867msec ago, state:1, 2744 count, [prev:83054ef37e70, 
next:83054ef37e70] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 d16 OK-raise   916msec ago, state:1, 2744 count, [prev:0200200200200200, 
next:0100100100100100] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 CPU04: 
 d16 OK-softirq 497msec ago, state:1, 76910 count, [prev:83054ef2e3e0, 
next:83054ef2e3e0] 8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT 
GUEST_PCI_SHIFT  PIRQ:0
 d16 OK-raise   489msec ago, state:1, 76916 count, [prev:83054ef2e3e0, 
next:83054ef2e3e0] 8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT 
GUEST_PCI_SHIFT  PIRQ:0
 d16 ERR-poison 600msec ago, state:0, 1 count, [prev:0200200200200200, 
next:0100100100100100] 8305085ffd28MACH_PCI_SHIFT MAPPED_SHIFT 
GUEST_PCI_SHIFT  PIRQ:0
 CPU05: 
 d16 OK-softirq 852msec ago, state:1, 2207 count, [prev:83054ef1fe70, 
next:83054ef1fe70] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 d16 OK-raise   902msec ago, state:1, 2207 count, [prev:0200200200200200, 
next:0100100100100100] 8305094a39a8NULL MAPPED_SHIFT GUEST_MSI_SHIFT  
PIRQ:87
 domain_crash called from io.c:964
 Domain 16 reported crashed by domain 7 on cpu#4:


 
 With #define DIFF_LIST 1:
 2) Nor the guest or the host crashed (let it run for about an hour and 15 
 minutes), 
but the USB XHCI driver bailed out quickly after guest boot, so there were 
 no MSI-X interrupts anymore.
(xl-dmesg-defined-nousb.txt, dmesg-guest-defined-nousb.txt)

Hm, that is odd. Can you tell me how you get your SeaBIOS to add those
extra statements? I don't seem to see them with my SeaBIOS (I've an XHCI
controlled hooked up to the guest too). Maybe I am missing an CONFIG in the
SeaBIOS build.

 3) On another boot the USB XHCI didn't bail out, after a while the host 
 crashes. (serial.log)
(XEN) [2014-11-18 14:53:37.364] RIP:e008:[82d08014a4de] 
 hvm_do_IRQ_dpci+0xf4/0x131
which resolves to:
# addr2line -e xen-syms 82d08014a4de
/usr/src/new/xen-unstable-vanilla/xen/include/xen/list.h:67
which is:
static inline void __list_add(struct list_head *new,
   struct list_head *prev,
   struct list_head *next)
 {
 next-prev = new;
 new-next = next;
 new-prev = prev;
 Here -prev-next = new;
 }

Looking at the stack:


(XEN) [2014-11-18 14:53:37.306]  0: 8303faaf25a8 [p:83054ef2e3e0, 
n:83054ef2e3e0]

We detected that the list was poison and were printing it, while an:

 [ Xen-4.5.0-rc  x86_64  debug=y  Not tainted ]
 CPU:4
 RIP:e008:[82d08014a4de] hvm_do_IRQ_dpci+0xf4/0x131
 RFLAGS: 00010082   CONTEXT: hypervisor
 rax: 83054ef2e3e0   rbx: 8303faaf25a8   rcx: 8303faaf2610
 rdx: 0200200200200200   rsi: 0006   rdi: 6ef3f123
 rbp: 83054ef27be8   rsp: 83054ef27bd8   r8:  8303faaf2010
 r9:  002f   r10: 0132   r11: 0003
 r12: 8305125d6000   r13:    r14: 8303faaf2580
 r15: 002f   cr0: 8005003b   cr4: 06f0
 cr3: 0005448c   cr2: ff600400
 ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
 Xen stack trace from rsp=83054ef27bd8:
83054ef27be8 8303faaf26c0 83054ef27c78 82d080172060
0020 83054ef27cf6 0046 83054ef27c70

Re: [Xen-devel] [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Julien Grall]

On 11/18/2014 04:15 PM, Jan Beulich wrote:
 On 18.11.14 at 16:00, julien.gr...@linaro.org wrote:
 On 10/31/2014 09:02 AM, Jan Beulich wrote:
 On 30.10.14 at 19:51, julien.gr...@linaro.org wrote:
 The naming suggests that the #if really should be around just the
 gic_version field (with a dummy field in the #else case to be C89
 compatible, e.g. a zero width unnamed bitfield) and the
 corresponding #define-s above, ...

 Not really related to this patch... but the way to improve it (via
 extending createdomain).

 I need to create an empty structure. Is the dummy field really needed?
 If so, did you meant?

 struct
 {
int :0;
 }
 
 Yes.
 
 The C spec declare this kind of structure as undefined.
 
 I can't find anything saying so.

http://c0x.coding-guidelines.com/6.7.2.1.html

1401 If the struct-declaration-list contains no named members, the
behavior is undefined.

 Would an empty structure and used it be better?
 
 Empty structures (and unions) aren't valid in standard C afaics, up to
 and including C11. That was the whole point of suggesting the above
 alternative, with me (maybe wrongly) believing that this would be valid.

Right, this is an extension of GCC. As neither of the 2 solutions are
valid, Ian Jackson was suggesting to use

struct {
   char dummy;
}

Would it be ok for you?

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] Problems accessing passthrough PCI device

[Simon Martin]

Hello Jan,

Friday, November 14, 2014, 5:27:36 AM, you wrote:

 I implied your earlier statement to mean that. But - did you also
 verify that the three flags actually end up set (ideally from both
 DomU and Dom0 perspective)? The PCI backend may be screwing
 up things...
 
 Yes I do verify the write. How do I check this from Dom0?

 Just use lspci.

I've just checked this with lspci. I see that the IO is being enabled.
Any   other   idea   on   why I might be reading back 0xff for all PCI
memory area reads? The lspci output follows.

Before starting DomU

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00

After DomU initialisation

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 02 00 10 00 04 00 00 02 00 00 00 00

After stopping DomU

smartin@smartin-xen:~$ lspci -s 00:19.0 -x
00:19.0 Ethernet controller: Intel Corporation Device 1559 (rev 04)
00: 86 80 59 15 00 00 10 00 04 00 00 02 00 00 00 00


-- 
Best regards,
 Simonmailto:furryfutt...@gmail.com


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

Re: [Xen-devel] Problems accessing passthrough PCI device

[Simon Martin]

Hello Konrad,

Thursday, November 13, 2014, 4:29:15 PM, you wrote:

 On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
 Thanks Konrad,
 
 Thursday, November 13, 2014, 4:03:38 PM, you wrote:
 
  Yes I do verify the write. How do I check this from Dom0?
 
  You can crank up the debug volume in xen-pciback. Recompile the kernel
  and put '#define DEBUG 1' at the start of the .c files.
 
  Interestingly enough I saw this issue as well - and it looked to me
  that Xen pciback was stuck in '7' state (Reconfiguring) and never
  excited it.
 
  But I hadn't had a chance to dig in this.
 
 This  might  be related to something that I reported a while ago, that
 when   I   shutdown  the PV it takes a long time for the corresponding
 Dom0 processes to stop.
 
 I'll set the debug level and see what's going on. That'll be on Monday
 now.

I attach the output from xl dmesg and dmesg. As far as I can see,
everything looks to be OK.


-- 
Best regards,
 Simonmailto:furryfutt...@gmail.com

xl_dmesg
Description: Binary data


dmesg
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.5 random freeze question

[Andrii Tseglytskyi]

OK got it. Give me a few mins

On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
 for non-hardware irqs (desc == NULL) and keep avoiding
 GICH_V2_LR_MAINTENANCE_IRQ and setting GICH_LR_HW for hardware irqs.

 Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
 other potential bugs introduced later.

 On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
 What if I try on top of current master branch the following code:

 diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
 index 31fb81a..6764ab7 100644
 --- a/xen/arch/arm/gic-v2.c
 +++ b/xen/arch/arm/gic-v2.c
 @@ -36,6 +36,8 @@
  #include asm/io.h
  #include asm/gic.h

 +#define GIC_DEBUG 1
 +
  /*
   * LR register definitions are GIC v2 specific.
   * Moved these definitions from header file to here
 diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
 index bcaded9..c03d6a6 100644
 --- a/xen/arch/arm/gic.c
 +++ b/xen/arch/arm/gic.c
 @@ -41,7 +41,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);

  #define lr_all_full() (this_cpu(lr_mask) == ((1 
 gic_hw_ops-info-nr_lrs) - 1))

 -#undef GIC_DEBUG
 +#define GIC_DEBUG 1

  static void gic_update_one_lr(struct vcpu *v, int i);

 It is equivalent to what you proposing - my code contains
 PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI, as result the following lone will
 be executed:
  lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ; inside gicv2_update_lr() function

 regards,
 Andrii

 On Tue, Nov 18, 2014 at 5:39 PM, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
  On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
  OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
  everything works fine
  The following 2 patches fixes xen/master for my platform.
 
  Stefano, could you please take a look to these changes?
 
  commit 3628a0aa35706a8f532af865ed784536ce514eca
  Author: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
  Date:   Tue Nov 18 14:20:42 2014 +0200
 
  xen/arm: dra7: always set GICH_V2_LR_MAINTENANCE_IRQ flag
 
  Change-Id: Ia380b3507a182b11592588f65fd23693d4f87434
  Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@globallogic.com
 
  diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
  index 31fb81a..093ecdb 100644
  --- a/xen/arch/arm/gic-v2.c
  +++ b/xen/arch/arm/gic-v2.c
  @@ -396,13 +396,14 @@ static void gicv2_update_lr(int lr, const struct
  pending_irq *p,
 
  GICH_V2_LR_PRIORITY_SHIFT) |
 ((p-irq  GICH_V2_LR_VIRTUAL_MASK) 
  GICH_V2_LR_VIRTUAL_SHIFT));
 
  -if ( p-desc != NULL )
  +if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
   {
  -if ( platform_has_quirk(PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI) )
  -lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
  -else
  -lr_reg |= GICH_V2_LR_HW | ((p-desc-irq 
  GICH_V2_LR_PHYSICAL_MASK )
  - GICH_V2_LR_PHYSICAL_SHIFT);
  +lr_reg |= GICH_V2_LR_MAINTENANCE_IRQ;
  +}
  +else if ( p-desc != NULL )
  +{
  +lr_reg |= GICH_V2_LR_HW | ((p-desc-irq  
  GICH_V2_LR_PHYSICAL_MASK )
  +GICH_V2_LR_PHYSICAL_SHIFT);
   }
 
   writel_gich(lr_reg, GICH_LR + lr * 4);
 
  Actually in case p-desc == NULL (the irq is not an hardware irq, it
  could be the virtual timer irq or the evtchn irq), you shouldn't need
  the maintenance interrupt, if the bug was really due to GICH_LR_HW not
  working correctly on OMAP5. This changes might only be better at
  hiding the real issue.
 
  Maybe the problem is exactly the opposite: the new scheme for avoiding
  maintenance interrupts doesn't work for software interrupts.
  The commit that should make them work correctly after the
  no-maintenance-irq commit is 394b7e587b05d0f4a5fd6f067b38339ab5a77121
  If you look at the changes to gic_update_one_lr in that commit, you'll
  see that is going to set a software irq as PENDING if it is already ACTIVE.
  Maybe that doesn't work correctly on OMAP5.
 
  Could you try this patch on top of
  394b7e587b05d0f4a5fd6f067b38339ab5a77121?  It should help us understand
  if the problem is specifically with software irqs.
 
 
  diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
  index b7516c0..d8a17c9 100644
  --- a/xen/arch/arm/gic.c
  +++ b/xen/arch/arm/gic.c
  @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
   /* Maximum cpu interface per GIC */
   #define NR_GIC_CPU_IF 8
 
  -#undef GIC_DEBUG
  +#define GIC_DEBUG 1
 
   static void gic_update_one_lr(struct vcpu *v, int i);
 
  @@ -563,6 +563,8 @@ static inline void gic_set_lr(int lr, struct 
  pending_irq *p,
   ((p-irq  GICH_LR_VIRTUAL_MASK)  GICH_LR_VIRTUAL_SHIFT);
   if ( p-desc != NULL )
   lr_val |= GICH_LR_HW | (p-desc-irq  GICH_LR_PHYSICAL_SHIFT);
  +else
  +lr_val |= GICH_LR_MAINTENANCE_IRQ;
 
   GICH[GICH_LR + lr] = lr_val;
 



 

[Xen-devel] [PATCH] xen: use more fixed strings to build the hypervisor

[Olaf Hering]

It is expected that repeated builds of identical sources results in
identical binaries on different hosts at different build times. This
fails for xen.gz and xen.efi because unstable strings are included in
the binaries.

In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
XEN_BUILD_HOST to specify fixed strings during build.

Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir Fraser k...@xen.org
Cc: Tim Deegan t...@xen.org
---
 xen/Makefile | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 72c1313..47f003c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -8,6 +8,9 @@ export XEN_FULLVERSION   = 
$(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 
 export XEN_WHOAMI  ?= $(USER)
 export XEN_DOMAIN  ?= $(shell ([ -x /bin/dnsdomainname ]  
/bin/dnsdomainname) || ([ -x /bin/domainname ]  /bin/domainname || echo 
[unknown]))
+export XEN_BUILD_DATE  ?= $(shell LC_ALL=C date)
+export XEN_BUILD_TIME  ?= $(shell LC_ALL=C date +%T)
+export XEN_BUILD_HOST  ?= $(shell hostname)
 
 export BASEDIR := $(CURDIR)
 export XEN_ROOT := $(BASEDIR)/..
@@ -126,11 +129,11 @@ delete-unfresh-files:
 
 # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
 include/xen/compile.h: include/xen/compile.h.in .banner
-   @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
-   -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
+   @sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
+   -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
-e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
-e 's/@@domain@@/$(XEN_DOMAIN)/g' \
-   -e 's/@@hostname@@/$(shell hostname)/g' \
+   -e 's/@@hostname@@/$(XEN_BUILD_HOST)/g' \
-e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 21 | head 
-1)!g' \
-e 's/@@version@@/$(XEN_VERSION)/g' \
-e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \

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

Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Julien Grall]

On 11/18/2014 04:21 PM, Ian Campbell wrote:
 On Tue, 2014-11-18 at 15:49 +, Julien Grall wrote:
 (Rename the mail and strip the cc list)

 On 11/18/2014 03:35 PM, Ian Jackson wrote:
 Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for 
 GICv3 for domU):
 On 11/18/2014 03:10 PM, Ian Jackson wrote:
 Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
 would be very surprised if clang didn't support them too.

 AFAIK, clang doesn't complain about empty structures.

 Right.

 AIUI our policy, gcc extensions are fine except in the Xen public
 headers.

 We have at least 2 empty structure on the ARM public header.

 That ought to be fixed, in case anyone ever wants to build ARM guests
 with Norcroft C or something.

 Does the size of these structs matter ?

 The 2 structures are arch_vcpu_info and arch_shared_info.

 They are used only at the end of the structure vcpu_info (resp.
 shared_info). So I guess we could fix it?
 
 arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
 and also vcpu_info is part of an array at the start of shared_info (an
 array of 1 on ARM, but things still follow it). I'm also not sure of the
 impact on the vcpu placement hypercall or the uses of it.

Oops, right. I looked too quickly to the code, sorry.

 So it looks like changing vcpu_info at least will be hard/impossible. If
 we want rid of these empty structs then I think an ifdef at the point of
 use is the only option :-(

I will send a patch to ifdef arch_vcpu and arch_shared_info when Xen 4.6
windows will be opened.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [for-xen-4.5 PATCH] Ignore non-zero data in unused xsave area.

[Konrad Rzeszutek Wilk]

On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
 If we restore an xsave area from an older xen that has a larger
 size than the xcr0 bit call for, it is possible to have non-zero
 data in the unused area if an xsave has ever been done that used
 that area (e.g. during a context switch). Since the vcpu's xsave
 area is never zeroed after the initial allocation, that data is
 still there. Since we are told that said area was not written to
 during the save or migration, there is no need to restore it.
 
 Signed-off-by: Don Koch dk...@verizon.com
 ---
 Turns out the assertion that the unused xsave area is zero
 is wrong. Unfortunately, that leaves the following as the
 only way I can think of to work around it (and is no worse
 than xsave/xrestore during context switches). Alternate
 suggestions welcome.

This is Xen 4.5 material I presume.

 
  xen/arch/x86/hvm/hvm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
 index 8f49b44..b2c0bc4 100644
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
 hvm_domain_context_t *h)
  printk(XENLOG_G_WARNING
 HVM%d.%u restore mismatch: xsave length %#x  %#x 
 (non-zero data at %#x)\n,
 d-domain_id, vcpuid, desc-length, size, i);
 -return -EOPNOTSUPP;
 +break;
  }
  }
  printk(XENLOG_G_WARNING
 -- 
 1.8.3.1
 
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [for-xen-4.5 PATCH] Ignore non-zero data in unused xsave area.

[Andrew Cooper]

On 18/11/14 16:32, Konrad Rzeszutek Wilk wrote:
 On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
 If we restore an xsave area from an older xen that has a larger
 size than the xcr0 bit call for, it is possible to have non-zero
 data in the unused area if an xsave has ever been done that used

Do you mean has never been done.

i.e. the non-zero data is actually Xen heap junk?

~Andrew

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

Re: [Xen-devel] [PATCH] xen: use more fixed strings to build the hypervisor

[Ian Jackson]

Olaf Hering writes ([PATCH] xen: use more fixed strings to build the 
hypervisor):
 It is expected that repeated builds of identical sources results in
 identical binaries on different hosts at different build times. This
 fails for xen.gz and xen.efi because unstable strings are included in
 the binaries.

I like the idea of making our builds more reproducible.  And your
patch looks correct (although I haven't tested it).

 In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
 XEN_BUILD_HOST to specify fixed strings during build.

But your commit message is rather odd.

The first paragrah describes an expectation which as far as I can tell
is not fulfilled by your patch.  Your patch just makes it easier to
fulfil.

And the second paragraph seems to have an English grammar issue.  Use
[blah] to specify fixed strings during build means, when found in a
commit message this commit uses [blah] to specify   But your
commit doesn't.  It merely provides a facility for others to do so.

How about

   It should be possible to repeatedly build identical sources
   and get identical binaries, even on different hosts at different
   build times.  This fails [etc. etc. ...]

   Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
   which the build environment can set to fixed strings to get a
   reproducible build.

or some such.

Ian.

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

Re: [Xen-devel] Empty struct in public headers Was: Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Ian Campbell]

On Tue, 2014-11-18 at 16:29 +, Julien Grall wrote:
 On 11/18/2014 04:21 PM, Ian Campbell wrote:
  On Tue, 2014-11-18 at 15:49 +, Julien Grall wrote:
  (Rename the mail and strip the cc list)
 
  On 11/18/2014 03:35 PM, Ian Jackson wrote:
  Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for 
  GICv3 for domU):
  On 11/18/2014 03:10 PM, Ian Jackson wrote:
  Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
  would be very surprised if clang didn't support them too.
 
  AFAIK, clang doesn't complain about empty structures.
 
  Right.
 
  AIUI our policy, gcc extensions are fine except in the Xen public
  headers.
 
  We have at least 2 empty structure on the ARM public header.
 
  That ought to be fixed, in case anyone ever wants to build ARM guests
  with Norcroft C or something.
 
  Does the size of these structs matter ?
 
  The 2 structures are arch_vcpu_info and arch_shared_info.
 
  They are used only at the end of the structure vcpu_info (resp.
  shared_info). So I guess we could fix it?
  
  arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
  and also vcpu_info is part of an array at the start of shared_info (an
  array of 1 on ARM, but things still follow it). I'm also not sure of the
  impact on the vcpu placement hypercall or the uses of it.
 
 Oops, right. I looked too quickly to the code, sorry.
 
  So it looks like changing vcpu_info at least will be hard/impossible. If
  we want rid of these empty structs then I think an ifdef at the point of
  use is the only option :-(
 
 I will send a patch to ifdef arch_vcpu and arch_shared_info when Xen 4.6
 windows will be opened.

Sounds good. The approach we've used in this area before is XEN_HAVE_FOO
(e.g. PV_UPCALL_MASK), so I suppose XEN_HAVE_ARCH_VCPU and
XEN_HAVE_ARCH_SHARED_INFO defined for x86 would be the most consistent
way to go.

Ian.


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

[Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes + support for McDivitt

[Ian Campbell]

These patches:

  * fix up an off by one bug in the xgene mapping of additional PCI
bus resources, which would cause an additional extra page to be
mapped
  * correct the size of the mapped regions to match the docs
  * adds support for the other 4 PCI buses on the chip, which
enables mcdivitt and presumably most other Xgene based platforms
which uses PCI buses other than pcie0.
  * adds earlyprintk for the mcdivitt platform

McDivitt is the X-Gene based HP Moonshot cartridge (McDivitt is the code
name, I think the product is called m400, not quite sure).

Other than the bug fixes I'd like to see the mcdivitt support
(specifically the other 4 PCI buses one) in 4.5 because Moonshot is an
interesting and exciting platform for arm64. It is also being used for
ongoing work on Xen on ARM on Openstack in Linaro. The earlyprintk patch
is totally harmless unless it's explicitly enabled at compile time, IMHO
if we are taking the rest we may as well throw it in...

The risk here is that we break the existing support for the Mustang
platform, which would be the most likely failure case for the second
patch. I've tested these on a Mustang, including firing up a PCI NIC
device. The new mappings are a superset of the existing ones so the
potential for breakage should be quite small.

I've also successfully tested on a McDivitt.

Ian.


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

[Xen-devel] [PATCH for-4.5 2/4] xen: arm: correct off by one in xgene-storm's map_one_mmio

[Ian Campbell]

The callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.

At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is just confusing.

Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
 xen/arch/arm/platforms/xgene-storm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 29c4752..38674cd 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -45,9 +45,9 @@ static int map_one_mmio(struct domain *d, const char *what,
 {
 int ret;
 
-printk(Additional MMIO %PRIpaddr-%PRIpaddr (%s)\n,
+printk(Additional MMIO %lx-%lx (%s)\n,
start, end, what);
-ret = map_mmio_regions(d, start, end - start + 1, start);
+ret = map_mmio_regions(d, start, end - start, start);
 if ( ret )
 printk(Failed to map %s @ %PRIpaddr to dom%d\n,
what, start, d-domain_id);
-- 
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 1/4] xen: arm: Add earlyprintk for McDivitt.

[Ian Campbell]

Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
 xen/arch/arm/Rules.mk |6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..ef887a5 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
 EARLY_UART_BASE_ADDRESS := 0x1c02
 EARLY_UART_REG_SHIFT := 2
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
+EARLY_PRINTK_INC := 8250
+EARLY_PRINTK_BAUD := 9600
+EARLY_UART_BASE_ADDRESS := 0x1c021000
+EARLY_UART_REG_SHIFT := 2
+endif
 ifeq ($(CONFIG_EARLY_PRINTK), juno)
 EARLY_PRINTK_INC := pl011
 EARLY_PRINTK_BAUD := 115200
-- 
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 3/4] xen: arm: correct specific mappings for PCIE0 on X-Gene

[Ian Campbell]

The region assigned to PCIE0, according to the docs, is 0x0e0 to
0x100. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).

Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
 xen/arch/arm/platforms/xgene-storm.c |   18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 38674cd..6c432a1 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -89,22 +89,8 @@ static int xgene_storm_specific_mapping(struct domain *d)
 int ret;
 
 /* Map the PCIe bus resources */
-ret = map_one_mmio(d, PCI MEM REGION, paddr_to_pfn(0xe0UL),
-paddr_to_pfn(0xe01000UL));
-if ( ret )
-goto err;
-
-ret = map_one_mmio(d, PCI IO REGION, paddr_to_pfn(0xe08000UL),
-   paddr_to_pfn(0xe08001UL));
-if ( ret )
-goto err;
-
-ret = map_one_mmio(d, PCI CFG REGION, paddr_to_pfn(0xe0d000UL),
-paddr_to_pfn(0xe0d020UL));
-if ( ret )
-goto err;
-ret = map_one_mmio(d, PCI MSI REGION, paddr_to_pfn(0xe01000UL),
-paddr_to_pfn(0xe01080UL));
+ret = map_one_mmio(d, PCI MEMORY, paddr_to_pfn(0x0e0UL),
+paddr_to_pfn(0x010UL));
 if ( ret )
 goto err;
 
-- 
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 4/4] xen: arm: Support the other 4 PCI buses on Xgene

[Ian Campbell]

Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.

This results in no change for Mustang.

Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
 xen/arch/arm/platforms/xgene-storm.c |   84 --
 1 file changed, 71 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 6c432a1..926c325 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -78,35 +78,31 @@ static int map_one_spi(struct domain *d, const char *what,
 return ret;
 }
 
-/*
- * Xen does not currently support mapping MMIO regions and interrupt
- * for bus child devices (referenced via the ranges and
- * interrupt-map properties to domain 0). Instead for now map the
- * necessary resources manually.
- */
-static int xgene_storm_specific_mapping(struct domain *d)
+/* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
+static int xgene_storm_pcie_specific_mapping(struct domain *d,
+ paddr_t base, paddr_t end,
+ int base_spi)
 {
 int ret;
 
 /* Map the PCIe bus resources */
-ret = map_one_mmio(d, PCI MEMORY, paddr_to_pfn(0x0e0UL),
-paddr_to_pfn(0x010UL));
+ret = map_one_mmio(d, PCI MEMORY, paddr_to_pfn(base), paddr_to_pfn(end));
 if ( ret )
 goto err;
 
-ret = map_one_spi(d, PCI#INTA, 0xc2, DT_IRQ_TYPE_LEVEL_HIGH);
+ret = map_one_spi(d, PCI#INTA, base_spi+0, DT_IRQ_TYPE_LEVEL_HIGH);
 if ( ret )
 goto err;
 
-ret = map_one_spi(d, PCI#INTB, 0xc3, DT_IRQ_TYPE_LEVEL_HIGH);
+ret = map_one_spi(d, PCI#INTB, base_spi+1, DT_IRQ_TYPE_LEVEL_HIGH);
 if ( ret )
 goto err;
 
-ret = map_one_spi(d, PCI#INTC, 0xc4, DT_IRQ_TYPE_LEVEL_HIGH);
+ret = map_one_spi(d, PCI#INTC, base_spi+2, DT_IRQ_TYPE_LEVEL_HIGH);
 if ( ret )
 goto err;
 
-ret = map_one_spi(d, PCI#INTD, 0xc5, DT_IRQ_TYPE_LEVEL_HIGH);
+ret = map_one_spi(d, PCI#INTD, base_spi+3, DT_IRQ_TYPE_LEVEL_HIGH);
 if ( ret )
 goto err;
 
@@ -115,6 +111,68 @@ err:
 return ret;
 }
 
+/*
+ * Xen does not currently support mapping MMIO regions and interrupt
+ * for bus child devices (referenced via the ranges and
+ * interrupt-map properties to domain 0). Instead for now map the
+ * necessary resources manually.
+ */
+static int xgene_storm_specific_mapping(struct domain *d)
+{
+struct dt_device_node *node = NULL;
+int ret;
+
+while ( (node = dt_find_compatible_node(node, pci, apm,xgene-pcie)) )
+{
+u64 addr;
+
+/* Identify the bus via it's control register address */
+ret = dt_device_get_address(node, 0, addr, NULL);
+if ( ret  0 )
+return ret;
+
+if ( !dt_device_is_available(node) )
+continue;
+
+   switch ( addr )
+{
+case 0x1f2b: /* PCIe0 */
+ret = xgene_storm_pcie_specific_mapping(d,
+0x0e0UL, 0x100UL, 0xc2);
+break;
+case 0x1f2c: /* PCIe1 */
+ret = xgene_storm_pcie_specific_mapping(d,
+0x0d0UL, 0x0e0UL, 0xc8);
+break;
+case 0x1f2d: /* PCIe2 */
+ret = xgene_storm_pcie_specific_mapping(d,
+0x090UL, 0x0a0UL, 0xce);
+break;
+case 0x1f50: /* PCIe3 */
+ret = xgene_storm_pcie_specific_mapping(d,
+0x0a0UL, 0x0c0UL, 0xd4);
+break;
+case 0x1f51: /* PCIe4 */
+ret = xgene_storm_pcie_specific_mapping(d,
+0x0c0UL, 0x0d0UL, 0xda);
+break;
+
+default:
+/* Ignore unknown PCI busses */
+ret = 0;
+break;
+}
+
+if ( ret  0 )
+return ret;
+
+printk(Mapped additional regions for PCIe device at 0x%PRIx64\n,
+   addr);
+}
+
+return 0;
+}
+
 static void xgene_storm_reset(void)
 {
 void __iomem *addr;
-- 
1.7.10.4


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

Re: [Xen-devel] Xen 4.5 random freeze question

[Andrii Tseglytskyi]

Hi Stefano,

No hangs with this change.
Complete log is the following:

U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
DRA752 ES1.0
ethaddr not set. Validating first E-fuse MAC
cpsw
- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 - 9fff
(XEN) RAM: a000 - bfff
(XEN) RAM: c000 - dfff
(XEN)
(XEN) MODULE[1]: c200 - c20069aa
(XEN) MODULE[2]: c000 - c200
(XEN) MODULE[3]:  - 
(XEN) MODULE[4]: c300 - c301
(XEN)  RESVD[0]: ba30 - bfd0
(XEN)  RESVD[1]: 9580 - 9590
(XEN)  RESVD[2]: 98a0 - 98b0
(XEN)  RESVD[3]: 95f0 - 98a0
(XEN)  RESVD[4]: 9590 - 95f0
(XEN)
(XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
(XEN) Placing Xen at 0xdfe0-0xe000
(XEN) Xen heap: d200-de00 (49152 pages)
(XEN) Dom heap: 344064 pages
(XEN) Domain heap initialised
(XEN) Looking for UART console serial0
 Xen 4.5-unstable
(XEN) Xen version 4.5-unstable (atseglytskyi@)
(arm-linux-gnueabihf-gcc (crosstool-NG
linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
20130328 (prerelease)) debu4
(XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
(XEN) Processor: 412fc0f2: ARM Limited, variant: 0x2, part 0xc0f, rev 0x2
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 2000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Platform: TI DRA7
(XEN) /psci method must be smc, but is: hvc
(XEN) Set AuxCoreBoot1 to dfe0004c (0020004c)
(XEN) Set AuxCoreBoot0 to 0x20
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer at 6144 KHz
(XEN) GIC initialization:
(XEN) gic_dist_addr=48211000
(XEN) gic_cpu_addr=48212000
(XEN) gic_hyp_addr=48214000
(XEN) gic_vcpu_addr=48216000
(XEN) gic_maintenance_irq=25
(XEN) GIC: 192 lines, 2 cpus, secure (IID 043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Brought up 2 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module 2
(XEN) Populate P2M 0xc800-0xd000 (1:1 mapping for dom0)
(XEN) Loading zImage from c040 to cfc0-cff50c48
(XEN) Loading dom0 DTB to 0xcfa0-0xcfa05ba8
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 272kB init memory.
(XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
already pending in LR0
(XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
already pending in LR0
[0.00] /cpus/cpu@0 missing clock-frequency property
[0.00] /cpus/cpu@1 missing clock-frequency property
[0.140625] omap-gpmc omap-gpmc: failed to reserve memory
[0.187500] omap_l3_noc ocp.3: couldn't find resource 2
[0.273437] i2c i2c-1: of_i2c: invalid reg on
/ocp/i2c@48072000/camera_ov10635
[0.437500] ldo3: operation not allowed
[0.437500] omapdss HDMI error: can't set the voltage regulator
[0.468750] tfc_s9700 display0: tfc_s9700_probe probe
[0.468750] ov1063x 1-0030: No deserializer node found
[0.468750] ov1063x 1-0030: No serializer node found
[0.468750] ov1063x 1-0030: Failed writing register 0x0103!
[0.468750] dra7xx-vip vip1-0: Waiting for I2C subdevice 30
[0.578125] ahci ahci.0.auto: can't get clock
[0.898437] ldc_module_init
[1.304687] Missing dual_emac_res_vlan in DT.
[1.304687] Using 1 as Reserved VLAN for 0 slave
[1.312500] Missing dual_emac_res_vlan in DT.
[1.320312] Using 2 as Reserved VLAN for 1 slave
[1.382812] Freeing init memory: 236K
sh: write error: No such device
Cannot identify '/dev/camera0': 2, No such file or directory
Parsing config from /xen/images/DomUAndroid.cfg
XSM Disabled: seclabel not supported
(XEN) do_physdev_op 16 cmd=13: not implemented yet
libxl: error: libxl_create.c:1092:domcreate_launch_dm: failed give
dom1 access to irq 53: Function not 

Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.

[Don Koch]

On Tue, 18 Nov 2014 16:35:42 +
Jan Beulich jbeul...@suse.com wrote:

  On 18.11.14 at 16:26, dk...@verizon.com wrote:
  If we restore an xsave area from an older xen that has a larger
  size than the xcr0 bit call for, it is possible to have non-zero
  data in the unused area if an xsave has ever been done that used
  that area (e.g. during a context switch). Since the vcpu's xsave
  area is never zeroed after the initial allocation, that data is
  still there.
 
 This needs more explanation: xcr0_accum is named this way
 because bits never disappear from it. Hence afaics any piece of
 the xsave area ever having got written with a non-zero value
 would be part of the data actually used on migration.

Let me investigate this further. Since the initial xsave area is cleared
when allocated, I see no other way to get anything in there.

  --- a/xen/arch/x86/hvm/hvm.c
  +++ b/xen/arch/x86/hvm/hvm.c
  @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain 
  *d, hvm_domain_context_t *h)
   printk(XENLOG_G_WARNING
  HVM%d.%u restore mismatch: xsave length %#x  %#x 
  (non-zero data at %#x)\n,
  d-domain_id, vcpuid, desc-length, size, i);
  -return -EOPNOTSUPP;
  +break;
   }
   }
   printk(XENLOG_G_WARNING
 
 Even if we really have to go this route, you should recall the
 discussion on the earlier patch of yours: The end result should
 not be that two messages get logged for a single event.

Ah, yes. Agreed. Will fix if my investigation reveals what occurred.

 Jan
 

Konrad: Yes, this will be 4.5 fodder, pending the aforementioned
investigation.

Thanks,
-d

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

Re: [Xen-devel] Problems accessing passthrough PCI device

[Jan Beulich]

 On 18.11.14 at 17:24, furryfutt...@gmail.com wrote:
 Hello Jan,
 
 Friday, November 14, 2014, 5:27:36 AM, you wrote:
 
 I implied your earlier statement to mean that. But - did you also
 verify that the three flags actually end up set (ideally from both
 DomU and Dom0 perspective)? The PCI backend may be screwing
 up things...
 
 Yes I do verify the write. How do I check this from Dom0?
 
 Just use lspci.
 
 I've just checked this with lspci. I see that the IO is being enabled.

Memory you mean.

 Any   other   idea   on   why I might be reading back 0xff for all PCI
 memory area reads? The lspci output follows.

Since this isn't behind a bridge - no, not really. Did you try this with
any other device for comparison purposes?

Jan


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

Re: [Xen-devel] [PATCH 0/4 for-4.5] xen: arm: xgene bug fixes + support for McDivitt

[Ian Campbell]

On Tue, 2014-11-18 at 16:44 +, Ian Campbell wrote:
 These patches:

... which are also at
git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1

Ian.


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

Re: [Xen-devel] [PATCH for-4.5 1/4] xen: arm: Add earlyprintk for McDivitt.

[Julien Grall]

Hi Ian,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
 Signed-off-by: Ian Campbell ian.campb...@citrix.com
 ---
  xen/arch/arm/Rules.mk |6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
 index 572d854..ef887a5 100644
 --- a/xen/arch/arm/Rules.mk
 +++ b/xen/arch/arm/Rules.mk
 @@ -95,6 +95,12 @@ EARLY_PRINTK_BAUD := 115200
  EARLY_UART_BASE_ADDRESS := 0x1c02
  EARLY_UART_REG_SHIFT := 2
  endif
 +ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt)
 +EARLY_PRINTK_INC := 8250
 +EARLY_PRINTK_BAUD := 9600

EARLY_PRINTK_BAUD is not necessary as we don't use the initialization
function (EARLY_PRINTK_INIT_UART is not set).

With the EARLY_PRINTK_BAUD dropped, this could be merged with the
xgene-storm  early printk (I didn't really understand why the baud rate
is different). But I don't think it's 4.5 material.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.5 3/4] xen: arm: correct specific mappings for PCIE0 on X-Gene

[Julien Grall]

Hi Ian,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
 The region assigned to PCIE0, according to the docs, is 0x0e0 to
 0x100. They make no distinction between PCI CFG and PCI IO mem within
 this range (in fact, I'm not sure that isn't up to the driver).
 
 Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@linaro.org

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH] libxl: Document device parameter of libxl_device_type_add functions

[Euan Harris]

The device parameter of libxl_device_type_add is an in/out parameter.
Unspecified fields are filled in with appropriate values for the created
device when the function returns.  Document this behaviour.

Signed-off-by: Euan Harris euan.har...@citrix.com
---
 tools/libxl/libxl.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c3451bd..41d6e8d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
nr_vtpms);
  *   domain to connect to the device and therefore cannot block on the
  *   guest.
  *
+ *   device is an in/out parameter:  fields left unspecified when the
+ *   structure is passed in are filled in with appropriate values for
+ *   the device created.
+ *
  * libxl_device_type_remove(ctx, domid, device):
  *
  *   Removes the given device from the specified domain by performing
-- 
1.9.3


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

Re: [Xen-devel] [PATCH for-4.5 4/4] xen: arm: Support the other 4 PCI buses on Xgene

[Julien Grall]

Hi Ian,

On 11/18/2014 04:44 PM, Ian Campbell wrote:
 Currently we only establish specific mappings for pcie0, which is
 used on the Mustang platform. However at least McDivitt uses pcie3.
 So wire up all the others, based on whether the corresponding DT node
 is marked as available.
 
 This results in no change for Mustang.

Hopefully, we will support PCI DT parsing in Xen 4.6!

 Signed-off-by: Ian Campbell ian.campb...@citrix.com
 ---
 +/*
 + * Xen does not currently support mapping MMIO regions and interrupt
 + * for bus child devices (referenced via the ranges and
 + * interrupt-map properties to domain 0). Instead for now map the
 + * necessary resources manually.
 + */
 +static int xgene_storm_specific_mapping(struct domain *d)
 +{
 +struct dt_device_node *node = NULL;

NIT: const struct

 +int ret;
 +
 +while ( (node = dt_find_compatible_node(node, pci, apm,xgene-pcie)) )
 +{
 +u64 addr;
 +
 +/* Identify the bus via it's control register address */
 +ret = dt_device_get_address(node, 0, addr, NULL);
 +if ( ret  0 )
 +return ret;
 +
 +if ( !dt_device_is_available(node) )
 +continue;
 +
 +   switch ( addr )
 +{
 +case 0x1f2b: /* PCIe0 */
 +ret = xgene_storm_pcie_specific_mapping(d,
 +0x0e0UL, 0x100UL, 0xc2);
 +break;
 +case 0x1f2c: /* PCIe1 */
 +ret = xgene_storm_pcie_specific_mapping(d,
 +0x0d0UL, 0x0e0UL, 0xc8);
 +break;
 +case 0x1f2d: /* PCIe2 */
 +ret = xgene_storm_pcie_specific_mapping(d,
 +0x090UL, 0x0a0UL, 0xce);
 +break;
 +case 0x1f50: /* PCIe3 */
 +ret = xgene_storm_pcie_specific_mapping(d,
 +0x0a0UL, 0x0c0UL, 0xd4);
 +break;
 +case 0x1f51: /* PCIe4 */
 +ret = xgene_storm_pcie_specific_mapping(d,
 +0x0c0UL, 0x0d0UL, 0xda);
 +break;
 +
 +default:
 +/* Ignore unknown PCI busses */

I would add a
printk(Ignoring PCI busses %s\n, dt_node_full_name(dev));

 +ret = 0;
 +break;

continue? You can't assume the order of the PCI busses in the device tree.

 +}
 +
 +if ( ret  0 )
 +return ret;
 +
 +printk(Mapped additional regions for PCIe device at 0x%PRIx64\n,
 +   addr);

Printing the device tree path would be more helpful than the address.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] libxl: Document device parameter of libxl_device_type_add functions

[Ian Jackson]

Euan Harris writes ([PATCH] libxl: Document device parameter of 
libxl_device_type_add functions):
 The device parameter of libxl_device_type_add is an in/out parameter.
 Unspecified fields are filled in with appropriate values for the created
 device when the function returns.  Document this behaviour.

Thanks.

Acked-by: Ian Jackson ian.jack...@eu.citrix.com

Konrad, this should go into 4.5 IMO because it's a doc comment
describing existing behaviour which we want everyone to rely on.

Ian.

 Signed-off-by: Euan Harris euan.har...@citrix.com
 ---
  tools/libxl/libxl.h | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
 index c3451bd..41d6e8d 100644
 --- a/tools/libxl/libxl.h
 +++ b/tools/libxl/libxl.h
 @@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
 nr_vtpms);
   *   domain to connect to the device and therefore cannot block on the
   *   guest.
   *
 + *   device is an in/out parameter:  fields left unspecified when the
 + *   structure is passed in are filled in with appropriate values for
 + *   the device created.
 + *
   * libxl_device_type_remove(ctx, domid, device):
   *
   *   Removes the given device from the specified domain by performing
 -- 
 1.9.3
 

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

Re: [Xen-devel] Xen 4.5 random freeze question

[Stefano Stabellini]

Hello Andrii,
we are getting closer :-)

It would help if you post the output with GIC_DEBUG defined but without
the other change that fixes the issue.

I think the problem is probably due to software irqs.
You are getting too many

gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still lr_pending

messages. That means you are loosing virtual SGIs (guest VCPU to guest
VCPU). It would be best to investigate why, especially if you get many
more of the same messages without the MAINTENANCE_IRQ change I
suggested.

This patch might also help understading the problem more:


diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b7516c0..5eaeca2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -717,7 +717,12 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 list_for_each_entry_safe ( p, t, v-arch.vgic.lr_pending, lr_queue )
 {
 i = find_first_zero_bit(this_cpu(lr_mask), nr_lrs);
-if ( i = nr_lrs ) return;
+if ( i = nr_lrs )
+{
+gdprintk(XENLOG_DEBUG, LRs full, not injecting irq=%u into 
d%dv%d\n,
+p-irq, v-domain-domain_id, v-vcpu_id);
+continue;
+}
 
 spin_lock_irqsave(gic.lock, flags);
 gic_set_lr(i, p, GICH_LR_PENDING);




On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
 Hi Stefano,
 
 No hangs with this change.
 Complete log is the following:
 
 U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
 DRA752 ES1.0
 ethaddr not set. Validating first E-fuse MAC
 cpsw
 - UART enabled -
 - CPU  booting -
 - Xen starting in Hyp mode -
 - Zero BSS -
 - Setting up control registers -
 - Turning on paging -
 - Ready -
 (XEN) Checking for initrd in /chosen
 (XEN) RAM: 8000 - 9fff
 (XEN) RAM: a000 - bfff
 (XEN) RAM: c000 - dfff
 (XEN)
 (XEN) MODULE[1]: c200 - c20069aa
 (XEN) MODULE[2]: c000 - c200
 (XEN) MODULE[3]:  - 
 (XEN) MODULE[4]: c300 - c301
 (XEN)  RESVD[0]: ba30 - bfd0
 (XEN)  RESVD[1]: 9580 - 9590
 (XEN)  RESVD[2]: 98a0 - 98b0
 (XEN)  RESVD[3]: 95f0 - 98a0
 (XEN)  RESVD[4]: 9590 - 95f0
 (XEN)
 (XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
 dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
 (XEN) Placing Xen at 0xdfe0-0xe000
 (XEN) Xen heap: d200-de00 (49152 pages)
 (XEN) Dom heap: 344064 pages
 (XEN) Domain heap initialised
 (XEN) Looking for UART console serial0
  Xen 4.5-unstable
 (XEN) Xen version 4.5-unstable (atseglytskyi@)
 (arm-linux-gnueabihf-gcc (crosstool-NG
 linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3
 20130328 (prerelease)) debu4
 (XEN) Latest ChangeSet: Thu Jul 3 12:55:26 2014 +0300 git:3ee354f-dirty
 (XEN) Processor: 412fc0f2: ARM Limited, variant: 0x2, part 0xc0f, rev 0x2
 (XEN) 32-bit Execution:
 (XEN)   Processor Features: 1131:00011011
 (XEN) Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
 (XEN) Extensions: GenericTimer Security
 (XEN)   Debug Features: 02010555
 (XEN)   Auxiliary Features: 
 (XEN)   Memory Model Features: 10201105 2000 0124 02102211
 (XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
 (XEN) Platform: TI DRA7
 (XEN) /psci method must be smc, but is: hvc
 (XEN) Set AuxCoreBoot1 to dfe0004c (0020004c)
 (XEN) Set AuxCoreBoot0 to 0x20
 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
 (XEN) Using generic timer at 6144 KHz
 (XEN) GIC initialization:
 (XEN) gic_dist_addr=48211000
 (XEN) gic_cpu_addr=48212000
 (XEN) gic_hyp_addr=48214000
 (XEN) gic_vcpu_addr=48216000
 (XEN) gic_maintenance_irq=25
 (XEN) GIC: 192 lines, 2 cpus, secure (IID 043b).
 (XEN) Using scheduler: SMP Credit Scheduler (credit)
 (XEN) I/O virtualisation disabled
 (XEN) Allocated console ring of 16 KiB.
 (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
 (XEN) Bringing up CPU1
 - CPU 0001 booting -
 - Xen starting in Hyp mode -
 - Setting up control registers -
 - Turning on paging -
 - Ready -
 (XEN) CPU 1 booted.
 (XEN) Brought up 2 CPUs
 (XEN) *** LOADING DOMAIN 0 ***
 (XEN) Loading kernel from boot module 2
 (XEN) Populate P2M 0xc800-0xd000 (1:1 mapping for dom0)
 (XEN) Loading zImage from c040 to 
 cfc0-cff50c48
 (XEN) Loading dom0 DTB to 0xcfa0-0xcfa05ba8
 (XEN) Std. Loglevel: All
 (XEN) Guest Loglevel: All
 (XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch
 input to Xen)
 (XEN) Freed 272kB init memory.
 (XEN) gic.c:673:d0v0 trying to inject irq=2 into d0v0, when it is
 already pending in LR0
 (XEN) gic.c:673:d0v0 trying to inject irq=2 into 

Re: [Xen-devel] delaying 4.4.2 and 4.3.4

[Daniel Kiper]

On Thu, Nov 13, 2014 at 09:05:47AM +, Jan Beulich wrote:
 All,

 while the 3 month period since the previous stable releases would
 expire at the beginning of December, looking at the number of
 changes in the stable trees I don't think starting preparations right
 now would make much sense. Unless I hear severe objections to
 this plan, and unless 4.5 gets significantly delayed, I think we
 should look at RC1s for them once 4.5 is (almost) out the door.
 That'll also minimize collisions between testing needs 4.5 and the
 stable releases have.

By the way, what I should do to have commit 
f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
(tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
I am asking about that more than five months. This patch fixes real bug.

Daniel

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

Re: [Xen-devel] [PATCH] libxl: Document device parameter of libxl_device_type_add functions

[Konrad Rzeszutek Wilk]

On Tue, Nov 18, 2014 at 05:44:20PM +, Ian Jackson wrote:
 Euan Harris writes ([PATCH] libxl: Document device parameter of 
 libxl_device_type_add functions):
  The device parameter of libxl_device_type_add is an in/out parameter.
  Unspecified fields are filled in with appropriate values for the created
  device when the function returns.  Document this behaviour.
 
 Thanks.
 
 Acked-by: Ian Jackson ian.jack...@eu.citrix.com
 
 Konrad, this should go into 4.5 IMO because it's a doc comment
 describing existing behaviour which we want everyone to rely on.

Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 
 Ian.
 
  Signed-off-by: Euan Harris euan.har...@citrix.com
  ---
   tools/libxl/libxl.h | 4 
   1 file changed, 4 insertions(+)
  
  diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
  index c3451bd..41d6e8d 100644
  --- a/tools/libxl/libxl.h
  +++ b/tools/libxl/libxl.h
  @@ -1109,6 +1109,10 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
  nr_vtpms);
*   domain to connect to the device and therefore cannot block on the
*   guest.
*
  + *   device is an in/out parameter:  fields left unspecified when the
  + *   structure is passed in are filled in with appropriate values for
  + *   the device created.
  + *
* libxl_device_type_remove(ctx, domid, device):
*
*   Removes the given device from the specified domain by performing
  -- 
  1.9.3
  

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

[Xen-devel] Backport request for tools/hotplug: set mtu from bridge for tap interface

[Ian Jackson]

Daniel Kiper writes (Re: [Xen-devel] delaying 4.4.2 and 4.3.4):
 By the way, what I should do to have commit 
 f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
 (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
 I am asking about that more than five months. This patch fixes real bug.

I don't seem to be able to find these mails from you but my mailbox is
very big.  The normal thing ought to be for you to post a backport
request and CC the stable tools maintainer (ie me).  I'm sorry if I
dropped your message.

The patch looks reasonable to backport.  I have put it on my list for
backporting later.  I'll wait a bit to see if anyone objects.
(I have also CC'd the patch's original author and also Ian C because
he acked it for unstable.)

Does it apply cleanly to 4.3 and 4.4?  I haven't checked.  Daniel, if
you could check that, that would be helpful.  If it doesn't then the
normal process would be for the backport requestor (ie you) to post
the revised patch against 4.3 and/or 4.4.

Thanks,
Ian.

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

[Xen-devel] [xen-4.2-testing test] 31630: regressions - FAIL

[xen . org]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 30594
 test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. 
vs. 30594

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu  5 xen-bootfail pass in 31592
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot  fail pass in 31592
 test-i386-i386-pair   7 xen-boot/src_host   fail pass in 31592
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail pass in 31451
 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail in 31592 pass in 
31288
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 31288 pass in 31630
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass 
in 31630
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 31288 pass in 31630
 test-amd64-i386-pv7 debian-install fail in 31451 pass in 31630

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
 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-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen5 rumpuserxen-buildfail   never pass
 build-amd64-rumpuserxen   5 rumpuserxen-buildfail   never pass
 test-amd64-amd64-xl-sedf  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 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  1 build-check(1) blocked n/a
 test-i386-i386-xl-winxpsp3   14 guest-stop   fail   never pass
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 31592 never 
pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-startfail in 31592 never pass
 test-amd64-amd64-libvirt  9 guest-start   fail in 31592 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop  fail in 31592 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stopfail in 31592 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop  fail in 31592 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stopfail in 31592 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop  fail in 31592 never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stopfail in 31592 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop  fail in 31592 never pass

version targeted for testing:
 xen  c844974caf1501b6527533ab2a3d27ea8920ab90
baseline version:
 xen  fad105dd0ac1a224d91757afee01acd4566f7e82


People who touched revisions under test:
  Andrew Cooper 

[Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to support arch configuration

[Julien Grall]

On ARM the virtual GIC may differ between each guest (emulated GIC version,
number of SPIs...). Those informations are already known at the domain creation
and can never change.

For now only the gic_version is set. In 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, a dummy structure
(C-spec compliant) has been created to factorize the code on the toolstack.

Some external tools (qemu, xenstore) may require to create a domain. Rather
than asking them to take care of the arch-specific domain configuration, let
the current function (xc_domain_create) to chose a default configuration and
introduce a new one (xc_domain_create_config).

This patch also drop the previously DOMCTL arm_configure_domain introduced
in Xen 4.5, as it has been made useless.

Signed-off-by: Julien Grall julien.gr...@linaro.org
Cc: Daniel De Graaf dgde...@tycho.nsa.gov
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich jbeul...@suse.com
Cc: George Dunlap george.dun...@eu.citrix.com

---
This is a follow-up of 
http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html

TODO: What about migration? For now the configuration lives in internal
libxl structure. We need a way to pass the domain configuration to the
other end.

I'm not sure if we should care of this right now as migration doesn't
yet exists on ARM.

For the xc_domain_create, Stefano S. was looking to drop PV domain
creation support in QEMU. So maybe I could simply extend xc_domain_create
and drop the xc_domain_create_config.
---
 tools/flask/policy/policy/modules/xen/xen.if |2 +-
 tools/libxc/include/xenctrl.h|   14 
 tools/libxc/xc_domain.c  |   46 +++---
 tools/libxl/libxl_arch.h |6 
 tools/libxl/libxl_arm.c  |   28 ++--
 tools/libxl/libxl_create.c   |   21 +---
 tools/libxl/libxl_dm.c   |3 +-
 tools/libxl/libxl_dom.c  |2 +-
 tools/libxl/libxl_internal.h |7 ++--
 tools/libxl/libxl_x86.c  |   10 ++
 xen/arch/arm/domain.c|   28 +++-
 xen/arch/arm/domctl.c|   34 ---
 xen/arch/arm/mm.c|6 ++--
 xen/arch/arm/setup.c |6 +++-
 xen/arch/x86/domain.c|3 +-
 xen/arch/x86/mm.c|6 ++--
 xen/arch/x86/setup.c |4 ++-
 xen/common/domain.c  |6 ++--
 xen/common/domctl.c  |3 +-
 xen/common/schedule.c|3 +-
 xen/include/public/arch-arm.h|9 +
 xen/include/public/arch-x86/xen.h|5 +++
 xen/include/public/domctl.h  |   20 ++-
 xen/include/xen/domain.h |3 +-
 xen/include/xen/sched.h  |8 +++--
 xen/xsm/flask/hooks.c|3 --
 xen/xsm/flask/policy/access_vectors  |2 --
 27 files changed, 168 insertions(+), 120 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if 
b/tools/flask/policy/policy/modules/xen/xen.if
index fa69c9d..641c797 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
getdomaininfo hypercall setvcpucontext setextvcpucontext
getscheduler getvcpuinfo getvcpuextstate getaddrsize
getaffinity setaffinity };
-   allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim 
set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op configure_domain };
+   allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim 
set_max_evtchn set_vnumainfo get_vnumainfo psr_cmt_op };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op };
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 45e282c..9976ab1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -477,18 +477,20 @@ typedef union
 } start_info_any_t;
 #endif
 
+
+typedef arch_domainconfig_t xc_domain_configuration_t;
+int xc_domain_create_config(xc_interface *xch,
+uint32_t ssidref,
+xen_domain_handle_t handle,
+uint32_t flags,
+uint32_t *pdomid,
+ 

Re: [Xen-devel] support for sharing huge pages with grant table?

[Timothy Wood]

On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell ian.campb...@citrix.com
wrote:

 On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
  Hi,
 
  I am curious if Xen currently supports sharing hugepages between
  domains (specifically ones originally allocated in Dom-0 and shared
  with a guest r/w).  I've seen some references to huge pages in the
  archives of this list, but not in relation to the grant mechanism.

 I don't think the grant table has any specific superpage support. It
 might be an interesting extension to consider though (for the sorts of
 reasons you would like it).

 You could grant a superpage using multiple 4K grants to cover whichever
 subset of the superpage you need to expose to the other end. Now granted
 (no pun intended ;-)) that might suck up 512 grefs in the worst case,
 which is a bit mad...


If the grants just need to be setup once at system startup and then are
never changed, is this likely to pose any particular problem (i.e., does
the size of the grant table only affect things when new grants are being
setup, or is it checked regularly at runtime)?



  Also, can someone confirm that superpages are another term for huge
  pages in Xen?

 Yes. Or at least I think so.

  This would be helpful for some work we are doing on high speed
  networking to VMs---DPDK stores packets into huge pages and we'd like
  to get those to VMs as quickly as possible.

 This seems like a reasonable usecase to me. Having added this to the
 grant table interface I suppose you would also need to consider
 extensions to the individual PV I/O protocols (netif.h) to allow them to
 signal when a grant was huge. You might have issues with e.g. finding
 enough bits to represent the larger sizes...


I hope you guys will think it is useful enough to someday implement it..
I've got a handful of undergrad and grad students who work with me, but
this might be beyond our capabilities at this point ;)

In our prior system, we did this on KVM.  In that case we used QEMU to
define a virtual PCI device that mapped memory from the host OS and let it
be accessed by a VM.  Any thoughts on whether the same approach would work
with Xen?  I'd originally thought just using the grant table to enable
sharing would make this a lot easier in Xen, but maybe not since it doesn't
support huge pages.

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

[Xen-devel] [PATCH for-4.5] scripts/get_maintainer.pl: Correctly CC the maintainers

[Julien Grall]

By default, the script get_maintainer.pl will remove duplicates email as soon
as it appends the list of maintainers of a new file, and therefore override
the role of the developper.

On complex patch (see [1]), this will result to ommitting randomly some
maintainers.

This could be fixed by not removing the duplicate email in the list. Once the
list is created, when it's necessary, the script will drop the REST people
and remove duplicata.

Example:

Patch: https://patches.linaro.org/41083/

Before:

Daniel De Graaf dgde...@tycho.nsa.gov
Ian Jackson ian.jack...@eu.citrix.com
Stefano Stabellini stefano.stabell...@eu.citrix.com
Ian Campbell ian.campb...@citrix.com
Wei Liu wei.l...@citrix.com
George Dunlap george.dun...@eu.citrix.com
xen-devel@lists.xen.org

After:

Daniel De Graaf dgde...@tycho.nsa.gov
Ian Jackson ian.jack...@eu.citrix.com
Stefano Stabellini stefano.stabell...@eu.citrix.com
Ian Campbell ian.campb...@citrix.com
Wei Liu wei.l...@citrix.com
Stefano Stabellini stefano.stabell...@citrix.com
Tim Deegan t...@xen.org
Keir Fraser k...@xen.org
Jan Beulich jbeul...@suse.com
George Dunlap george.dun...@eu.citrix.com
xen-devel@lists.xen.org

[1] http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00060.html

Signed-off-by: Julien Grall julien.gr...@linaro.org
CC: Don Slutz dsl...@verizon.com

---
I would like to see this patch in Xen 4.5 and backported to Xen 4.4 (first
time the script has been introduced).

Developpers using this script won't ommitted to cc some maintainers, and it
will avoid maintainers complaining about miss CC.

The only drawbacks I can see is there is too much people CCed (the
patch d67738db was intended to avoid CCing Keir too often).

Also, if the maintainers is referenced twice in the file MAINTAINERS with
different email, the script won't notice it's duplicated and list 2 times.
Though, for this one it could be fixed by modifying  the MAINTAINERS file.
Is it worth for Xen 4.5? For know, it seems to only happen with Stefano.
---
 scripts/get_maintainer.pl |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index df920e2..cc445cd 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -35,7 +35,7 @@ my $email_git_min_percent = 5;
 my $email_git_since = 1-year-ago;
 my $email_hg_since = -365;
 my $interactive = 0;
-my $email_remove_duplicates = 1;
+my $email_remove_duplicates = 0;
 my $email_use_mailmap = 1;
 my $email_drop_the_rest_supporter_if_supporter_found = 1;
 my $output_multiline = 1;
-- 
1.7.10.4


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

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq

[Konrad Rzeszutek Wilk]

On Tue, Nov 18, 2014 at 05:20:44PM +, Jan Beulich wrote:
  On 18.11.14 at 18:03, li...@eikelenboom.it wrote:
  Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
   1) test_and_[set|clear]_bit sometimes return unexpected values.
  [But this might be invalid as the addition of the 8303faaf25a8
   might be correct - as the second dpci the softirq is processing
   could be the MSI one]
  
  Would there be an easy way to stress test this function separately in some 
  debugging function to see if it indeed is returning unexpected values ?
 
 I don't think there's a reasonable chance of these functions to return
 unexpected values - they're being used elsewhere, and you'd have
 had other problems in the past if they didn't behave as expected.

Interestingly most of the 'test_and_[set|clear]_bit operate on 'unsigned long'
while we do 'unsigned int' here. But the 'test_and'' are all btXl so double-word
safe.

The fact that Sander is able to get 'test_and_clear_bit(STATE_SCHED)' to return
zero - when in fact it should return a positive value - implies that some actor
is messing with the 'state' outside our raise/softirq dialogue.

pt_irq_guest_eoi does pirq_dpci-state = 0 unconditionally!

Lets see if this debug + potential patch helps. This should be applied
on top of the other patch you had. Just in case I am attaching all four
to this email.

From 8093140e374fceb9121ccd07726fb3898b212bfb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 18 Nov 2014 15:08:15 -0500
Subject: [PATCH 4/5] DEBUG4: Add an 'stamp' and potential fix.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 xen/drivers/passthrough/io.c | 57 +++-
 xen/include/xen/hvm/irq.h|  1 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index b786bd2..8a8fc62 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -26,6 +26,8 @@
 #include asm/hvm/iommu.h
 #include asm/hvm/support.h
 #include xen/hvm/irq.h
+#include xen/console.h
+
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
 
@@ -61,21 +63,29 @@ struct _debug_f {
 struct list_head list;
 unsigned int state;
 struct hvm_pirq_dpci *dpci;
+unsigned long stamp;
 };
 
 struct __debug {
 struct _debug_f ok;
 struct _debug_f poison;
 struct _debug_f raise;
+struct _debug_f busy_raise;
 struct _debug_f reset;
 struct _debug_f zombie_softirq;
 struct _debug_f zombie_raise;
+struct _debug_f timeout;
+struct _debug_f clear;
 };
 
 static DEFINE_PER_CPU(struct __debug, _d);
 
 void _record(struct _debug_f *d, struct hvm_pirq_dpci *pirq_dpci)
 {
+
+if (pirq_dpci-pirq)
+return;
+
 if (pirq_dpci-dom)
 d-domid = pirq_dpci-dom-domain_id;
 else
@@ -86,6 +96,7 @@ void _record(struct _debug_f *d, struct hvm_pirq_dpci 
*pirq_dpci)
 d-list.prev = pirq_dpci-softirq_list.prev;
 d-state = pirq_dpci-state;
 d-dpci = pirq_dpci;
+d-stamp = pirq_dpci-stamp++;
 }
 
 enum {
@@ -95,6 +106,9 @@ enum {
 OK_SOFTIRQ,
 OK_RAISE,
 OK_RESET,
+OK_TIMEOUT,
+OK_BUSY,
+OK_CLEAR,
 };
 
 static void dump_record(struct _debug_f *d, unsigned int type)
@@ -106,7 +120,11 @@ static void dump_record(struct _debug_f *d, unsigned int 
type)
 [OK_SOFTIRQ] = OK-softirq,
 [OK_RAISE]   = OK-raise  ,
 [OK_RESET]   = OK-reset  ,
+[OK_TIMEOUT] = OK-timeout,
+[OK_BUSY]= OK-busy   ,
+[OK_CLEAR]   = OK-clear  ,
 };
+#if 0
 #define LONG(x) [_HVM_IRQ_DPCI_##x] = #x
 static const char *const names_flag[] = {
 LONG(MACH_PCI_SHIFT),
@@ -117,6 +135,7 @@ static void dump_record(struct _debug_f *d, unsigned int 
type)
 };
 #undef LONG
 unsigned int i;
+#endif
 s_time_t now;
 
 if ( d-domid == 0 )
@@ -126,20 +145,21 @@ static void dump_record(struct _debug_f *d, unsigned int 
type)
 BUG();
 
 now = NOW();
-printk(d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p,
+printk(d%d %s %lumsec ago, state:%x, %ld count, [prev:%p, next:%p] %p 
%lx,
d-domid, names[type],
(unsigned long)((now - d-last) / MILLISECS(1)),
-d-state, d-count, d-list.prev, d-list.next, d-dpci);
+d-state, d-count, d-list.prev, d-list.next, d-dpci, d-stamp);
 
 if ( d-dpci )
 {
 struct hvm_pirq_dpci *pirq_dpci = d-dpci;
-
+#if 0
 for ( i = 0; i = _HVM_IRQ_DPCI_GUEST_MSI_SHIFT; i++ )
 if ( pirq_dpci-flags  (1  i) )
 printk(%s , names_flag[i]);
 
 printk( PIRQ:%d, pirq_dpci-pirq);
+#endif
 if (pirq_dpci-line)
 printk( LINE: %d, pirq_dpci-line);
 }
@@ -159,7 +179,10 @@ static void dump_debug(unsigned char key)
 printk(CPU%02d: \n ,cpu);
 dump_record(d-ok, OK_SOFTIRQ);
 dump_record(d-raise, OK_RAISE);
+   

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq

[Konrad Rzeszutek Wilk]

 
 Uhmm i thought i had these switched off (due to problems earlier and then 
 forgot 
 about them .. however looking at the earlier reports these lines were also in 
 those reports).
 
 The xen-syms and these last runs are all with a prestine xen tree cloned 
 today (staging 
 branch), so the qemu-xen and seabios defined with that were also freshly 
 cloned 
 and had a new default seabios config. (just to rule out anything stale in my 
 tree)
 
 If you don't see those messages .. perhaps your seabios and qemu trees (and 
 at least the 
 seabios config) are not the most recent (they don't get updated automatically 
 when you just do a git pull on the main tree) ?
 
 In /tools/firmware/seabios-dir/.config i have:
 CONFIG_USB=y
 CONFIG_USB_UHCI=y
 CONFIG_USB_OHCI=y
 CONFIG_USB_EHCI=y
 CONFIG_USB_XHCI=y
 CONFIG_USB_MSC=y
 CONFIG_USB_UAS=y
 CONFIG_USB_HUB=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_MOUSE=y
 

I seem to have the same thing. Perhaps it is my XHCI controller being wonky.

 And this is all just from a:
 - git clone git://xenbits.xen.org/xen.git -b staging
 - make clean  ./configure  make -j6  make -j6 install

Aye. 
.. snip..
   1) test_and_[set|clear]_bit sometimes return unexpected values.
  [But this might be invalid as the addition of the 8303faaf25a8
   might be correct - as the second dpci the softirq is processing
   could be the MSI one]
 
 Would there be an easy way to stress test this function separately in some 
 debugging function to see if it indeed is returning unexpected values ?

Sadly no. But you got me looking in the right direction when you mentioned
'timeout'.
 
   2) INIT_LIST_HEAD operations on the same CPU are not honored.
 
 Just curious, have you also tested the patches on AMD hardware ?

Yes. To reproduce this the first thing I did was to get an AMD box.

 
  
  When i look at the combination of (2) and (3), It seems it could be an 
  interaction between the two passed through devices and/or different IRQ 
  types.
 
  Could be - as in it is causing this issue to show up faster than
  expected. Or it is the one that triggers more than one dpci happening
  at the same time.
 
 Well that didn't seem to be it (see separate amendment i mailed previously)

Right, the current theory I've is that the interrupts are not being
Acked within 8 milisecond and we reset the 'state' - and at the same
time we get an interrupt and schedule it - while we are still processing
the same interrupt. This would explain why the 'test_and_clear_bit'
got the wrong value.

In regards to the list poison - following this thread of logic - with
the 'state = 0' set we open the floodgates for any CPU to put the same
'struct hvm_pirq_dpci' on its list.

We do reset the 'state' on _every_ GSI that is mapped to a guest - so
we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:

CPUX:   CPUY:
pt_irq_time_out:
state = 0;  
[out of timer coder, theraise_softirq
 pirq_dpci is on the dpci_list] [adds the pirq_dpci as state == 0]

softirq_dpcisoftirq_dpci:
list_del
[entries poison]
list_del = BOOM

Is what I believe is happening.

The INTX device - once I put a load on it - does not trigger
any pt_irq_time_out, so that would explain why I cannot hit this.

But I believe your card hits these hiccups.   

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

[Xen-devel] [PATCH] set pv guest default video_memkb to 0

[Zhigang Wang]

Before this patch, pv guest video_memkb is -1, which is an invalid value.
And it will cause the xenstore 'memory/targe' calculation wrong:

memory/target = info-target_memkb - info-video_memkb

Signed-off-by: Zhigang Wang zhigang.x.w...@oracle.com
---
 tools/libxl/libxl_create.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..1198225 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -357,6 +357,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 break;
 case LIBXL_DOMAIN_TYPE_PV:
 libxl_defbool_setdefault(b_info-u.pv.e820_host, false);
+if (b_info-video_memkb == LIBXL_MEMKB_DEFAULT)
+b_info-video_memkb = 0;
 if (b_info-shadow_memkb == LIBXL_MEMKB_DEFAULT)
 b_info-shadow_memkb = 0;
 if (b_info-u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
-- 
1.8.3.1


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

[Xen-devel] [linux-3.10 test] 31657: regressions - FAIL

[xen . org]

flight 31657 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31657/

Regressions :-(

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

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

Tests which did not succeed, but are not blocking:
 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-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-amd64-i386-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-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-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 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-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-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 linuxbe70188832b22a8f1a49d0e3a3eb2209f9cfdc8a
baseline version:
 linuxbe67db109090b17b56eb8eb2190cd70700f107aa


750 people touched revisions under test,
not listing them all


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  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 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 pass
 test-amd64-amd64-xl-pcipt-intel  fail
 test-amd64-i386-rhel6hvm-intel   pass
 test-amd64-i386-qemut-rhel6hvm-intel pass
 

[Xen-devel] [linux-next test] 31643: tolerable trouble: broken/fail/pass

[xen . org]

flight 31643 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start   fail baseline untested
 test-amd64-amd64-xl-sedf  9 guest-start fail baseline untested
 test-amd64-i386-xl-credit2   12 guest-localmigrate  fail baseline untested
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate  fail baseline untested
 test-amd64-i386-xl   12 guest-localmigrate  fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start fail baseline untested
 test-amd64-amd64-xl   9 guest-start fail baseline untested
 test-amd64-i386-xl-multivcpu 12 guest-localmigrate  fail baseline untested
 test-armhf-armhf-xl   9 guest-start fail baseline untested
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken baseline untested
 test-amd64-amd64-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-pair 16 guest-start/debian  fail baseline untested
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested

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-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   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-amd64-xl-qemuu-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-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass

version targeted for testing:
 linuxefefb5ca5da52f7537c7ced03d6e53408f13a26e
baseline version:
 linux56c381f93d57b88a3e667a2f55137947315c17e2

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

[Xen-devel] [rumpuserxen test] 31661: all pass - PUSHED

[xen . org]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen  9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
 rumpuserxen  1eb3666b469e307b20262e856229d0bd5d06a59e


People who touched revisions under test:
  Martin Lucina mar...@lucina.net


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-i386-rumpuserxen-i386 pass



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=rumpuserxen
+ revision=9716ed62cb1d73254b552e2077497d684c81639d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 
9716ed62cb1d73254b552e2077497d684c81639d
+ branch=rumpuserxen
+ revision=9716ed62cb1d73254b552e2077497d684c81639d
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock 
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : 

[Xen-devel] [libvirt test] 31660: tolerable FAIL - PUSHED

[xen . org]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass

version targeted for testing:
 libvirt  121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
baseline version:
 libvirt  72b4151f858df3564b82a8ebba60778b996b6dce


People who touched revisions under test:
  John Ferlan jfer...@redhat.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-libvirt fail
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  fail



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 
121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ branch=libvirt
+ revision=121fc4f9f331cc85cfc4c85c99b2cbf7ea5c53ac
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock 
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
 

Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

[Chen, Tiejun]

So without lookuping devices[i], how can we call func() for each sbdf as
you mentioned?


You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.



Yeah, so change this again,

int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
struct acpi_rmrr_unit *rmrr;
int rc = 0;
unsigned int i;
u16 bdf;

for_each_rmrr_device ( rmrr, bdf, i )
{
rc = func(PFN_DOWN(rmrr-base_address),
   PFN_UP(rmrr-end_address) -
PFN_DOWN(rmrr-base_address),
   PCI_SBDF(rmrr-segment, bdf),
  ctxt);
/* Hit this entry so just go next. */
if ( rc == 1 )
i = rmrr-scope.devices_cnt;
else if ( rc  0 )
return rc;
}

return rc;
}

Thanks
Tiejun

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

Re: [Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Zhang, Yang Z]

Tim Deegan wrote on 2014-11-18:
 At 14:26 + on 18 Nov (1416317209), Ian Campbell wrote:
 On Tue, 2014-11-18 at 11:41 +, Zhang, Yang Z wrote:
 Hmm - this is a pitfall waiting to happen.
 
 In the case that there is a heterogeneous setup with one 1G
 capable and one 1G incapable server, Xen cannot forcibly prevent
 the use of 1G pages on the capable hardware.  Any VM which
 guesses at hardware support by means other than cpuid features
 is liable to
 explode on migrate.
 
 But a normal guest shouldn't to guess it, right?
 
 IMHO any guest which does not use the mechanism explicitly provided
 for feature detection deserves to break randomly.
 
 Yes, that's a reasonable position (notwithstanding that we know such
 software exists).
 

Agree.

 In this case, the guest is entitled to _expect_ pagefaults on 1GB
 mappings if CPUID claims they are not supported.  That sounds like an
 unlikely thing for the guest to be relying on, but Xen itself does
 something similar for the SHOPT_FAST_FAULT_PATH (and now also for
 IOMMU entries for the deferred caching attribute updates).

Indeed. How about adding the software check (as Andrew mentioned) firstly and 
leave the hardware problem (Actually, I don't think we can solve it currently).

 
 Cheers,
 
 Tim.


Best regards,
Yang


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

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq

[Konrad Rzeszutek Wilk]

On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
 
 Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
 
  
  Uhmm i thought i had these switched off (due to problems earlier and then 
  forgot 
  about them .. however looking at the earlier reports these lines were also 
  in 
  those reports).
  
  The xen-syms and these last runs are all with a prestine xen tree cloned 
  today (staging 
  branch), so the qemu-xen and seabios defined with that were also freshly 
  cloned 
  and had a new default seabios config. (just to rule out anything stale in 
  my tree)
  
  If you don't see those messages .. perhaps your seabios and qemu trees 
  (and at least the 
  seabios config) are not the most recent (they don't get updated 
  automatically 
  when you just do a git pull on the main tree) ?
  
  In /tools/firmware/seabios-dir/.config i have:
  CONFIG_USB=y
  CONFIG_USB_UHCI=y
  CONFIG_USB_OHCI=y
  CONFIG_USB_EHCI=y
  CONFIG_USB_XHCI=y
  CONFIG_USB_MSC=y
  CONFIG_USB_UAS=y
  CONFIG_USB_HUB=y
  CONFIG_USB_KEYBOARD=y
  CONFIG_USB_MOUSE=y
  
 
  I seem to have the same thing. Perhaps it is my XHCI controller being wonky.
 
  And this is all just from a:
  - git clone git://xenbits.xen.org/xen.git -b staging
  - make clean  ./configure  make -j6  make -j6 install
 
  Aye. 
  .. snip..
1) test_and_[set|clear]_bit sometimes return unexpected values.
   [But this might be invalid as the addition of the 8303faaf25a8
might be correct - as the second dpci the softirq is processing
could be the MSI one]
  
  Would there be an easy way to stress test this function separately in some 
  debugging function to see if it indeed is returning unexpected values ?
 
  Sadly no. But you got me looking in the right direction when you mentioned
  'timeout'.
  
2) INIT_LIST_HEAD operations on the same CPU are not honored.
  
  Just curious, have you also tested the patches on AMD hardware ?
 
  Yes. To reproduce this the first thing I did was to get an AMD box.
 
  
   
   When i look at the combination of (2) and (3), It seems it could be an 
   interaction between the two passed through devices and/or different IRQ 
   types.
  
   Could be - as in it is causing this issue to show up faster than
   expected. Or it is the one that triggers more than one dpci happening
   at the same time.
  
  Well that didn't seem to be it (see separate amendment i mailed previously)
 
  Right, the current theory I've is that the interrupts are not being
  Acked within 8 milisecond and we reset the 'state' - and at the same
  time we get an interrupt and schedule it - while we are still processing
  the same interrupt. This would explain why the 'test_and_clear_bit'
  got the wrong value.
 
  In regards to the list poison - following this thread of logic - with
  the 'state = 0' set we open the floodgates for any CPU to put the same
  'struct hvm_pirq_dpci' on its list.
 
  We do reset the 'state' on _every_ GSI that is mapped to a guest - so
  we also reset the 'state' for the MSI one (XHCI). Anyhow in your case:
 
  CPUX:   CPUY:
  pt_irq_time_out:
  state = 0;  
  [out of timer coder, theraise_softirq
   pirq_dpci is on the dpci_list] [adds the pirq_dpci as state == 0]
 
  softirq_dpcisoftirq_dpci:
  list_del
  [entries poison]
  list_del = BOOM
  
  Is what I believe is happening.
 
  The INTX device - once I put a load on it - does not trigger
  any pt_irq_time_out, so that would explain why I cannot hit this.
 
  But I believe your card hits these hiccups.   
 
 
 Hi Konrad,
 
 I just tested you 5 patches and as a result i still got an(other) host crash:
 (complete serial log attached)
 
 (XEN) [2014-11-18 21:55:41.591] [ Xen-4.5.0-rc  x86_64  debug=y  Not 
 tainted ]
 (XEN) [2014-11-18 21:55:41.591] CPU:0
 (XEN) [2014-11-18 21:55:41.591] [ Xen-4.5.0-rc  x86_64  debug=y  Not 
 tainted ]
 (XEN) [2014-11-18 21:55:41.591] RIP:e008:[82d08012c7e7]CPU:2
 (XEN) [2014-11-18 21:55:41.591] RIP:e008:[82d08014a461] 
 hvm_do_IRQ_dpci+0xbd/0x13c
 (XEN) [2014-11-18 21:55:41.591] RFLAGS: 00010006
 _spin_unlock+0x1f/0x30CONTEXT: hypervisor

Duh!

Here is another patch on top of the five you have (attached and inline).

From 18008650f10199e2b83f74394f634a97086e34b8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 18 Nov 2014 20:48:43 -0500
Subject: [PATCH] debug: Whether we want to clear the 'dom' field or not when
 changing the 'state' bit.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 xen/drivers/passthrough/io.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index aad5607..24e2bd6 100644
--- 

[Xen-devel] [qemu-upstream-4.4-testing test] 31663: tolerable FAIL - PUSHED

[xen . org]

flight 31663 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31663/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot   fail blocked in 25336

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 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-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check 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-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-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-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 qemuub04df88d41f64fc6b56d193b6e90fb840cedb1d3
baseline version:
 qemuu65fc9b78ba3d868a26952db0d8e51cecf01d47b4


People who touched revisions under test:
  Roger Pau Monne roger@citrix.com
  Roger Pau Monné roger@citrix.com
  Stefano Stabellini stefano.stabell...@eu.citrix.com


jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 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   fail
 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 pass
 test-amd64-amd64-xl-sedf-pin pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-xl-sedf pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
 

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

[xen . org]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  0540b854f6733759593e829bc3f13c9b45974e32
baseline version:
 xen  e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2


People who touched revisions under test:
  Daniel De Graaf dgde...@tycho.nsa.gov
  Dietmar Hahn dietmar.h...@ts.fujitsu.com
  Emil Condrea emilcond...@gmail.com
  George Dunlap george.dun...@eu.citrix.com
  Ian Campbell ian.campb...@citrix.com
  Jan Beulich jbeul...@suse.com
  Juergen Gross jgr...@suse.com
  Konrad Rzeszutek Wilk konrad.w...@oracle.com
  M A Young m.a.yo...@durham.ac.uk
  Meng Xu men...@cis.upenn.edu
  Michael Young m.a.yo...@durham.ac.uk
  Olaf Hering o...@aepfle.de
  Wei Liu wei.l...@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-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  

[Xen-devel] [PATCH 2/2 V3] fix rename: xenstore not fully updated

[Chunyan Liu]

libxl__domain_rename only updates /local/domain/domid/name,
/vm/uuid/name in xenstore are not updated. Add code in
libxl__domain_rename to update /vm/uuid/name too.

Signed-off-by: Chunyan Liu cy...@suse.com
---
 tools/libxl/libxl.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dbefaf3..b403edc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -359,6 +359,9 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 uint32_t stub_dm_domid;
 const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
 int rc;
+libxl_dominfo info;
+char *uuid;
+const char *vm_name_path;
 
 dom_path = libxl__xs_get_dompath(gc, domid);
 if (!dom_path) goto x_nomem;
@@ -429,6 +432,16 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 goto x_fail;
 }
 
+/* update /vm/uuid/name */
+rc = libxl_domain_info(ctx, info, domid);
+if (rc)
+goto x_fail;
+
+uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+vm_name_path = GCSPRINTF(/vm/%s/name, uuid);
+if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name))
+goto x_fail;
+
 if (stub_dm_domid) {
 rc = libxl__domain_rename(gc, stub_dm_domid,
   stub_dm_old_name,
-- 
1.8.4.5


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

Re: [Xen-devel] [PATCH] xen: use more fixed strings to build the hypervisor

[Olaf Hering]

On Tue, Nov 18, Ian Jackson wrote:

 How about
 
It should be possible to repeatedly build identical sources
and get identical binaries, even on different hosts at different
build times.  This fails [etc. etc. ...]
 
Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUILD_HOST
which the build environment can set to fixed strings to get a
reproducible build.
 
 or some such.

Thanks. Do you want me to resend with this updated changelog, or will it
be used while applying?

Olaf

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

[Xen-devel] [linux-linus test] 31665: regressions - FAIL

[xen . org]

flight 31665 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31665/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  8 guest-start   fail REGR. vs. 31241
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-bootfail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 31241
 test-armhf-armhf-xl   9 guest-start  fail   like 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 31241
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 31241

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-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-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-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-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-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 linuxfc14f9c1272f62c3e8d01300f52467c0d9af50f9
baseline version:
 linux9f76628da20f96a179ca62b504886f99ecc29223


561 people touched revisions under test,
not listing them all


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  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  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   fail
 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