On May 23, 2016 9:31 PM, Jan Beulich wrote:
> >>> On 18.05.16 at 10:08, wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1391,13 +1399,26 @@ int domain_context_mapping_one(
> > spin_unlock(&iommu->lock);
> >
> > /* Context entry
flight 94782 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94782/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
Move sharing locks above altp2m to avoid locking order violation. Allow
applying altp2m mem_access settings when the hostp2m entries are shared.
Also, do not trigger PoD for hostp2m when setting altp2m mem_access to be
in-line with non-altp2m mem_access path. Also allow gfn remapping with
p2m_ram_s
flight 94773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
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
opt_psr is now not only used at booting time but also at runtime.
More specifically, it is used to check CDP switch in psr_cpu_init()
which can potentially be called in CPU hotplug case.
Signed-off-by: Chao Peng
---
xen/arch/x86/psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
The patch fixing this issue has already been sent to upstream.
" [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list "
v2 will be sent out soon.
Thanks,
Feng
> -Original Message-
> From: Hao, Xudong
> Sent: Thursday, May 26, 2016 9:45 AM
> To: Xen-devel
> Cc: Wu, F
Xen 4.7 RC3 enabled VT-d PI(iommu=on,intpost), and created HVM guest with VF
NIC assigned repeatedly, it will cause Xen panic(maybe 2 times ,5 times ,10
times).
It's not a RC3 regression, at least this Xen commit 1bd52e1f got failure as
well.
HW: Intel Broadwell server, Intel(R) Xeon(R) CPU E5-
On May 26, 2016 12:02 AM, Jan Beulich wrote:
> >>> On 25.05.16 at 17:34, wrote:
> > On May 23, 2016 10:19 PM, Jan Beulich wrote:
> >> >>> On 18.05.16 at 10:08, wrote:
> >> > +unsigned long type,
> >> > +int preempti
flight 94776 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94776/
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
Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
address" forgot to consider dom_xen, which fails tools/xen-mceinj when
it's going to inject into domain DOMID_XEN (e.g. when -d option is not
used) via XEN_MC_msrinject. Use dom_xen when the domain id DOMID_XEN is
passed in.
Signed-o
flight 94770 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 94756
Regressions which ar
flight 94774 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94774/
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
flight 94772 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94772/
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 Wed, May 25, 2016 at 04:33:54AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > --- a/xen/arch/x86/boot/build32.lds
> > +++ b/xen/arch/x86/boot/build32.lds
> > @@ -25,6 +25,7 @@ SECTIONS
> > *(.text)
> > *(.text.*)
> > *(.rodata)
> > +*(.rodat
On Wed, May 25, 2016 at 03:32:37AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > @@ -100,19 +107,29 @@ multiboot2_header_end:
> > gdt_boot_descr:
> > .word 6*8-1
> > .long sym_phys(trampoline_gdt)
> > +.long 0 /* Needed for 64-bit lgdt */
> > +
>
On Thu, May 12, 2016 at 02:13:21PM +, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > >
> > > Ok. Do you regard this as a critical issue for 4.7?
> > >
> >
> > Our general support statement is to support N->N+1 migration, so it is
> > not really critical for me. On the other ha
On Tue, May 24, 2016 at 11:16 AM, Dario Faggioli
wrote:
> [trimmed To/Cc]
>
> On Fri, 2016-05-20 at 13:56 -0400, Meng Xu wrote:
>> On Fri, May 20, 2016 at 6:20 AM, Jan Beulich
>> wrote:
>> > Or, as an alternative to Olaf's reply, don't install the tools at
>> > all, but
>> > instead run everythin
Hi Wei,
On Wed, May 25, 2016 at 6:53 AM, Wei Liu wrote:
> On Tue, May 24, 2016 at 04:47:38PM -0400, Meng Xu wrote:
>> Hi Olaf,
>>
>> Thank you very much for your suggestion!
>>
>> On Fri, May 20, 2016 at 4:52 AM, Olaf Hering wrote:
>> > On Thu, May 19, Meng Xu wrote:
>> >
>> >> Does anyone try t
On Wed, May 25, 2016 at 02:39:57AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > There is a problem with place_string() which is used as early memory
> > allocator. It gets memory chunks starting from start symbol and
> > going down. Sadly this does not work when Xen is loaded u
Hello,
I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3
platform. I'm using Xen 4.6.
After successfully creating bare metal example(by successful I mean I've stuck
processor in while loop in main function), I probably should initialize memory
management unit and similiar
On Wed, May 25, 2016 at 12:25 PM, George Dunlap
wrote:
> On Wed, May 25, 2016 at 5:58 PM, Tamas K Lengyel wrote:
>> On Wed, May 25, 2016 at 10:08 AM, George Dunlap
>> wrote:
>>> On Wed, May 25, 2016 at 4:31 PM, Tamas K Lengyel
>>> wrote:
On May 25, 2016 05:27, "George Dunlap" wrote:
flight 94758 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
version targeted
On 05/05/2016 12:58 AM, Lv Zheng wrote:
> ACPICA commit c49a751b4dae7baec1790748a2b4b6e8ab599f51
>
> For Access Size = 0, it actually can use user expected access bit width.
> This patch implements this.
>
> Besides of the ACPICA upstream commit, this patch also includes a fix fixing
> the issue re
On Wed, May 25, 2016 at 01:53:31AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > --- a/xen/arch/x86/efi/Makefile
> > +++ b/xen/arch/x86/efi/Makefile
> > @@ -1,14 +1,9 @@
> > CFLAGS += -fshort-wchar
> >
> > -obj-y += stub.o
> > -
> > -create = test -e $(1) || touch -t 1999010100
flight 94769 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 94767
Tests which di
On 5/23/2016 6:46 AM, Jan Beulich wrote:
On 22.05.16 at 01:42, wrote:
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -258,6 +258,8 @@ struct hvm_io_handler *hvm_next_io_handler(struct domain *d)
{
unsigned int i = d->arch.hvm_domain.io_handler_count++;
+ASSE
On 5/23/2016 6:54 AM, Jan Beulich wrote:
On 22.05.16 at 01:42, wrote:
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/pa
On 5/23/2016 3:23 AM, Paul Durrant wrote:
-Original Message-
> From: suravee.suthikulpa...@amd.com
> [mailto:suravee.suthikulpa...@amd.com]
> Sent: 22 May 2016 00:43
> To: xen-devel@lists.xen.org; Paul Durrant; jbeul...@suse.com; George
> Dunlap
> Cc: Keir (Xen.org); Suravee Suthikulpanit
flight 94765 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94765/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-inte
On Wed, May 25, 2016 at 5:58 PM, Tamas K Lengyel wrote:
> On Wed, May 25, 2016 at 10:08 AM, George Dunlap
> wrote:
>> On Wed, May 25, 2016 at 4:31 PM, Tamas K Lengyel wrote:
>>>
>>> On May 25, 2016 05:27, "George Dunlap" wrote:
On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel
wr
Thanks for these review comment. I'll update this patch and send out V3
Suravee
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
- Original Message -
> From: "Anthony PERARD"
> To: "Paul Durrant"
> Cc: qemu-de...@nongnu.org, xen-de...@lists.xenproject.org, "Stefano
> Stabellini" , "Paolo
> Bonzini"
> Sent: Wednesday, May 25, 2016 5:52:32 PM
> Subject: Re: [PATCH v3] xen-hvm: ignore background I/O sections
>
>
flight 94766 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94766/
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 Wed, May 25, 2016 at 01:20:23AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > --- a/xen/arch/x86/efi/stub.c
> > +++ b/xen/arch/x86/efi/stub.c
> > @@ -4,11 +4,8 @@
> > #include
> > #include
> >
> > -#ifndef efi_enabled
> > -const bool_t efi_enabled = 0;
> > -#endif
> > -
>
On Wed, May 25, 2016 at 10:08 AM, George Dunlap
wrote:
> On Wed, May 25, 2016 at 4:31 PM, Tamas K Lengyel wrote:
>>
>> On May 25, 2016 05:27, "George Dunlap" wrote:
>>>
>>> On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel
>>> wrote:
>>> > Don't propagate altp2m changes from ept_set_entry for me
On 25/05/16 15:30, Ed Swierk wrote:
> The following lockdep dump occurs whenever I destroy an HVM domain, on
> Linux 4.4 Dom0 with CONFIG_XEN_BALLOON=n on recent stable Xen 4.5.
This occurs in dom0? Or the guest that's being destroyed?
> Any clues whether this is a real potential deadlock, or ho
On 05/25/2016 12:51 PM, Boris Ostrovsky wrote:
> Let me see whether which path we take.
That is "Let me see which code path we are taking in Linux"
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
The inaugural OpenXT Summit brings together developers and ecosystem
participants for a 2-day conference in Fairfax, VA, USA on June 7-8, 2016. The
audience for this event includes kernel and application developers, hardware
designers, system integrators and security architects.
Released as op
flight 94756 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94756/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 94740
build-i386-rumpuserxen
On 05/25/2016 12:09 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support
> 32-bit default_ioport_* accesses"):
>> On 25.05.16 at 17:36, wrote:
>>> AccesSize parameter is optional when invoking the Register macro. If the
>>> AccessSize parameter is
On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > Existing solution does not allocate space for this symbol and any
> > references to acpi20, etc. does not make sense. As I saw any efi.*
> > references are protected by relevant ifs but we should no
flight 94767 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94767/
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
On Tue, May 24, 2016 at 09:46:13AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, wrote:
> > @@ -19,6 +20,28 @@
> > #define BOOT_PSEUDORM_CS 0x0020
> > #define BOOT_PSEUDORM_DS 0x0028
> >
> > +#define MB2_HT(name) (MULTIBOOT2_HEADER_TAG_##name)
> > +#define MB2_TT(name) (MULTIBO
Series:
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Jan Beulich writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support
32-bit default_ioport_* accesses"):
> On 25.05.16 at 17:36, wrote:
> > AccesSize parameter is optional when invoking the Register macro. If the
> > AccessSize parameter is
> > not supplied then the AccessSize field will
On Wed, May 25, 2016 at 4:31 PM, Tamas K Lengyel wrote:
>
> On May 25, 2016 05:27, "George Dunlap" wrote:
>>
>> On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel
>> wrote:
>> > Don't propagate altp2m changes from ept_set_entry for memshare as
>> > memshare
>> > already has the lock. We call altp2
On Tue, May 24, 2016 at 04:27:18PM +0100, Peter Maydell wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
>
> This commit was created with scripts/clean-includes.
>
> Signed-off-by: Peter Maydell
Acked-by: Anthony PERARD
--
>>> On 25.05.16 at 17:36, wrote:
> This is what the spec says:
>
> AccessSize evaluates to an 8-bit integer that specifies the size of data
> values used when accessing the
> address space as follows:
> 0 - Undefined (legacy)
> 1 - Byte access
> 2 - Word access
> 3 - DWord access
> 4 - QWord acce
On Wed, May 25, 2016 at 09:00:49AM -0600, Jan Beulich wrote:
> Correct the number of single byte NOPs we want to be replaced in case
> neither SMEP nor SMAP are available.
>
> Also simplify the expression adding these NOPs - at that location .
> equals .Lcr4_orig, and removing that part of the exp
The field 'foreign_id' is not used when the space is dev_mmio. As the
space is not yet part of the stable ABI, the field is marked as reserved
for future use.
The value should always be 0, other values will return -EOPNOTSUPP.
Signed-off-by: Julien Grall
---
Changes in v2:
- Return
>>> On 25.05.16 at 17:08, wrote:
> On 05/25/2016 10:35 AM, Ian Jackson wrote:
>> Ian Jackson writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>>> Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>>> On 25.05.16 at 17:34, wrote:
> On May 23, 2016 10:19 PM, Jan Beulich wrote:
>> >>> On 18.05.16 at 10:08, wrote:
>> > +unsigned long type,
>> > +int preemptible)
>> > {
>> > unsigned long nx, x, y = page->u.
Currently, XENMAPSPACE_dev_mmio maps MMIO regions using one of the most
restrictive memory attribute (Device-nGnRE).
Signed-off-by: Julien Grall
---
Changes in v2:
- s/Device_nGnRE/Device-nGnRE/ to match the spec
- Update the comment to mention the name for ARMv7.
---
xen/in
Hello all,
This series is based on the thread [1]. To allow future extension, the new
space dev_mmio should have all unused fields marked as reserved.
This series is candidate for Xen 4.7, the first patch ensure a clean ABI
for the new space which will allow future extension.
See in each patch f
On Mon, May 09, 2016 at 05:31:20PM +0100, Paul Durrant wrote:
> Since Xen will correctly handle accesses to unimplemented I/O ports (by
> returning all 1's for reads and ignoring writes) there is no need for
> QEMU to register backgroud I/O sections.
>
> This patch therefore adds checks to xen_io_
On Wed, May 25, 2016 at 03:51:23PM +0100, Wei Liu wrote:
> On Wed, May 25, 2016 at 03:04:40PM +0100, George Dunlap wrote:
> > On Mon, May 23, 2016 at 6:09 PM, Xen.org security team
> > wrote:
> > > RESOLUTION
> > > ==
> > >
> > > Applying the appropriate attached patch resolves this issue
On 05/25/2016 11:22 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>> IIUIC, the Linux/ACPICA patch makes ACPICA use correct field in ACPI's
>> Generic Address Structure (section 5.2.3.2 in the 6.0 spec). Before t
On May 25, 2016 05:27, "George Dunlap" wrote:
>
> On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel
wrote:
> > Don't propagate altp2m changes from ept_set_entry for memshare as
memshare
> > already has the lock. We call altp2m propagate changes once memshare
> > successfully finishes. Allow the ho
On May 23, 2016 10:19 PM, Jan Beulich wrote:
> >>> On 18.05.16 at 10:08, wrote:
>
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2463,11 +2463,12 @@ static int __put_page_type(struct page_info
> > *page, }
> >
> >
> > -static int __get_page_type(struct page_info *page, unsigned
Boris Ostrovsky writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
default_ioport_* accesses"):
> IIUIC, the Linux/ACPICA patch makes ACPICA use correct field in ACPI's
> Generic Address Structure (section 5.2.3.2 in the 6.0 spec). Before the
> patch it used register's bit_width and now i
...along with
https://git.kernel.org/cgit/linux/kernel/git/xen/tip.git/commit/?id=702f9260
which should also go into v4.4, IMO.
On Wed, May 25, 2016 at 4:17 AM, Ed Swierk wrote:
> On Tue, May 24, 2016 at 11:29 PM, Ingo Molnar wrote:
>> Do they apply, build and boot cleanly in that order on top
Hi Julien,
On 24.05.2016 22:05, Julien Grall wrote:
On 24/05/2016 14:39, Dirk Behme wrote:
Hi Julien,
Hello Dirk,
On 23.05.2016 22:15, Julien Grall wrote:
Hello Dirk,
is there a solution for
arm: domain 0 disables clocks which are in fact being used
http://bugs.xenproject.org/xen/bug/
On May 25, 2016 4:07 PM, Jan Beulich wrote:
> >>> On 25.05.16 at 08:41, wrote:
> > On May 24, 2016 4:22 PM, Jan Beulich wrote:
> >> >>> On 18.05.16 at 10:08, wrote:
> >> > static int device_power_down(void) {
> >> > -console_suspend();
> >> > +if ( console_suspend() )
> >> > +
On 05/25/2016 10:35 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>> Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
>> default_ioport_* accesses"):
>>> Recent changes in ACPICA (specifically
Correct the number of single byte NOPs we want to be replaced in case
neither SMEP nor SMAP are available.
Also simplify the expression adding these NOPs - at that location .
equals .Lcr4_orig, and removing that part of the expression fixes a
bogus ".space or fill with negative value, ignored" war
>>> On 25.05.16 at 16:43, wrote:
> I could say:
>
> "ARM only; the region will be mapped in Stage-2 using the memory
> attribute 'Device-nGnRE' (previously named 'Device' on ARMv7)".
SGTM
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:
On Wed, May 25, 2016 at 03:04:40PM +0100, George Dunlap wrote:
> On Mon, May 23, 2016 at 6:09 PM, Xen.org security team
> wrote:
> > RESOLUTION
> > ==
> >
> > Applying the appropriate attached patch resolves this issue.
> >
> > The patches adopt a simple and rather crude approach which is
flight 94764 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94764/
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
Hi Jan,
On 25/05/16 14:14, Jan Beulich wrote:
On 25.05.16 at 13:41, wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -220,7 +220,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
#define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap only.
Ian Jackson writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
default_ioport_* accesses"):
> Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
> > Recent changes in ACPICA (specifically, Linux commit 66b1ed5aa8dd ("ACPICA:
> > ACPI 2.
On Wed, May 25, 2016 at 03:31:19PM +0100, Wei Liu wrote:
> On Wed, May 25, 2016 at 03:28:50PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [PATCH for-4.7] docs: update xl manpage about
> > {block,network}-attach command"):
> > > On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
>
The following lockdep dump occurs whenever I destroy an HVM domain, on
Linux 4.4 Dom0 with CONFIG_XEN_BALLOON=n on recent stable Xen 4.5.
Any clues whether this is a real potential deadlock, or how to silence
it if not?
==
[ INFO: RECLAIM_FS-saf
Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
default_ioport_* accesses"):
> Recent changes in ACPICA (specifically, Linux commit 66b1ed5aa8dd ("ACPICA:
> ACPI 2.0, Hardware: Add access_width/bit_offset support for
> acpi_hw_write()") result in guests issuing 32-bit acces
On Wed, May 25, 2016 at 03:28:50PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.7] docs: update xl manpage about
> {block,network}-attach command"):
> > On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
> ...
> > > But the vdev field specifies more than just the device
Wei Liu writes ("Re: [PATCH for-4.7] docs: update xl manpage about
{block,network}-attach command"):
> On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
...
> > But the vdev field specifies more than just the device type. So I
> > think this is wrong.
>
> I guess to make things simple
Hi Jan,
On 25/05/16 14:12, Jan Beulich wrote:
On 25.05.16 at 13:41, wrote:
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1143,6 +1143,10 @@ int xenmem_add_to_physmap_one(
break;
}
case XENMAPSPACE_dev_mmio:
+/* The field 'foreign_domid' is reserved for futur
Hi Edgar,
On 25/05/16 14:29, Edgar E. Iglesias wrote:
On Tue, May 24, 2016 at 08:44:41PM +0100, Julien Grall wrote:
Looking a little closer, the place where the generic list of matches and
attributes doesn't work well is when trying to deal with the no-memory-wc
property available only in mmio-s
Wei Liu writes ("[PATCH for-4.7] docs: update xl manpage about
{block,network}-attach command"):
> State that only attaching PV interface is supported.
...
> Create a new virtual block device. This will trigger a hotplug event
> -for the guest.
> +for the guest. Note that only attaching PV block
On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] docs: update xl manpage about
> {block,network}-attach command"):
> > State that only attaching PV interface is supported.
> ...
> > Create a new virtual block device. This will trigger a hotplug even
Hi Wei,
On 25/05/16 03:10, Wei Chen wrote:
In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1.
Well, technically the bit is unamed for ARM64. So I would make clear
that the name is from AArch32. Something along:
"The bit 31 (former bit Multiprocessing extensions bit in AArc
Hi Wei,
Title: "Fix the MPIDR_HWID_MASK value for ARM64".
On 25/05/16 03:09, Wei Chen wrote:
Current MPIDR_HWID_MASK is using the bit definition of ARM32 MPIDR.
s/Current/Currently/
This value is not correct while Xen is running on ARM64.
I think s/while/when/
Now, we add a correct valu
On Wed, May 25, 2016 at 07:12:30AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 13:41, wrote:
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -1143,6 +1143,10 @@ int xenmem_add_to_physmap_one(
> > break;
> > }
> > case XENMAPSPACE_dev_mmio:
> > +/* The f
On Mon, May 23, 2016 at 6:09 PM, Xen.org security team wrote:
> RESOLUTION
> ==
>
> Applying the appropriate attached patch resolves this issue.
>
> The patches adopt a simple and rather crude approach which is
> effective at resolving the security issue in the context of a Xen
> device mo
Hi Wei,
On 25/05/16 03:09, Wei Chen wrote:
The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to gene
Hi Wei,
On 25/05/16 03:09, Wei Chen wrote:
The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or
from CPU node of DT. Currently, the cpu_logical_map is using the u32 as
its variable type. It can work properly while Xen is running on ARM32,
because the hardware ID is 32-bits. Whi
flight 94761 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94761/
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 Wed, May 25, 2016 at 09:37:09AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> > The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> > virtual_region to do bug, symbol, and (x86) exception tables lookup."
> > has intro
On Wed, May 25, 2016 at 02:23:56PM +0100, Wei Liu wrote:
> This ensures buf is always valid when it is passed to strtok_r.
>
> CID: 1291936
>
> Signed-off-by: Wei Liu
Pushed. Thanks everyone.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
Hi Wei,
Please try to send all the patches with the cover letter as references.
git send-email should do it if you send all the patches at once.
This is really helpful to with mail client supporting thread.
Regards,
On 25/05/16 03:08, Wei Chen wrote:
In ARM64 the MPIDR register is mapped to
On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> virtual_region to do bug, symbol, and (x86) exception tables lookup."
> has introduced virtual_region. The call to initialize those regions is
> made in init_tr
On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> virtual_region to do bug, symbol, and (x86) exception tables lookup."
> has introduced virtual_region. The call to initialize those regions is
> made in init_tr
On Wed, May 25, 2016 at 02:33:41PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] xl: use xstrdup in cpurange_parse"):
> > This ensures buf is always valid when it is passed to strtok_r.
> >
> > CID: 1291936
> >
> > Signed-off-by: Wei Liu
>
> Acked-by: Ian Jackson
>
> > This is
Wei Liu writes ("[PATCH for-4.7] xl: use xstrdup in cpurange_parse"):
> This ensures buf is always valid when it is passed to strtok_r.
>
> CID: 1291936
>
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
> This is a backport candidate.
Really ? malloc failing is vanishingly rare in practice n
On 25/05/16 14:23, Wei Liu wrote:
> This ensures buf is always valid when it is passed to strtok_r.
>
> CID: 1291936
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Jackson
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On Tue, May 24, 2016 at 08:44:41PM +0100, Julien Grall wrote:
> Hi Edgar,
>
> On 23/05/2016 16:42, Edgar E. Iglesias wrote:
> >On Mon, May 23, 2016 at 04:13:53PM +0100, Julien Grall wrote:
> >>On 23/05/16 15:02, Edgar E. Iglesias wrote:
> >>>On Mon, May 23, 2016 at 02:02:39PM +0100, Julien Grall w
Hello Peng,
On 25/05/16 13:37, Peng Fan wrote:
On Wed, May 25, 2016 at 10:10:11AM +0800, Wei Chen wrote:
In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1.
So, the value check for this bit is no longer necessary on ARM64.
From ARM DDI0487A.G, I found the U bit for MPIDR_EL1
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, May 24, 2016 10:47 PM
> To: Wu, Feng ; Jan Beulich
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> k...@xen.org
Should be "multiple times" in title.
On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> virtual_region to do bug, symbol, and (x86) exception tables lookup."
> has introduced virtual_region. The call to initial
Wei Liu writes ("[PATCH OSSTEST] make-flight: don't create ovmf tests for
seabios branch"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
I have queued this in a branch that will see it pushed at some point.
Thanks,
Ian.
___
Xen-devel mailing list
1 - 100 of 145 matches
Mail list logo
