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,
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 failin
> 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
Hi Linus,
On Mon, 22 Dec 2014 20:09:50 -0800 Linus Torvalds
wrote:
>
> On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell
> 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 mer
On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell 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 of the function,
Hi Stefano,
In gic.c, gic_update_one_lr, gic_hw_ops is called to read and write to an LR.
why is read/write not done on the LRs stored in the vcpu context ?
Could you please elaborate why it is done this way.
-Regards
manish
___
Xen-devel mailing lis
>>> On 12/19/2014 at 06:25 PM, in message
>>> <1418984720.20028.15.ca...@citrix.com>,
Ian Campbell 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 wrote:
> > >
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
test-amd64-amd64-xl-qe
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 s
Hi Linus,
I have been carrying this merge fix patch for some time that is now
needed in your tree:
From: Stephen Rothwell
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 conflict in
arch/arm/i
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64
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 x86,
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 ++--
arch/x86/vdso/vclock_gettime.c
From: Herbert Xu
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 remain empty. However, like
From: Herbert Xu
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 napi poll_list must re
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
El 18/12/14 a les 11.41, Jan Beulich ha escrit:
On 17.12.14 at 13:51, 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 +1729,8 @
There is no reason for having it and, with commit 250a1ac685f1 ("x86,
smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()"), it prevents HVM guests from booting.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/time.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/
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 guest-start
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
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
___
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 intended.
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 succeed,
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 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 0383102b09fd3724f14c200cd8ea
flight 32568 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32568/
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 failin
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
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?
Signed-of
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 EL
>>> On 12/19/2014 at 06:38 PM, in message
>>> <1418985490.20028.27.ca...@citrix.com>,
Ian Campbell 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 wrote:
> > >
>>> On 12/19/2014 at 06:38 PM, in message
>>> <1418985490.20028.27.ca...@citrix.com>,
Ian Campbell 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 wrote:
> > >
On Mon, Dec 22, 2014 at 04:18:33PM +0800, Jason Wang wrote:
>
> btw, looks like at least caif_virtio has the same issue.
Good catch.
-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks caif.
It is now required that if the entire budget is con
>>> On 12/19/2014 at 06:27 PM, in message
>>> <1418984856.20028.17.ca...@citrix.com>,
Ian Campbell 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 snapshot name).
On 12/20/2014 08:23 AM, Herbert Xu wrote:
> David Vrabel 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
>> budget was used.
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 a
On Fri, Dec 19, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> > This is a resend of these two series:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg006
36 matches
Mail list logo
