branch xen-4.6-testing
xenbranch xen-4.6-testing
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
flight 94083 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-build fail REGR. vs. 92982
build-armhf-xsm
flight 94104 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 65543
build-amd64
flight 94079 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
build-amd64-libvi
Hi Julien and Dushyant,
>>>
(XEN) DOM0: [0.00] irq: no irq domain found for
/interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for
/interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for
/interrupt-controller !
flight 94070 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94070/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94021
build-i386-rumpuserxen
flight 94089 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94089/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
This run is configured for baseline tests only.
flight 44413 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44413/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logs
(Including more folks, quoting entire patch)
On Thu, 12 May, at 08:19:54PM, Shannon Zhao wrote:
> From: Shannon Zhao
>
> The EFI DT parameters for bare metal are located under /chosen node,
> while for Xen Dom0 they are located under /hyperviosr/uefi node. These
> parameters under /chosen and /h
flight 94073 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94073/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 7a1b56b..aa7c5b1 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -24,6 +24,22 @@
>
> DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
>
> +void update_cpu_capabilities(const struct arm_cpu_capabi
On 05/10/2016 04:06 AM, Stefano Stabellini wrote:
> On Mon, 9 May 2016, Wei Liu wrote:
>> On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote:
>>> qemu commit 91a097e7 forbids specifying cache mode for empty
>>> drives. Attempting to create a domain with an empty qdisk cdrom
>>> drive result
* Hardware: ZCU102 ZynqMP board
* Software: Rolled my own dom0 linux
* Tested: Start dom0
The test fails with the following error:
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0
> diff --git a/xen/include/asm-arm/arm64/insn.h
> b/xen/include/asm-arm/arm64/insn.h
> new file mode 100644
> index 000..cfcdbe9
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/insn.h
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright (C) 2013 Huawei Ltd.
> + * Author: Jiang Liu
> + *
> + * Copyright
On Thu, May 05, 2016 at 05:34:19PM +0100, Julien Grall wrote:
> Some of the processor erratum will require to modify code sequence.
> As those modifications may impact the performance, they should only
> be enabled on affected cores. Furthermore, Xen may also want to take
> advantage of new hardwar
On Tue, May 10, 2016 at 10:03:22PM +0800, fu@linaro.org wrote:
> From: Fu Wei
>
> This patchset add xen_boot support into grup-mkconfig for
> generating xen boot entrances automatically
>
All of them look good to me.
Thanks!
> Also update the docs/grub.texi for new xen_boot commands.
>
>
From: Suravee Suthikulpanit
Along with the IVHD block type 10h, newer AMD platforms also come with
types 11h, which is a superset of the older one. Having multiple IVHD
block types in the same platform allows backward compatibility of newer
systems to work with existing drivers. The driver shoul
flight 94112 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94112/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
From: Suravee Suthikulpanit
The guest_iommu_init() is currently called by the following code path:
arch/x86/domain.c: arch_domain_create()
]- drivers/passthrough/iommu.c: iommu_domain_init()
|- drivers/passthrough/amd/pci_amd_iommu.c: amd_iommu_domain_init();
|- drive
From: Suravee Suthikulpanit
Hi All,
On systems with iommu v2 enabled, the hypervisor crashes when trying
to start up an HVM guest.
Investigating shows that the guest_iommu_init() is called before the
HVM domain is initialized. It then tries to register_mmio_handler()
causing the hvm_next_io_ha
From: Suravee Suthikulpanit
At the time of registering HVM I/O handler, the HVM domain might
not have been initialized, which means the hvm_domain.io_handler
would be NULL. In the hvm_next_io_handler(), this should be checked
before returning and referencing the array. Also, the io_handler_count
On Tue, May 10, 2016 at 04:05:24PM -0500, Doug Goldstein wrote:
> There are a number of debugging options for Xen so the idea is to have a
> menu to group them all together. Enabling this menu item will also
> disable NDEBUG which will result in more debug prints. This was
> previously wired into t
hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
general L1 p2m walk. It is fine for AMD as NPT share the same format as
normal pagetables. For Intel EPT however, it is wrong.
The translation ends up correct (as the formats are sufficiently similar), but
the control b
On 13/05/16 18:02, Wei Liu wrote:
> On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote:
>> As has been explained previously[1], SMAP (and with less relevance
>> also SMEP) is not compatible with 32-bit PV guests which aren't
>> aware/prepared to be run with that feature enabled. Andrew's
>
From: Suravee Suthikulpanit
Hi All,
On systems with iommu v2 enabled, the hypervisor crashes when trying
to start up an HVM guest.
Investigating shows that the guest_iommu_init() is called before the
HVM domain is initialized. It then tries to register_mmio_handler()
causing the hvm_next_io_ha
From: Suravee Suthikulpanit
The guest_iommu_init() is currently called by the following code path:
arch/x86/domain.c: arch_domain_create()
]- drivers/passthrough/iommu.c: iommu_domain_init()
|- drivers/passthrough/amd/pci_amd_iommu.c: amd_iommu_domain_init();
|- drive
From: Suravee Suthikulpanit
At the time of registering HVM I/O handler, the HVM domain might
not have been initialized, which means the hvm_domain.io_handler
would be NULL. In the hvm_next_io_handler(), this should be checked
before returning and referencing the array. Also, the io_handler_count
On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote:
> As has been explained previously[1], SMAP (and with less relevance
> also SMEP) is not compatible with 32-bit PV guests which aren't
> aware/prepared to be run with that feature enabled. Andrew's
> original approach either sacrificed ar
flight 94065 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94065/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail in 94038 pass in
94065
test-amd64-i386-xl-qemut-de
On Fri, May 13, 2016 at 10:12 AM, Jan Beulich wrote:
On 13.05.16 at 17:31, wrote:
>> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote:
>> On 13.05.16 at 16:50, wrote:
On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote:
On 12.05.16 at 17:25, wrote:
>> @@ -1468,6 +1
>>> On 13.05.16 at 17:35, wrote:
> On 05/13/2016 11:09 AM, Jan Beulich wrote:
> On 13.05.16 at 16:50, wrote:
> [...]
> @@ -1468,6 +1505,69 @@ int
> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
> }
> break;
>
> +case X
On Fri, 2016-05-13 at 10:23 +0100, Andrew Cooper wrote:
> On 13/05/16 09:55, Jan Beulich wrote:
> >
> > But anyway, L2 or L3 - I can't see how this context switching would
> > DTRT when there are vCPU-s of different domains on the same
> > socket (or core, if L2s and MSRs were per-core): The one g
On 17/03/16 16:14, Jan Beulich wrote:
> Instead of addressing these fields via the base of the stack (which
> uniformly requires 4-byte displacements), address them from the end
> (which for everything other than guest_cpu_user_regs requires just
> 1-byte ones). This yields a code size reduction so
>>> On 13.05.16 at 17:31, wrote:
> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote:
> On 13.05.16 at 16:50, wrote:
>>> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote:
>>> On 12.05.16 at 17:25, wrote:
> @@ -1468,6 +1505,69 @@ int
> +if ( rc )
> +
>>> On 13.05.16 at 17:57, wrote:
> On 17/03/16 08:03, Jan Beulich wrote:
>> Alternatives patching code picks the most suitable NOPs for the
>> running system, so simply use it to replace the pre-populated ones.
>>
>> Use an arbitrary, always available feature to key off from, but
>> hide this behi
On 13/05/16 17:06, Jan Beulich wrote:
On 13.05.16 at 17:57, wrote:
>> On 17/03/16 08:03, Jan Beulich wrote:
>>> Alternatives patching code picks the most suitable NOPs for the
>>> running system, so simply use it to replace the pre-populated ones.
>>>
>>> Use an arbitrary, always available fe
On 17/03/16 08:03, Jan Beulich wrote:
> Since such guests' kernel code runs in ring 1, their memory accesses,
> at the paging layer, are supervisor mode ones, and hence subject to
> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> two features though (and so far we also don't
On 17/03/16 08:03, Jan Beulich wrote:
> Alternatives patching code picks the most suitable NOPs for the
> running system, so simply use it to replace the pre-populated ones.
>
> Use an arbitrary, always available feature to key off from, but
> hide this behind the new X86_FEATURE_ALWAYS.
>
> Signed
On 10/03/16 09:53, Jan Beulich wrote:
> Since such guests' kernel code runs in ring 1, their memory accesses,
> at the paging layer, are supervisor mode ones, and hence subject to
> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> two features though (and so far we also don't
>>> On 13.05.16 at 17:27, wrote:
> We're approaching the release date so I would like to wrap this up.
>
> As I understand it, there is indeed an issue in the emulator, but a
> proper fix that take into consideration all cases has not been proposed.
>
> Should we make this a blocker for the rele
>>> On 06.05.16 at 13:41, wrote:
> Looking at the qdisk backend implementation I wondered whether
> blkif_get_x86_32_req() is really correct, especially for the
> BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to
> distinguish 32- and 64-bit layouts of blkif_request_discard while
On 10/03/16 09:54, Jan Beulich wrote:
> Alternatives patching code picks the most suitable NOPs for the
> running system, so simply use it to replace the pre-populated ones.
>
> Use an arbitrary, always available feature to key off from, but
> hide this behind the new X86_FEATURE_ALWAYS.
>
> Signed
On 05/13/2016 11:09 AM, Jan Beulich wrote:
On 13.05.16 at 16:50, wrote:
[...]
@@ -1468,6 +1505,69 @@ int
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
}
break;
+case XENMEM_sharing_op_bulk_share:
+{
+unsigned long max_sgfn
On Fri, May 13, 2016 at 09:30:23AM -0600, Jan Beulich wrote:
> >>> On 13.05.16 at 17:21, wrote:
> > On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
> >> >>> On 17.03.16 at 09:03, wrote:
> >> > Since such guests' kernel code runs in ring 1, their memory accesses,
> >> > at the paging
>>> On 13.05.16 at 17:24, wrote:
> On 13/05/16 16:00, Andrew Cooper wrote:
>> On 13/05/16 15:13, Jan Beulich wrote:
>> On 13.05.16 at 15:33, wrote:
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v
On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote:
On 13.05.16 at 16:50, wrote:
>> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote:
>> On 12.05.16 at 17:25, wrote:
+if ( !rc )
+mem_sharing_share_pages(d, bulk->start, sh, cd,
bulk->start,
>>> On 13.05.16 at 17:21, wrote:
> On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
>> >>> On 17.03.16 at 09:03, wrote:
>> > Since such guests' kernel code runs in ring 1, their memory accesses,
>> > at the paging layer, are supervisor mode ones, and hence subject to
>> > SMAP/SMEP ch
flight 94064 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94064/
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. 65543
Tests which did not succeed,
>>> On 22.04.16 at 12:54, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also specified
> vpmu will be turned off.
> As the virtualisation is not 100% safe, don't use the vpmu flag on
>
We're approaching the release date so I would like to wrap this up.
As I understand it, there is indeed an issue in the emulator, but a
proper fix that take into consideration all cases has not been proposed.
Should we make this a blocker for the release? I'm inclined to say no
because it has bee
On 13/05/16 16:00, Andrew Cooper wrote:
> On 13/05/16 15:13, Jan Beulich wrote:
> On 13.05.16 at 15:33, wrote:
>>> --- a/xen/arch/x86/mm/hap/nested_hap.c
>>> +++ b/xen/arch/x86/mm/hap/nested_hap.c
>>> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain
>>> *p2m,
>>> * wa
On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
> On Fri, 13 May 2016, Jan Beulich wrote:
>
> > >>> On 13.05.16 at 15:49, wrote:
> > > ...
> > >
> > > Still an issue - with 4.7.0-rc1.
> >
> > And I don't recall anyone having contributed a fix/workaround.
> >
> > > If I do:
> > >
>
On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
> >>> On 17.03.16 at 09:03, wrote:
> > Since such guests' kernel code runs in ring 1, their memory accesses,
> > at the paging layer, are supervisor mode ones, and hence subject to
> > SMAP/SMEP checks. Such guests cannot be expected to
>>> On 13.05.16 at 17:00, wrote:
> On 13/05/16 15:13, Jan Beulich wrote:
> On 13.05.16 at 15:33, wrote:
>>> +unsigned int l1_page_order;
>>> +int rv;
>>>
>>> /* translate l2 guest va into l2 guest gfn */
>>> p2m = p2m_get_nestedp2m(v, np2m_base);
>>>
* Hardware: Intel(R) Xeon(R) CPU E5-2430
* Sofware: Debian Jessie dom0
* Functionality tested:
xl save/resume
vm_event/mem_access/monitor/altp2m
Comment: everything works as expected.
Cheers,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
I have noticed that frontswap.h first declares "frontswap_enabled" as extern
bool variable, and then overrides it with "#define frontswap_enabled (1)" for
CONFIG_FRONTSWAP=Y or (0) when disabled. The bool variable isn't actually
instantiated anywhere.
This all looks like an unfinished attempt to m
>>> On 13.05.16 at 16:50, wrote:
> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote:
> On 12.05.16 at 17:25, wrote:
>>> +if ( !rc )
>>> +mem_sharing_share_pages(d, bulk->start, sh, cd,
>>> bulk->start, ch);
>>
>> You shouldn't be ignoring errors here.
>
> The
On Fri, May 13, 2016 at 5:31 AM, Wei Liu wrote:
> On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote:
>> * Hardware:
>> CPU: Intel Core2 Quad Q9400
>> Total Memory: 2791088 kB
>>
>> * Software:
>> Ubuntu 14.04
>> Linux kernel: 3.13.0-68
>>
>> * Guest operating systems:
>> Ubuntu 14.04 (PV)
>
On 13/05/16 15:13, Jan Beulich wrote:
On 13.05.16 at 15:33, wrote:
>> --- a/xen/arch/x86/mm/hap/nested_hap.c
>> +++ b/xen/arch/x86/mm/hap/nested_hap.c
>> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
>> * walk is successful, the translated value is returned i
On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote:
On 12.05.16 at 17:25, wrote:
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d)
>> return rc;
>> }
>>
>> +static int bulk_share(struct
flight 94061 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 9 debian-installfail REGR. vs. 93937
Regressions which a
On Fri, 13 May 2016, Jan Beulich wrote:
> >>> On 13.05.16 at 15:49, wrote:
> > ...
> >
> > Still an issue - with 4.7.0-rc1.
>
> And I don't recall anyone having contributed a fix/workaround.
>
> > If I do:
> >
> > $export CFLAGS=" "'
> > $make
> >
> > I end up with:
> > gcc -E -O1 -fno-omit-
>>> On 13.05.16 at 15:33, wrote:
> --- a/xen/arch/x86/mm/hap/nested_hap.c
> +++ b/xen/arch/x86/mm/hap/nested_hap.c
> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
> * walk is successful, the translated value is returned in
> * L1_gpa. The result value tells what
>>> On 13.05.16 at 15:49, wrote:
> On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
>> > >>> On 01.12.15 at 15:36, wrote:
>> > > On December 1, 2015 8:19:32 AM EST, Jan Beulich
>> > > wrote:
>> > > On 01.1
On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
> > >>> On 01.12.15 at 15:36, wrote:
> > > On December 1, 2015 8:19:32 AM EST, Jan Beulich wrote:
> > > On 01.12.15 at 00:37, wrote:
> > >>> When I try to bui
Hi Marek
On Fri, May 13, 2016 at 02:35:21PM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull
> some patches from unstable, but then I hit some strange problem:
>
> During configure run in stubdom/gmp-x86_64 I've got:
hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
general L1 p2m walk. It is fine for AMD as NPT share the same format as
normal pagetables. For Intel EPT however, it is wrong.
The translation ends up correct (as the formats are sufficiently similar), but
the control b
Hi,
I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull
some patches from unstable, but then I hit some strange problem:
During configure run in stubdom/gmp-x86_64 I've got:
checking size of unsigned short... configure: error: cannot compute sizeof
(unsigned short)
> > > >This is what I've been remembering:
> > > >
> > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb9
> > > 927
> > > > 8b6ba885616bb183b88ad67
> > >
> > > The comment on this link describes exactly what I am experiencing.
> > > Thanks so much.
> >
> > Thanks Jan for provi
> -Original Message-
> From: Wu, Feng [mailto:feng...@intel.com]
> Sent: Friday, May 13, 2016 3:11 AM
> To: Zytaruk, Kelly; Jan Beulich
> Cc: Tian, Kevin; xen-devel@lists.xen.org; Wu, Feng
> Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not
> executed\n")
>
>
>
>
>>> On 12.05.16 at 17:25, wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d)
> return rc;
> }
>
> +static int bulk_share(struct domain *d, struct domain *cd, unsigned long max,
> +
>>> On 06.05.16 at 16:33, wrote:
> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_intros
>>> On 13.05.16 at 12:55, wrote:
> Am 18.04.2016 um 15:31 schrieb Xen.org security team:
>> +/*
>> + * Bit 24 of a 24-bit flag mask! This is not any bit of a real pte,
>> + * and is only used for signalling in variables that contain flags.
>> + */
>> +#define _PAGE_INVALID_BIT (1U<<24)
>> +
>> #
On Fri, May 13, 2016 at 09:37:27AM +0100, Paul Durrant wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
>
> A previous patch added the necessar
Hi,
Am 18.04.2016 um 15:31 schrieb Xen.org security team:
> Xen Security Advisory CVE-2016-3960 / XSA-173
> version 3
>
> x86 shadow pagetables: address width overflow
...
> ISSUE DESCRIPTION
> =
> In the x86 shadow pagetable
On Fri, May 13, 2016 at 04:52:43AM -0600, Jan Beulich wrote:
> >>> On 13.05.16 at 12:41, wrote:
> > On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote:
> >> flight 94059 xen-4.6-testing real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/94059/
> >>
> >> Regressi
>>> On 13.05.16 at 12:41, wrote:
> On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote:
>> flight 94059 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/94059/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including
>>> On 13.05.16 at 12:33, wrote:
> flight 94059 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94059/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-libvirt5 libvirt-build
flight 94063 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94063/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote:
> flight 94059 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94059/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386
flight 94059 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 93932
build-amd64-libvi
On Thu, May 12, 2016 at 05:48:13PM +0200, Olaf Hering wrote:
> Migrating a HVM guest from staging-4.4 to staging-4.5 fails:
>
> # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> char device redirected to /dev/pts/4 (label serial0)
> xen_ram_alloc: do not alloc f80 bytes of ram
On Thu, 12 May 2016, Olaf Hering wrote:
> On Thu, May 12, Olaf Hering wrote:
>
> > One thing to fix it in staging-4.5 is to introduce a dummy device which
> > handles a section named "kvm-tpr-opt". I already have a hack which does
> > that, and the migration proceeds. I will propose a patch to dea
Hi George,
after quite a bit of debugging on 4.6.1 I learned that said commit
("x86/P2M: consolidate handling of types not requiring a valid MFN")
is more than just cleanup: Since p2m_set_entry() happily performs
arithmetic on the passed in MFN, shadow mode guests (verified) as
well as HAP ones wh
On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote:
> * Hardware:
> CPU: Intel Core2 Quad Q9400
> Total Memory: 2791088 kB
>
> * Software:
> Ubuntu 14.04
> Linux kernel: 3.13.0-68
>
> * Guest operating systems:
> Ubuntu 14.04 (PV)
>
> * Functionality tested:
> xl sched-rtds (for set/get pe
On 13/05/16 09:55, Jan Beulich wrote:
On 13.05.16 at 09:43, wrote:
>> On 13/05/2016 07:48, Jan Beulich wrote:
>> On 13.05.16 at 08:26, wrote:
On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
On 12.05.16 at 11:40, wrote:
>> We plan to bring new PQoS feature
On May 13, 2016 5:09 PM, Jan Beulich wrote:
> >>> On 13.05.16 at 10:04, wrote:
> > On May 12, 2016 11:06 PM, Jan Beulich wrote:
> >> >>> On 12.05.16 at 16:28, wrote:
> >> > On May 10, 2016 2:54 PM, Jan Beulich wrote:
> >> >> >>> On 10.05.16 at 05:41, wrote:
> >> >> > On May 10, 2016 12:14 AM,
>>> On 13.05.16 at 10:04, wrote:
> On May 12, 2016 11:06 PM, Jan Beulich wrote:
>> >>> On 12.05.16 at 16:28, wrote:
>> > On May 10, 2016 2:54 PM, Jan Beulich wrote:
>> >> >>> On 10.05.16 at 05:41, wrote:
>> >> > On May 10, 2016 12:14 AM, Jan Beulich wrote:
>> >> >> >>> On 06.05.16 at 10:54,
>>> On 13.05.16 at 09:43, wrote:
> On 13/05/2016 07:48, Jan Beulich wrote:
> On 13.05.16 at 08:26, wrote:
>>> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
>>> On 12.05.16 at 11:40, wrote:
> We plan to bring new PQoS feature called Intel L2 Cache Allocation
> Techn
My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.
Patch #1 adds the necessary boilerplate to map the
My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.
This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a fr
My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.
A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it
My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.
This patch adds code to xen-netback to use the value in a hash extra
info fragment passed from the guest frontend in a transmit-side
(i.e. netb
My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.
This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.
flight 94056 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 94035 REGR. vs.
92982
Tests which are f
On May 12, 2016 11:06 PM, Jan Beulich wrote:
> >>> On 12.05.16 at 16:28, wrote:
> > On May 10, 2016 2:54 PM, Jan Beulich wrote:
> >> >>> On 10.05.16 at 05:41, wrote:
> >> > On May 10, 2016 12:14 AM, Jan Beulich wrote:
> >> >> >>> On 06.05.16 at 10:54, wrote:
Jan,
Try it again, I hope I have
On 13/05/2016 07:48, Jan Beulich wrote:
On 13.05.16 at 08:26, wrote:
>> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
>> On 12.05.16 at 11:40, wrote:
We plan to bring new PQoS feature called Intel L2 Cache Allocation
Technology (L2 CAT) to Xen.
L2 CAT i
On Thu, 2016-05-12 at 23:34 -0400, Meng Xu wrote:
> On Wed, May 11, 2016 at 11:20 AM, Tianyang Chen > wrote:
> >
> > No functional change:
> > -Various coding style fix
> > -Added comments for UPDATE_LIMIT_SHIFT.
> >
Hey, Tianyang, thanks for this.
> > Use non-atomic bit-ops:
> > -Vcpu flags
On Do, 2016-05-12 at 16:13 +0200, Juergen Gross wrote:
> This series adds a Xen pvUSB backend driver to qemu. USB devices
> connected to the host can be passed through to a Xen guest. The
> devices are specified via Xenstore. Access to the devices is done
> via host-libusb.c
>
> I've tested the ba
> -Original Message-
> From: Zytaruk, Kelly [mailto:kelly.zyta...@amd.com]
> Sent: Thursday, May 12, 2016 10:21 PM
> To: Jan Beulich
> Cc: Wu, Feng ; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not
> executed\n")
>
>
>
1 - 100 of 101 matches
Mail list logo
