With Xen configured into the arm64 kernel, any driver allocating
DMA'able memory for PCI operations, must be GPL compatible, regardless
of its interaction with Xen. This patch relaxes the GPL requirement of
xen_dma_ops and its dependencies to allow open source drivers to be
compiled for the arm64
On 12/20/2014 08:23 AM, Herbert Xu wrote:
David Vrabel david.vra...@citrix.com wrote:
After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n-poll(), and is only requeued if all of the
On 12/19/2014 at 06:27 PM, in message
1418984856.20028.17.ca...@citrix.com,
Ian Campbell ian.campb...@citrix.com wrote:
On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote:
'--name' meant to give a meaningful name (like: newinstall. Used as the
memory snapshot name and disk
On 12/19/2014 at 06:38 PM, in message
1418985490.20028.27.ca...@citrix.com,
Ian Campbell ian.campb...@citrix.com wrote:
On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote:
On 12/18/2014 at 11:27 PM, in message
1418916436.11882.101.ca...@citrix.com,
Ian Campbell
On 12/19/2014 at 06:38 PM, in message
1418985490.20028.27.ca...@citrix.com,
Ian Campbell ian.campb...@citrix.com wrote:
On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote:
On 12/18/2014 at 11:27 PM, in message
1418916436.11882.101.ca...@citrix.com,
Ian Campbell
On 20/12/2014 20:48, Vijay Kilari wrote:
Hi,
Hi Vijay,
I want to know what is the criteria followed in Xen for scheduling VCPUs.
Assume below scenario:
- Run 2 VPCUs on 1 Physical CPU
- VCPUs does not trap on WFE or WFE ( either by WFI/WFE trap is
disabled in HCR OR no WFE/WFI in
Hi Ian,
On 21/12/2014 12:18, Ian Campbell wrote:
By iterating up to = mi-nr_mods we are running off the end of the boot
modules, but more importantly it causes us to then skip the first FDT reserved
region, meaning we might clobber it.
Oops. Good catch!
OOI, how did you find it?
On Mon, 2014-12-22 at 11:54 +0100, Julien Grall wrote:
Hi Ian,
On 21/12/2014 12:18, Ian Campbell wrote:
By iterating up to = mi-nr_mods we are running off the end of the boot
modules, but more importantly it causes us to then skip the first FDT
reserved
region, meaning we might
flight 32577 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32577/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 5f4031a1d23e08f1f470e0af788c0296223ae6b5
baseline version:
rumpuserxen
Hi
There is a problem with booting dom0 as pvh (xen-4.5rc3, kernel 3.18.0+).
After digging a bit into this it seems that the booting gets stuck upon
enabling second IOMMU by writing to DMAR_GCMD_REG (See the attaches debug log).
The boot process passes this stage if second iommu was not enabled.
flight 32571 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32571/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32542
Tests which did not
High all,
I am in the process of cleaning up the 4.5 documentation. One of the pages that
needs verification is
* http://wiki.xenproject.org/wiki/XL_vs_Xend_Feature_Comparison
As we are removing XM, I would assume that the only discrepancies between XM
and XL should be those that were
With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()) HVM guests no longer boot since we are
hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().
I don't think we need this test (PV or HVM), do we?
-boris
On 22/12/14 15:53, Boris Ostrovsky wrote:
With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()) HVM guests no longer boot since we are
hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().
I don't think we need this test (PV or HVM), do we?
flight 32576 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32576/
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
El 18/12/14 a les 11.41, Jan Beulich ha escrit:
On 17.12.14 at 13:51, roger@citrix.com wrote:
I've also added the following patch to Xen, and it reliably triggers on
FreeBSD, while it seems to work fine on Linux:
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1729,6
flight 32574 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32574/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-sedf 7 debian-install fail pass in 32554
Regressions which are regarded as
From: Herbert Xu herb...@gondor.apana.org.au
Date: Sat, 20 Dec 2014 11:23:27 +1100
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks virtio_net in an insidious way.
It is now required that if the entire budget is consumed when poll
returns, the
From: Herbert Xu herb...@gondor.apana.org.au
Date: Mon, 22 Dec 2014 20:35:25 +1100
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks caif.
It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must
This is a dramatic simplification and speedup of the vdso pvclock read
code. Is it correct?
Andy Lutomirski (2):
x86, vdso: Use asm volatile in __getcpu
x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
arch/x86/include/asm/vgtod.h | 6 ++--
In Linux 3.18 and below, GCC hoists the lsl instructions in the
pvclock code all the way to the beginning of __vdso_clock_gettime,
slowing the non-paravirt case significantly. For unknown reasons,
presumably related to the removal of a branch, the performance issue
is gone as of
e76b027e6408
Hi Linus,
I have been carrying this merge fix patch for some time that is now
needed in your tree:
From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 8 Dec 2014 18:46:59 +1100
Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix
The merge of the (linux-next) xen-tip tree got a
Hello,
在 12/19/2014 06:15 PM, Anthony Korzan 写道:
Thank you for your response,
I compiled Linux 3.0.101, sch_plug, and reinstalled remus-drbd. I still receive
the same error when starting remus:
xc: error: rdexact failed (select returned 0): Internal error
xc: error: Error when reading batch
flight 32581 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32581/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 32564
On 12/19/2014 at 06:25 PM, in message
1418984720.20028.15.ca...@citrix.com,
Ian Campbell ian.campb...@citrix.com wrote:
On Thu, 2014-12-18 at 22:45 -0700, Chun Yan Liu wrote:
On 12/18/2014 at 11:10 PM, in message
1418915443.11882.86.ca...@citrix.com,
Ian Campbell
On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Linus,
I have been carrying this merge fix patch for some time that is now
needed in your tree:
No, it's not. Look more closely.
My merge put the
dev-archdata.dma_coherent = coherent;
line at the top
Hi Linus,
On Mon, 22 Dec 2014 20:09:50 -0800 Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Linus,
I have been carrying this merge fix patch for some time that is now
needed in your tree:
No,
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, December 19, 2014 7:26 PM
This can (and will) be legitimately the case when sharing page tables
with EPT (more of a problem before p2m_access_rwx became zero, but
still possible even now when other than that is the default for a
flight 32584 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32584/
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
Tests which are
On 23/12/2014 01:39, Andy Lutomirski wrote:
This is a dramatic simplification and speedup of the vdso pvclock read
code. Is it correct?
Andy Lutomirski (2):
x86, vdso: Use asm volatile in __getcpu
x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
Patch 1 is ok,
30 matches
Mail list logo
