>>> On 12/18/2014 at 11:15 PM, in message
>>> <1418915759.11882.91.ca...@citrix.com>,
Ian Campbell wrote:
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * xl won't manage snapshots, that means it won't maintain json files,
> > won't maintain snapshot ch
>>> On 12/18/2014 at 11:27 PM, in message
>>> <1418916436.11882.101.ca...@citrix.com>,
Ian Campbell wrote:
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * remove libxl_domain_snapshot_create/delete/revert API
> > * export disk snapshot functionality for
flight 32448 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32448/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32149
Tests which did not succeed, bu
flight 32471 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32471/
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 Thu, Dec 18, 2014 at 05:40:28PM +0100, Tim Deegan wrote:
> Hi,
>
> Thanks for posting this - it's very useful. I have a couple of
> questions about the interface design.
Thanks Tim.
>
> At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> > Design Overview
> > When enforcing cache allo
>>> On 12/18/2014 at 11:10 PM, in message
>>> <1418915443.11882.86.ca...@citrix.com>,
Ian Campbell wrote:
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * add an overview document, so that one can has a overall look
> > about the whole domain snapshot w
flight 32445 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 26303
test-amd64-amd64-pair
>>> On 12/18/2014 at 11:05 PM, in message
>>> <1418915119.11882.79.ca...@citrix.com>,
Ian Campbell wrote:
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * add a document for domain snapshot related terms, they will be
> > referred in later documents.
>
Hi,
在 12/19/2014 05:48 AM, Anthony Korzan 写道:
Hello!
I have only managed to get Xen 4.5's Remus "working" on Linux Kernels less than
3.5. The provided remus-drbd, as detailed in docs/README.remus and available
from https://github.com/rshriram/remus-drbd will not compile with Linux Kernels
3.6 a
flight 32441 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-oldkern 5 kernel-build fail REGR. vs. 32392
Tests which are fail
RMRR Fix Design for Xen
This design is a goal to fix RMRR for Xen. It includes four sectors as
follows:
* Background
* What is RMRR
* Current RMRR Issues
* Design Overview
We hope this can help us to understand current problem then figure out a
clean and bette
On 2014/12/19 0:13, Tim Deegan wrote:
Hi Kevin,
At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
From: Tim Deegan [mailto:t...@xen.org]
Now since the code's not going to be in 4.5 anyway, it should be
possible to _develop_ it in
I agree with Julien below, this should probably be put into the p2m layer.
The ARM definition of the function could then simply be an inline
definition that just returns 0.
Tamas
On Tue, Dec 2, 2014 at 9:54 AM, Julien Grall
wrote:
>
> Hi,
>
> CC Tamas as he did some work on memaccess for ARM.
>
Is parallel make supported for xen? If I compile 4.5 rc4 (although the
error exists with many other prior releases too) with make -j4 world it
fails part way through with an error 2. This does not occur with a straight
'make world'
PK
___
Xen-devel maili
Hello!
I have only managed to get Xen 4.5's Remus "working" on Linux Kernels less than
3.5. The provided remus-drbd, as detailed in docs/README.remus and available
from https://github.com/rshriram/remus-drbd will not compile with Linux Kernels
3.6 and above.
One of these errors is that remus-d
> index 000..b5a3e98
> --- /dev/null
> +++ b/drivers/xen/preempt.c
> @@ -0,0 +1,17 @@
> +/*
> + * Preemptible hypercalls
> + *
> + * Copyright (C) 2014 Citrix Systems R&D ltd.
> + *
> + * This source code is free software; you can redistribute it and/or
> + * modify it under the terms of the GN
On 18/12/14 18:27, Roger Pau Monne wrote:
> Check that MMIO regions added to PVH Dom0 are allowed. Previously a PVH Dom0
> would have access to the full MMIO range.
>
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/domain_build.c | 31
On 18/12/14 18:27, Roger Pau Monne wrote:
> Prevent Dom0 from accessing HPET MMIO region by adding it to the list of
> denied memory regions.
>
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
Apologies that this reply is split between patch 0 and 2 - I replied to
your cov
On 18/12/14 18:27, Roger Pau Monne wrote:
> Hello,
>
> This series contains a bug-fix for PVH Dom0, that prevents Xen from adding
> MMIO regions that should not be accesible to Dom0. The second patch also
> prevents Dom0 from accessing the HPET, which AFAICT is used by Xen.
>
> I'm not sure if th
Prevent Dom0 from accessing HPET MMIO region by adding it to the list of
denied memory regions.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain_build.c | 12
1 file changed, 12 insertions(+)
diff --git a/xen/arch/x86/domain_build.c b/xen/a
Check that MMIO regions added to PVH Dom0 are allowed. Previously a PVH Dom0
would have access to the full MMIO range.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain_build.c | 31 +++
1 file changed, 31 insertions(+)
diff -
Hello,
This series contains a bug-fix for PVH Dom0, that prevents Xen from adding
MMIO regions that should not be accesible to Dom0. The second patch also
prevents Dom0 from accessing the HPET, which AFAICT is used by Xen.
I'm not sure if there's a reason why the HPET MMIO region wasn't added t
Hi,
XenServers Coverity scanning has identified a spinlock inversion, where
enable_iommu() takes the iommu lock and irq_desc lock in an opposite
order to the rest of the interrupt handling. (I suspect Coverity Scan
is not identifying this as it is not configured to perform function
pointer analys
On 13/10/14 14:41, David Vrabel wrote:
>
> Design
> ==
Jennifer has put together most of the initial implementation of this so
expect a full series some time next year.
It didn't quite end up as described here.
> Userspace address to page translation
> -
On 18/12/14 17:50, David Miller wrote:
> From: David Vrabel
> Date: Thu, 18 Dec 2014 11:13:06 +
>
>> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
>> feature-rx-notify mandatory) incorrectly assumed that there were no
>> frontends in use that did not support this feature.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 16, 2014 1:38 AM
> To: Chao Peng
> Cc: andrew.coop...@citrix.com; ian.campb...@citrix.com;
> wei.l...@citrix.com; george.dun...@eu.citrix.com;
> ian.jack...@eu.citrix.com; stefano.stabell...@eu.c
From: David Vrabel
Date: Thu, 18 Dec 2014 11:13:06 +
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature. But the frontend
> driver in MiniOS does not a
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do this via IPI since otherwise there is a (somewheat
theoretical) chance that between test and subsequent clearing
of last
On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:
> On 12/18/2014 04:04 PM, Wei Liu wrote:
> > On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
> >> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> >>> Signed-off-by: Dario Faggioli
> >>> ---
> >>> make-flight | 11 ++
On 18/12/14 16:08, Tim Deegan wrote:
>> yep. Just curious, I thought stubdomain is not popularly used. typical
>> > case is to have qemu in dom0. is this still true? :-)
> Some do and some don't. :) High-security distros like Qubes and
> XenClient do. You can enable it in xl config files pretty e
>>> On 18.12.14 at 17:08, wrote:
> On 12/18/2014 09:10 AM, Jan Beulich wrote:
> On 17.12.14 at 16:38, wrote:
>>> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
>>> forever.
>> Reported-by: Jan Beulich
>> (or Suggested-by if you like that better)
>>
>>> Signed-of
Hi,
Thanks for posting this - it's very useful. I have a couple of
questions about the interface design.
At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> Design Overview
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("V
Hi Kevin,
At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
> At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:t...@xen.org]
> > > Now since the code's not going to be in 4.5 anyway, it should be
> > > possible to _develop_ it in this manner, possibly
Hi,
At 06:29 + on 12 Dec (1418362182), Tian, Kevin wrote:
> If we can't containerize Dom0's behavior completely, I would think dom0
> and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> make things worse.
Ah, but it does -- it's putting thousands of lines of code int
On 18/12/2014 16:02, Jan Beulich wrote:
On 18.12.14 at 16:56, wrote:
On 17/12/2014 17:17, Jan Beulich wrote:
Aliasing device and pci_dev for x86 would yield similar clarity afaict.
To be sure, by aliasing you mean creating a typedef?
For x86:
typedef struct pci_dev device_t;
And for ARM:
t
On 12/18/2014 09:10 AM, Jan Beulich wrote:
On 17.12.14 at 16:38, wrote:
The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
forever.
Reported-by: Jan Beulich
(or Suggested-by if you like that better)
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/vpmu.c | 15
>>> On 18.12.14 at 16:56, wrote:
> On 17/12/2014 17:17, Jan Beulich wrote:
>> Aliasing device and pci_dev for x86 would yield similar clarity afaict.
>
> To be sure, by aliasing you mean creating a typedef?
>
> For x86:
> typedef struct pci_dev device_t;
>
> And for ARM:
> typedef struct device
Hi Andrew Cooper,
On 17/12/2014 17:52, Andrew Cooper wrote:
On 17/12/14 17:10, Jan Beulich wrote:
Julien Grall 12/17/14 1:55 PM >>>
On 17/12/14 10:05, Jan Beulich wrote:
On 16.12.14 at 21:08, wrote:
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
Any reason not to simply use {read,w
Hi Andrew,
On 17/12/2014 17:52, Andrew Cooper wrote:
On 17/12/14 17:10, Jan Beulich wrote:
Julien Grall 12/17/14 1:55 PM >>>
On 17/12/14 10:05, Jan Beulich wrote:
On 16.12.14 at 21:08, wrote:
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
Any reason not to simply use {read,write}_a
Hi Jan,
On 17/12/2014 17:17, Jan Beulich wrote:
Julien Grall 12/17/14 2:04 PM >>>
On 17/12/14 10:46, Jan Beulich wrote:
On 17.12.14 at 11:30, wrote:
Having a generic way to describe device will really help ARM code (see
IOMMU).
If we don't have a such thing, we may need to duplicate quite
Hi,
At 07:24 + on 12 Dec (1418365491), Tian, Kevin wrote:
> > I'm afraid not. There's nothing worrying per se in a backend knowing
> > the MFNs of the pages -- the worry is that the backend can pass the
> > MFNs to hardware. If the check happens only at lookup time, then XenGT
> > can (eith
On 12/18/2014 07:15 AM, Dietmar Hahn wrote:
Am Mittwoch 17 Dezember 2014, 10:38:31 schrieb Boris Ostrovsky:
Version 16 of PV(H) PMU patches.
Hi Boris,
I did a fast and simple test on a small Intel machine and all went fine. I'll
do some more after my vacation in 2015.
Thanks!
After adaptin
On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
> * remove libxl_domain_snapshot_create/delete/revert API
> * export disk snapshot functionality for both xl and libvirt usage
>
> ===
> Libxl/libxlu D
flight 32438 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32438/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 5 xen-boot fail blocked in 32412
test-amd64-i386-xl5
On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
> * xl won't manage snapshots, that means it won't maintain json files,
> won't maintain snapshot chain relationship, and then as a result
> won't take care of deleting snapshot and listing snapshots.
> * remove snap
On 12/18/2014 04:04 PM, Wei Liu wrote:
On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
On 12/18/2014 02:39 PM, Dario Faggioli wrote:
Signed-off-by: Dario Faggioli
---
make-flight | 11 +++
sg-run-job |6 ++
2 files changed, 17 insertions(+)
diff --git a/m
On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
> * add an overview document, so that one can has a overall look
> about the whole domain snapshot work, limits, requirements,
> how to do, etc.
>
>
On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
> * add a document for domain snapshot related terms, they will be
> referred in later documents.
>
> =
> Terms
>
> * Active domain: domain created and
On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> >Signed-off-by: Dario Faggioli
> >---
> > make-flight | 11 +++
> > sg-run-job |6 ++
> > 2 files changed, 17 insertions(+)
> >
> >diff --git a/make-flight b/make-fl
On 12/18/2014 02:39 PM, Dario Faggioli wrote:
Signed-off-by: Dario Faggioli
---
make-flight | 11 +++
sg-run-job |6 ++
2 files changed, 17 insertions(+)
diff --git a/make-flight b/make-flight
index a91f256..ce02c89 100755
--- a/make-flight
+++ b/make-flight
@@ -266,6 +26
>>> On 17.12.14 at 16:38, wrote:
> Add support for handling PMU interrupts for PV guests.
>
> VPMU for the interrupted VCPU is unloaded until the guest issues
> XENPMU_flush
> hypercall. This allows the guest to access PMU MSR values that are stored in
> VPMU context which is shared between hype
On 12/18/2014 02:38 PM, Dario Faggioli wrote:
for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
credit, credit2 and RTDS.
It also tries to migrating a domain to the new cpupool
a
On 12/18/2014 02:38 PM, Dario Faggioli wrote:
Just the fact that we are not doing anything to smoke test cpupools, while I
think we should. :-)
This add something quite basic, but it's, IMO, already representative one
typically does with cpupools. We can add more pCPU related tricks (removing,
a
>>> On 17.12.14 at 16:38, wrote:
> +int __init amd_vpmu_init(void)
> +{
> +if ( current_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +return -EINVAL;
Your only caller guarantees this not to be the case.
> +int __init core2_vpmu_init(void)
> +{
> +u64 caps;
> +
> +if ( current_cp
>>> On 17.12.14 at 16:38, wrote:
> Acked-by: Kevin Tian
> Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Dietmar Hahn
> Tested-by: Dietmar Hahn
I don't see these being valid anymore, and I think this isn't the first
time I'm pointing out that you should drop such tags when making
more than
>>> On 17.12.14 at 16:38, wrote:
> @@ -146,36 +145,34 @@ static void vpmu_save_force(void *arg)
> vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
>
> if ( vpmu->arch_vpmu_ops )
> -(void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
> +(void)vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
Poin
>>> On 17.12.14 at 16:38, wrote:
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -26,7 +26,9 @@ headers-y := \
> headers-$(CONFIG_X86) += compat/arch-x86/xen-mca.h
> headers-$(CONFIG_X86) += compat/arch-x86/xen.h
> headers-$(CONFIG_X86) += compat/arch-x86/xen-$(compat
>>> On 17.12.14 at 16:38, wrote:
> Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector
> should
> be updated. Instead, handle guest's APIC_LVTPC accesses and write what the
> guest
> explicitly wanted.
>
> Signed-off-by: Boris Ostrovsky
> Acked-by: Kevin Tian
> Reviewed-by
>>> On 17.12.14 at 16:38, wrote:
> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
> forever.
Reported-by: Jan Beulich
(or Suggested-by if you like that better)
> Signed-off-by: Boris Ostrovsky
> ---
> xen/arch/x86/hvm/vpmu.c | 15 ---
> 1 file changed
>>> On 11.12.14 at 14:45, wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> break;
> }
>
> +ret = xsm_devour(XSM_HOOK, d, recipient_dom);
> +
>>> On 11.12.14 at 14:45, wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> }
> break;
>
> +case XEN_DOMCTL_devour:
> +{
> +struct domain *recipient_dom;
> +
> +
On Thu, 2014-12-18 at 14:38 +0100, Dario Faggioli wrote:
> Just the fact that we are not doing anything to smoke test cpupools, while I
> think we should. :-)
>
> This add something quite basic, but it's, IMO, already representative one
> typically does with cpupools. We can add more pCPU related
Signed-off-by: Dario Faggioli
---
make-flight | 11 +++
sg-run-job |6 ++
2 files changed, 17 insertions(+)
diff --git a/make-flight b/make-flight
index a91f256..ce02c89 100755
--- a/make-flight
+++ b/make-flight
@@ -266,6 +266,16 @@ do_credit2_tests () {
$debian_
for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
credit, credit2 and RTDS.
It also tries to migrating a domain to the new cpupool
and then back to Pool-0.
Signed-off-by: Dario Fag
Just the fact that we are not doing anything to smoke test cpupools, while I
think we should. :-)
This add something quite basic, but it's, IMO, already representative one
typically does with cpupools. We can add more pCPU related tricks (removing,
adding, etc), or we can add more domains and move
>>> On 11.12.14 at 14:45, wrote:
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
> break; /* not reached */
> }
>
> +case SHUTDOWN_soft_reset:
> +{
> +printk("Domain 0 did soft reset but it is unsupport
>>> On 11.12.14 at 14:45, wrote:
> New dying state is requred to indicate that a particular domain
> is dying but cleanup procedure wasn't started. This state can be
> set from outside of domain_kill().
Without any user of the new state (yet), please be more verbose
here to explain what the inten
>>> On 11.11.14 at 14:17, wrote:
> This driver uses hwdom to change frequencies on physical
> CPUs.
> Workflow:
> * cpufreq governor driver in Xen wants to change the
>frequency of the physical CPU
> * hwdom-cpufreq driver sets parameters in the shared
>memory
> * hwdom-cpufreq driver s
>>> On 11.11.14 at 14:17, wrote:
> Kernel uses this op to start/stop cpufreq notification
> events sending.
This is too little of an explanation for a public interface addition.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.
>>> On 11.11.14 at 14:17, wrote:
> @@ -207,6 +207,18 @@ int cpufreq_add_cpu(unsigned int cpu)
> );
> return -EINVAL;
> }
> +#else /* CONFIG_ACPI */
> +if ((perf->domain_info.num_processors !=
> +processor_pminfo[firstcpu]->perf.domain_info
>>> On 11.11.14 at 14:17, wrote:
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> Signed-off-by: Oleksandr Dmytryshyn
Acked-by: Jan Beulich
___
Xen-devel mailing l
>>> On 11.11.14 at 14:17, wrote:
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> Signed-off-by: Oleksandr Dmytryshyn
Acked-by: Jan Beulich
___
Xen-devel mailing l
>>> On 11.11.14 at 14:17, wrote:
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> Signed-off-by: Oleksandr Dmytryshyn
Acked-by: Jan Beulich
___
Xen-devel mailing l
>>> On 11.11.14 at 14:17, wrote:
> ACPI-specific parts are moved under appropriate ifdefs.
> Now pmstat functions can be used in ARM platform.
>
> Signed-off-by: Oleksandr Dmytryshyn
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.
>>> On 11.11.14 at 14:17, wrote:
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -4,6 +4,7 @@
> HAS_IOPORTS := y
> HAS_ACPI := y
> HAS_PM := y
> +HAS_CPU_TURBO := y
If you want to abbreviate it, please make it HAS_TURBO. If you
want to spell it out, please use HAS_CPUFREQ_TURB
>>> On 03.12.14 at 15:29, wrote:
> @@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
> return num_act_frames_from_sha_frames(nr_grant_frames(gt));
> }
>
> +static inline struct active_grant_entry *
> +active_entry_acquire(struct grant_table *t, grant_ref_t e)
> +{
> +
On 18/12/2014 12:12, Ian Campbell wrote:
On Thu, 2014-12-18 at 12:05 +, Julien Grall wrote:
Hi Ian,
On 18/12/2014 09:47, Ian Campbell wrote:
On Wed, 2014-12-17 at 15:40 +, Julien Grall wrote:
The domain vgic lock is used uninitialized.
Signed-off-by: Julien Grall
Acked-by: Ian C
flight 32431 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32431/
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-rump
Am Mittwoch 17 Dezember 2014, 10:38:31 schrieb Boris Ostrovsky:
> Version 16 of PV(H) PMU patches.
Hi Boris,
I did a fast and simple test on a small Intel machine and all went fine. I'll
do some more after my vacation in 2015.
After adapting your sent linux kernel patches I'am interestet in traci
On Thu, 2014-12-18 at 12:05 +, Julien Grall wrote:
> Hi Ian,
>
> On 18/12/2014 09:47, Ian Campbell wrote:
> > On Wed, 2014-12-17 at 15:40 +, Julien Grall wrote:
> >> The domain vgic lock is used uninitialized.
> >>
> >> Signed-off-by: Julien Grall
> >
> > Acked-by: Ian Campbell
> >
> >>
Hi Ian,
On 18/12/2014 09:47, Ian Campbell wrote:
On Wed, 2014-12-17 at 15:40 +, Julien Grall wrote:
The domain vgic lock is used uninitialized.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
unitialize
On Thu, Dec 18, 2014 at 11:13:06AM +, David Vrabel wrote:
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature. But the frontend
> driver in MiniOS does no
>>> On 03.12.14 at 15:29, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct
> grant_table *rgt)
> {
> if ( lgt < rgt )
> {
> -spin_lock(&lgt->lock);
> -spin_lock(&rgt->lock);
>
Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature. But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.
N
On Wed, Dec 17, 2014 at 08:23:41PM -0700, Chun Yan Liu wrote:
[...]
> > >
> > >
> > > 2. cfgfile syntax
> > >
> > > #snapshot name. If user doesn't provide a VM snapshot name, xl will
> > generate
> > > #a name automatically by the creation time.
> > > name=""
> > >
> > > #snapshot de
On Wed, Dec 17, 2014 at 08:34:07PM -0700, Chun Yan Liu wrote:
>
>
> >>> On 12/17/2014 at 08:17 PM, in message
> <20141217121750.gf1...@zion.uk.xensource.com>, Wei Liu
> wrote:
> > On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote:
> > > Changes to V8:
> > > * add an overview docum
On Thu, 2014-12-18 at 10:49 +, Jan Beulich wrote:
> >>> On 18.12.14 at 11:17, wrote:
> > On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
> >> Do we have a bug in Xen that affect SSE instructions (possibly already
> >> fixed after Philipp version) ?
> >
> > I've had a niggling feelin
>>> On 18.12.14 at 11:17, wrote:
> On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
>
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> 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 @@ static void end_level_ioapic_irq_new(struct irq_desc
On 18/12/14 10:17, Ian Campbell wrote:
> On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
>
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an ol
On Wed, 2014-12-17 at 15:54 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 15, 2014 at 10:02:31AM +, Ian Campbell wrote:
> > On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
> >
> > Ping again. This issue has resurfaced in the Debian packaging of the 4.5
> > rcs. I think we should fix
Hello,
On 17.12.2014 10:14, Frediano Ziglio wrote:
> 2014-12-16 16:44 GMT+00:00 Frediano Ziglio :
>> 2014-12-16 16:23 GMT+00:00 Ian Campbell :
...
>> First we (I'll try when I reach home) can check if memset in glibc (or
>> the version called from talloc_zero) can use SSE. A possible dmesg
>> outp
On Tue, 2014-12-16 at 22:55 +, Wei Liu wrote:
> On Tue, Dec 16, 2014 at 10:04:25PM +, M A Young wrote:
> > On Tue, 16 Dec 2014, Wei Liu wrote:
> >
> > >On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote:
> > >[...]
> > >>Is this patch going to get committed in time for xen 4.5?
> >
On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
> Do we have a bug in Xen that affect SSE instructions (possibly already
> fixed after Philipp version) ?
I've had a niggling feeling of Deja Vu over this which I'd been putting
down to an old Xen on ARM bug in the area of FPU register swit
AFAIK, TC doesn't support limiting packets per second.
2014-12-18 18:00 GMT+08:00 Sander Eikelenboom :
>
> Thursday, December 18, 2014, 9:13:18 AM, you wrote:
>
>>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
On Jul09 15:48, Sander Eikelenboom wrote:
> Just wondering, why sho
>>> On 17.12.14 at 16:43, wrote:
> flight 32424 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32424/
>
> 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/
Thursday, December 18, 2014, 9:13:18 AM, you wrote:
>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>>> On Jul09 15:48, Sander Eikelenboom wrote:
>>> > Just wondering, why should this be done in the drivers ?
>>> > Couldn't this also be achieved with netfilter and the recent/limit
>>>
On Thu, 2014-12-18 at 10:54 +0800, Kai Huang wrote:
> Hi,
>
> I built and installed Xen from latest upstream Xen source code, but XL
> always failed to work. Do you know what's going on here? My
> environment is Lubuntu 14.04. Thanks in advance.
>
> I always got "Permission denied" error.
>
> ro
On Wed, 2014-12-17 at 15:40 +, Julien Grall wrote:
> The domain vgic lock is used uninitialized.
>
> Signed-off-by: Julien Grall
Acked-by: Ian Campbell
> ---
> This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
> unitialized. Luckily we only use the field "raw" which
1 - 100 of 108 matches
Mail list logo
