>>> On 15.09.15 at 03:17, wrote:
>> > But looks its not better, so any idea?
>>
>> Did you at least make an attempt to find other examples of where
>> we dynamically determine the log level to be used for a message?
>> I would assume that if you did, you'd have come to
>>
>> printk(XE
flight 61882 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581
Regressions which are
flight 61844 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 9 debian-installfail REGR. vs. 61513
test-amd64-i386-x
flight 61893 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 60684
build-amd6
But looks its not better, so any idea?
Did you at least make an attempt to find other examples of where
we dynamically determine the log level to be used for a message?
I would assume that if you did, you'd have come to
printk(XENLOG_GUEST "%s" VTDPREFIX
I didn't know this tip on
On 14/09/2015 16:58, Will Deacon wrote:
The Xen ctxt switch code[0] has DACR_EL2 in the midst of it all, and
certainly followed by some sysregs, which I've got my fingers crossed
happens to be sufficient (other than maybe adding a comment).
It looks like you restore CONTEXTIDR_EL1 fairly late,
flight 61839 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61839/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 61745
flight 61827 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-vhd 13 guest-saverestore fail REGR. vs. 60666
test-amd64-i386-xl-qco
On Mon, Sep 14, George Dunlap wrote:
> Well if you "know nothing about SELinux", and you don't use it, and
> don't have any test systems that use it, then why did you assert
> "The proper place to specify [an SELinux mount context] is /etc/fstab"?
> This patchset was accepted because you represen
On Mon, Sep 14, 2015 at 06:54:51PM +0200, Vitaly Kuznetsov wrote:
> Wei Liu writes:
>
> > Sorry for the delay.
> >
> > FYI all other patches of this series were applied by Jan. You only need
> > to resend this one.
>
> Cool, I will.
>
> >
> > See below for a few comments.
> >
> > On Fri, Sep 04
On Mon, Sep 14, 2015 at 04:46:28PM +0100, Marc Zyngier wrote:
> On 14/09/15 16:06, Will Deacon wrote:
> > When restoring the system register state for an AArch32 guest at EL2,
> > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > which can lead to the guest effectively runni
Wei Liu writes:
> Sorry for the delay.
>
> FYI all other patches of this series were applied by Jan. You only need
> to resend this one.
Cool, I will.
>
> See below for a few comments.
>
> On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote:
>> Use existing create/restore path to p
On 09/11/2015 07:31 AM, Olaf Hering wrote:
> On Thu, Sep 10, George Dunlap wrote:
>
>> On Fri, Dec 19, 2014 at 11:25 AM, Olaf Hering wrote:
>>> Using SELinux mount options per default breaks several systems.
>>> Either the context= mount option is not known at all to the kernel,
>>> as reported f
On Mon, Sep 14, 2015 at 5:20 PM, Ian Campbell
wrote:
> On Mon, 2015-09-14 at 14:40 +0200, Christoffer Dall wrote:
> > On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > > On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel <
> david.vra...@citrix.com
> > > >
> > > wrote:
> > >
> > >
Sorry for the delay.
FYI all other patches of this series were applied by Jan. You only need
to resend this one.
See below for a few comments.
On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote:
> Use existing create/restore path to perform 'soft reset' for HVM
> domains. Tear ever
Hi Ian,
On Mon, Sep 14, 2015 at 04:36:28PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-14 at 16:06 +0100, Will Deacon wrote:
> > When restoring the system register state for an AArch32 guest at EL2,
> > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > which can lead to th
On 14/09/15 16:06, Will Deacon wrote:
> When restoring the system register state for an AArch32 guest at EL2,
> writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> which can lead to the guest effectively running with junk in the DACR
> and running into unexpected domain faults.
It seems that there is some hardware which report start to report GICv4
in the GIC*_PIDR2 register.
As GICv4 is a superset of GICv3, it should just work on Xen.
Reported-by: Andre Przywara
Signed-off-by: Julien Grall
---
xen/arch/arm/gic-v3.c | 4 ++--
xen/include/asm-arm/gic_v3_de
flight 61821 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 61627
Regressions which ar
On Mon, 2015-09-14 at 16:06 +0100, Will Deacon wrote:
> When restoring the system register state for an AArch32 guest at EL2,
> writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> which can lead to the guest effectively running with junk in the DACR
> and running into unexpected
Hi all,
This small patch series allow Xen to run on platform reporting GICv4
in the GIC*_PIDR2.
Sincerely yours,
Julien Grall (2):
xen/arm: gic-v3: Clean-up the GIC*_PIDR2_* definitions
xen/arm: gic-v3: Allow Xen to run on hardware reporting GICv4
xen/arch/arm/gic-v3.c | 8 +++
GICR_PIDR2 and GICD_PIDR2 use the same register layout. Rather than
define twice, one of which is an alias to the other, introduce GIC_PIDR2_*
defines.
Also:
* Use the same prefix for the mask and the value
* Integrate the shift in the value to avoid shifting in the code
* Use GICv* to
Signed-off-by: Julien Grall
---
xen/include/asm-arm/domain.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 56aa208..7ddaeaa 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -17,7 +17,6 @@ struct
El 14/09/15 a les 16.54, Stefano Stabellini ha escrit:
> On Mon, 14 Sep 2015, Roger Pau Monné wrote:
>> IMHO this splitting is just a workaround for the fact that we don't have
>> a 64KB PV block protocol, and this is the real problem that should be
>> solved.
>
> 64K is a pure one guest kernel co
On Mon, 2015-09-14 at 14:40 +0200, Christoffer Dall wrote:
> On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel > >
> > wrote:
> >
> > > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > > This is a Linux Dom0 crash on x86 (Dell P
On Mon, Sep 14, 2015 at 02:40:08PM +0200, Christoffer Dall wrote:
> On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel
> > wrote:
> >
> > > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > > This is a Linux Dom0 crash on x86 (Del
When restoring the system register state for an AArch32 guest at EL2,
writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
which can lead to the guest effectively running with junk in the DACR
and running into unexpected domain faults.
This patch works around the issue by re-order
On Mon, 14 Sep 2015, Roger Pau Monné wrote:
> IMHO this splitting is just a workaround for the fact that we don't have
> a 64KB PV block protocol, and this is the real problem that should be
> solved.
64K is a pure one guest kernel configuration option, not a platform wide
option. The hypervisor i
On 14/09/15 15:29, Roger Pau Monné wrote:
>> To give you an example, Centos 7, which will support Xen and only 64KB
>> page granularity, will be supported for years. Dropping any splitting in
>> a short future (3-5 years) will just break those guests to boot on Xen.
>
> Can't the patches to suppor
>>> On 14.09.15 at 16:24, wrote:
> For Intel IGD passthrough, the guest driver programs the device to DMA
> to/from its RMRR.
>
> c/s 619ecf8 "make {set,clear}_identity_p2m_mapping() work for PV guests"
> was incomplete for pre-Broadwell systems which did not support shared
> EPT.
>
> The correc
Hello,
El 14/09/15 a les 14.47, Julien Grall ha escrit:
> On 14/09/15 13:08, Roger Pau Monné wrote:
>>> I'd like to see a basic support of 64KB page granularity upstream before
>>> starting to think about performance improvement. And there is still a
>>> lot to do.
>>
>> I wasn't actually thinking
>>> On 14.09.15 at 05:27, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -288,14 +288,39 @@ int psr_get_cat_l3_info(unsigned int socket, uint32_t
> *cbm_len,
> return 0;
> }
>
> -int psr_get_l3_cbm(struct domain *d, unsigned int socket, uint64_t *cbm)
> +int psr_get_l3_
From: Malcolm Crossley
For Intel IGD passthrough, the guest driver programs the device to DMA
to/from its RMRR.
c/s 619ecf8 "make {set,clear}_identity_p2m_mapping() work for PV guests"
was incomplete for pre-Broadwell systems which did not support shared
EPT.
The correct check to use is iommu_u
>>> On 14.09.15 at 05:27, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -21,9 +21,16 @@
>
> #define PSR_CMT(1<<0)
> #define PSR_CAT(1<<1)
> +#define PSR_CDP(1<<2)
>
> struct psr_cat_cbm {
> -uint64_t cbm;
> +union {
> +uint64_t cbm
On 09/14/2015 09:13 AM, Juergen Gross wrote:
HYPERVISOR_memory_op() is defined to return an "int" value. This is
wrong, as the Xen hypervisor will return "long".
The sub-function XENMEM_maximum_reservation returns the maximum
number of pages for the current domain. An int will overflow for a
d
On Mon, Sep 14, 2015 at 12:12 PM, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):
>> On 09/14/2015 12:36 PM, George Dunlap wrote:
>> > Anyone want to look into the Linux source code to find out how big it
>> > will allow busnum / devnum to grow?
>
On Mon, Sep 14, 2015 at 03:09:34PM +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 14:28, Daniel Kiper wrote:
> > On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
> >> On 14 September 2015 at 11:25, Mark Rutland wrote:
> >> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel
While "ioport" list element parsing already validates that the entire
input string got consumed, its two siblings so far didn't.
Signed-off-by: Jan Beulich
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1730,7 +1730,7 @@ static void parse_config_data(const char
struct keyhandler does not contain much information, and requires a lot
of boilerplate to use. It is far more convenient to have
register_keyhandler() take each piece of information a parameter,
especially when introducing temporary debugging keyhandlers.
This in turn allows struct keyhandler its
On Mon, 14 Sep 2015, Juergen Gross wrote:
> Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
> source file.
>
> Signed-off-by: Juergen Gross
Acked-by: Stefano Stabellini
> arch/arm/xen/enlighten.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch
On Mon, Sep 14, 2015 at 03:29:57PM +0200, Juergen Gross wrote:
> On 09/14/2015 03:23 PM, Wei Liu wrote:
> >On Mon, Sep 14, 2015 at 02:54:09PM +0200, Juergen Gross wrote:
> >>Remove unused fields from the domain builder and associated functions.
> >>
> >>Signed-off-by: Juergen Gross
> >>---
> >> t
On 09/14/2015 03:23 PM, Wei Liu wrote:
On Mon, Sep 14, 2015 at 02:54:09PM +0200, Juergen Gross wrote:
Remove unused fields from the domain builder and associated functions.
Signed-off-by: Juergen Gross
---
tools/libxc/include/xc_dom.h | 2 --
tools/python/xen/lowlevel/xc/xc.c | 8 ++---
On Mon, Sep 14, 2015 at 02:54:09PM +0200, Juergen Gross wrote:
> Remove unused fields from the domain builder and associated functions.
>
> Signed-off-by: Juergen Gross
> ---
> tools/libxc/include/xc_dom.h | 2 --
> tools/python/xen/lowlevel/xc/xc.c | 8 ++--
> 2 files changed, 2 insert
Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
source file.
Signed-off-by: Juergen Gross
---
arch/arm/xen/enlighten.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eeeab07..5421706 100644
--- a/arc
HYPERVISOR_memory_op() is defined to return an "int" value. This is
wrong, as the Xen hypervisor will return "long".
The sub-function XENMEM_maximum_reservation returns the maximum
number of pages for the current domain. An int will overflow for a
domain configured with 8TB of memory or more.
Cor
On 14 September 2015 at 14:28, Daniel Kiper wrote:
> On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
>> On 14 September 2015 at 11:25, Mark Rutland wrote:
>> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
>> >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutlan
On Mon, Sep 14, 2015 at 4:39 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 14/09/15 12:00, Vijay Kilari wrote:
>> I will take care of A & B in next revision.
>>
>> Is there any further comments on this series?. I have not received
>> any comments on last few patches (patch #25 to patch#30).
>
> I hav
Hi Juergen,
On 04/09/15 13:50, Juergen Gross wrote:
> HYPERVISOR_memory_op() is defined to return an "int" value. This is
> wrong, as the Xen hypervisor will return "long".
>
> The sub-function XENMEM_maximum_reservation returns the maximum
> number of pages for the current domain. An int will ov
Remove unused fields from the domain builder and associated functions.
Signed-off-by: Juergen Gross
---
tools/libxc/include/xc_dom.h | 2 --
tools/python/xen/lowlevel/xc/xc.c | 8 ++--
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/li
On 14/09/15 13:08, Roger Pau Monné wrote:
>> I'd like to see a basic support of 64KB page granularity upstream before
>> starting to think about performance improvement. And there is still a
>> lot to do.
>
> I wasn't actually thinking of this as a performance improvement, but
> rather as a way of
Ping?
On 09/04/2015 02:50 PM, Juergen Gross wrote:
HYPERVISOR_memory_op() is defined to return an "int" value. This is
wrong, as the Xen hypervisor will return "long".
The sub-function XENMEM_maximum_reservation returns the maximum
number of pages for the current domain. An int will overflow fo
On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel
> wrote:
>
> > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5-2450),
> > > CC'ing relevant people. As you can see
On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 11:25, Mark Rutland wrote:
> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> >> > On Fri, Sep 11, 2015 at 01:46:43PM +0100,
On Mon, 2015-09-14 at 13:07 +0200, Laszlo Ersek wrote:
> Debian Wheezy is not very old, it's only a year older than RHEL7 (May
> > 2013
> > vs June 2014) and only a bit older than two years in absolute terms. It is
> > also the subject of an LTS effort, which extends its lifetime to 2018.
>
> (*)
On Mon, Sep 14, 2015 at 10:25:19AM +0100, Mark Rutland wrote:
> On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > > On Thu, Sep 10, 2015 at 05:23:0
On 09/14/2015 03:13 PM, Jan Beulich wrote:
On 14.09.15 at 13:53, wrote:
>> I've found this out by accident, since I have some code that does some
>> #ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while
>> running staging ("Xen version 4.7-unstable") it seems that in
>> xen/xen-c
>>> On 14.09.15 at 13:53, wrote:
> I've found this out by accident, since I have some code that does some
> #ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while
> running staging ("Xen version 4.7-unstable") it seems that in
> xen/xen-compat.h we still have:
>
> #define __XEN_LATEST
El 14/09/15 a les 13.21, Julien Grall ha escrit:
> On 14/09/15 12:04, Roger Pau Monné wrote:
>> Hello,
>>
>> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>>> Hi Roger,
>>>
>>> On 14/09/15 09:56, Roger Pau Monné wrote:
El 07/09/15 a les 17.33, Julien Grall ha escrit:
> Hi all,
>
>>>
Hello,
I've found this out by accident, since I have some code that does some
#ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while
running staging ("Xen version 4.7-unstable") it seems that in
xen/xen-compat.h we still have:
#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040600
Is th
flight 61817 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60869
test-amd64-i386-xl-qemuu-ovm
flight 61809 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60577
test-am
On 14/09/2015 19:18, Jan Beulich wrote:
>>> On 14.09.15 at 04:42, wrote:
> By default, the old P-state driver (acpi-freq) is used. Adding
> "intel_pstate" to the Xen booting param list to enable the use of
> intel_pstate. However, if intel_pstate is enabled on a machine which
> does not suppor
>>> On 14.09.15 at 13:16, wrote:
> (I still think not using SetVirtualAddressMap() at all
> would be the best approach for arm64, but unfortunately, most of my
> colleagues disagree with me)
Any reasons they have? I'm curious because we run x86 Xen without
using this function ...
Jan
_
On Monday 14 September 2015 13:04:59 Roger Pau Monné wrote:
> > TBH, I'm expecting a small impact to the performance. It would be hard
> > to get the exactly the same performance as today if we keep the helpers
> > to avoid the backend dealing himself with the splitting and page
> > granularity.
>
On 09/14/2015 01:12 PM, Ian Jackson wrote:
Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):
On 09/14/2015 12:36 PM, George Dunlap wrote:
Anyone want to look into the Linux source code to find out how big it
will allow busnum / devnum to grow?
drivers/usb/core/hcd.
On 14/09/15 12:04, Roger Pau Monné wrote:
> Hello,
>
> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>> Hi Roger,
>>
>> On 14/09/15 09:56, Roger Pau Monné wrote:
>>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granular
On Mon, 2015-09-14 at 12:13 +0100, Wei Liu wrote:
> On Mon, Sep 14, 2015 at 12:11:47PM +0100, George Dunlap wrote:
> > On Wed, Sep 9, 2015 at 2:12 PM, Wei Liu wrote:
> > > Hi all
> > >
> > > Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in
> > > xen.git.
> > >
> > > The tarbal
On Mon, Sep 14, 2015 at 11:26 AM, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: George Dunlap
>
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -107,11 +107,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
> * promise to provide zero pages. So we scrub p
>>> On 14.09.15 at 04:42, wrote:
> By default, the old P-state driver (acpi-freq) is used. Adding
> "intel_pstate" to the Xen booting param list to enable the
> use of intel_pstate. However, if intel_pstate is enabled on a
> machine which does not support the driver (e.g. Nehalem), the
> old P-sta
Wei Liu writes ("Re: [Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3"):
> On Mon, Sep 14, 2015 at 12:11:47PM +0100, George Dunlap wrote:
> > I realize they all point the same place, but shouldn't we ideally be
> > using xenproject.org rather than xensource.com? Particularly as the
> > latter hasn't actually
cr-try-bisect launders / in the testid but relies on other characters
being handled appropriately by cs-bisection-step. So for example it
can pass
graph-out=/home/logs/results/bisect/linux-linus/test-armhf-armhf-xl-arndale.leak-check--basis(8)
But cs-bisection step foolishly assumed that the
On 14 September 2015 at 12:39, Jan Beulich wrote:
On 14.09.15 at 11:36, wrote:
>> On 14 September 2015 at 11:31, Shannon Zhao wrote:
>>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>>> means we can't use runtime services and should not set the bit
>>> EFI_RUNTIME
On Mon, Sep 14, 2015 at 12:11:47PM +0100, George Dunlap wrote:
> On Wed, Sep 9, 2015 at 2:12 PM, Wei Liu wrote:
> > Hi all
> >
> > Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in xen.git.
> >
> > The tarball can be downloaded from:
> >
> > http://bits.xensource.com/oss-xen/rele
Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):
> On 09/14/2015 12:36 PM, George Dunlap wrote:
> > Anyone want to look into the Linux source code to find out how big it
> > will allow busnum / devnum to grow?
>
> drivers/usb/core/hcd.c is using a bitmap to find the ne
Hi Vijay,
On 14/09/15 12:00, Vijay Kilari wrote:
> I will take care of A & B in next revision.
>
> Is there any further comments on this series?. I have not received
> any comments on last few patches (patch #25 to patch#30).
I haven't commented the rest of the series because I'm expecting to se
On Wed, Sep 9, 2015 at 2:12 PM, Wei Liu wrote:
> Hi all
>
> Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in xen.git.
>
> The tarball can be downloaded from:
>
> http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz
>
> Signature for tarball:
>
> http://bits.x
On Mon, 2015-09-14 at 11:59 +0100, Ian Jackson wrote:
> This was a database used by networking infrastructure on the
> now-obsolete XenClient network in the Citrix Cambridge office (which
> used some management tools developed by Mythic Beasts).
>
> The production database in Cambridge no longer h
On Mon, 14 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 14, 2015 at 10:36:55AM +0100, Stefano Stabellini wrote:
> > On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > > If you'd like your ack on it, please send one, I can still do that.
> >
> > Acked-by: Stefano Stabellini
>
> S
On 09/14/15 11:22, Ian Campbell wrote:
> On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote:
>>
> [...]
>> For me that's not so clear-cut. OVMF is frequently used as a UEFI
>> development environment (it's better to brick a virtual machine than
>> your physical dev platform...)
>
> One flip sid
Hello,
El 14/09/15 a les 12.40, Julien Grall ha escrit:
> Hi Roger,
>
> On 14/09/15 09:56, Roger Pau Monné wrote:
>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>>> Hi all,
>>>
>>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>>> hypercall interface and PV prot
On Wed, Sep 9, 2015 at 8:59 PM, Ian Campbell wrote:
> On Mon, 2015-08-31 at 16:36 +0530, vijay.kil...@gmail.com wrote:
>> Some Major TODOs:
>>1) Avoid making vits_process_cmd() static in later point of time
>>2) How to handle LPI that does not have LPI config table entry.
>>3) Enable/
This was a database used by networking infrastructure on the
now-obsolete XenClient network in the Citrix Cambridge office (which
used some management tools developed by Mythic Beasts).
The production database in Cambridge no longer has the configdb, and
both instances have `HostDB_Executive_NoCon
On 09/12/15 01:06, Josh Triplett wrote:
> On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
>> On 09/11/15 21:30, Josh Triplett wrote:
>>> On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
very
On 09/14/2015 12:36 PM, George Dunlap wrote:
On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross wrote:
On 09/11/2015 04:41 PM, Ian Campbell wrote:
On Fri, 2015-09-11 at 16:18 +0200, Juergen Gross wrote:
On 09/11/2015 04:09 PM, Ian Campbell wrote:
On Fri, 2015-09-11 at 15:55 +0200, Juergen Gro
On Mon, Sep 14, 2015 at 8:13 AM, Jan Beulich wrote:
> Luckily, due to gfn_unlock() currently mapping to p2m_unlock(), this is
> only a cosmetic issue right now.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
> ---
> Despite its cosmetic nature I think it would be better to also fix
>>> On 14.09.15 at 08:24, wrote:
>> OK, that explanation is fine to me as long as it's made clear no
>> security guarantee once admin uses 'relax' for any domain. Tiejun
>> could you resend patch with right warning/error type?
>>
>
> Sure, but a little bit makes me confused when I'm trying to ad
Hi Roger,
On 14/09/15 09:56, Roger Pau Monné wrote:
> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>> Hi all,
>>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4KB page granularity.
>>
>> Any attempt to
>>> On 14.09.15 at 11:36, wrote:
> On 14 September 2015 at 11:31, Shannon Zhao wrote:
>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>> means we can't use runtime services and should not set the bit
>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross wrote:
> On 09/11/2015 04:41 PM, Ian Campbell wrote:
>>
>> On Fri, 2015-09-11 at 16:18 +0200, Juergen Gross wrote:
>>>
>>> On 09/11/2015 04:09 PM, Ian Campbell wrote:
On Fri, 2015-09-11 at 15:55 +0200, Juergen Gross wrote:
>
> On 09/
Ian Campbell writes ("[PATCH OSSTEST 2/2] crontab-cambridge: Add
distros-debian-stretch"):
> I thought I'd done this ages ago...
Acked-by: Ian Jackson
Both patches.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-dev
M A Young writes ("writing to read only scsi drives"):
> I thought I would check here in case this is a new security issue but it
> was reported at https://bugzilla.redhat.com/show_bug.cgi?id=1257893 that
> in HVM guests it was possible to write to scsi devices (either specified
> as sda etc. in
On 14/09/15 11:26, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
flight 61805 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61805/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail
in 61729 pass in 61805
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -107,11 +107,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
* promise to provide zero pages. So we scrub pages before using.
*/
for ( i = 0; i < (1 << order); i++ )
-{
-char *
On Mon, 2015-09-14 at 12:02 +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 11:57, Ian Campbell wrote:
> > > or SetVirtualAddressMap/ConvertPointer, and
> >
> > These two are RTS, so in principal it could.
> >
> > (I'm not sure about ConvertPointer, is it useful for OS kernels, or
> > ju
The weekly CD images which are used by the snapshot flight are
generated Sunday-Monday, so running that on a Saturday as we have been
doing ensures that it will take at least two iterations/weeks to get
any issues fixed.
Also the current ordering of the existing releases made it hard to
decide whe
I thought I'd done this ages ago...
Signed-off-by: Ian Campbell
---
crontab-cambridge | 1 +
1 file changed, 1 insertion(+)
diff --git a/crontab-cambridge b/crontab-cambridge
index 19669f0..c478203 100644
--- a/crontab-cambridge
+++ b/crontab-cambridge
@@ -9,6 +9,7 @@ MAILTO=ian.jack...@citrix.
Stefano Stabellini writes ("[PATCH for-4.6] libxl: handle read-only drives with
qemu-xen"):
> The current libxl code doesn't deal with read-only drives at all.
>
> Upstream QEMU and qemu-xen only support read-only cdrom drives: make
> sure to specify "readonly=on" for cdrom drives and return erro
On Mon, Sep 14, 2015 at 10:36:55AM +0100, Stefano Stabellini wrote:
> On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > If you'd like your ack on it, please send one, I can still do that.
>
> Acked-by: Stefano Stabellini
Sorry, that's a bit too late - I sent Linus the pull request on Satu
On 14 September 2015 at 11:57, Ian Campbell wrote:
> On Mon, 2015-09-14 at 11:43 +0200, Ard Biesheuvel wrote:
>
>> Xen will not boot the kernel via the stub, but directly. It needs to
>> supply a EFI like environment so that the kernel can boot via ACPI.
>> There is no reason whatsoever to mock up
1 - 100 of 131 matches
Mail list logo
