flight 94817 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 94785
build-amd64-libvirt
+Wei
Thanks,
-Xudong
> -Original Message-
> From: Zhang, PengtaoX
> Sent: Friday, May 27, 2016 1:07 PM
> To: Xen-devel
> Cc: Hao, Xudong ; Zhang, Haozhong
>
> Subject: [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to
> inject MSR"
>
> Bug detailed description:
> -
flight 94808 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
94743
Regressions whic
On 05/27/16 13:07, Zhang, PengtaoX wrote:
> Bug detailed description:
>
> On haswell-ex and boardwell-ex server, testing the xen's LLC, MEM, UCNA,
> show error message:"Failed to inject MSR: Invalid argument".
>
> Environment :
>
> HW: haswell-ex/boardwell-ex
>
To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate
first level page table, if there is a big chunk memory (ie, >512GB).
So, need to make sure boot pages are ready before setup xenheap mappings.
Signed-off-by: Peng Fan
Cc: Julien Grall
Cc: Stefano Stabellini
---
xen/arch/ar
Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv
Signed-off-by: Peng Fan
Cc: Julien Grall
Cc: Stefano Stabellini
---
xen/arch/arm/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 09ff1ea..dcb23b7 100644
--- a/xen/arch/arm
flight 94814 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94814/
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
Bug detailed description:
On haswell-ex and boardwell-ex server, testing the xen's LLC, MEM, UCNA, show
error message:"Failed to inject MSR: Invalid argument".
Environment :
HW: haswell-ex/boardwell-ex
Xen: Xen 4.7.0 RC3
Dom0: Linux 4.6.0
Reproduce steps:
flight 94802 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 94789
Regressions which ar
Hi,
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Friday, May 27, 2016 12:56 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access
> bit width support
>
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
> Boris Ostrovsky 05/25/16 9:17
> PM >>>
> >> On 05
Hi,
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky
> Sent: Thursday, May 26, 2016 3:17 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit
> width support
>
> On 05/05/2016 12:58 AM, Lv Zheng wrote:
> >
Hi,
Because the boosting CPU and memory resources on server, Xen users are allowed
and actually do create lots of vdisk and vnic, e.g., 6 vnic, 20 vdisk and 24
vcpu (the number of vnic queue is proportional to the number of vcpu assigned
to guest), and this requires the administrator to increase t
On 2016年05月26日 16:42, Dong, Eddie wrote:
> If enabling virtual Q35 solves the problem, it has the advantage: When more
> and more virtual IOMMU feature comes (likely), we can reuse the KVM code for
> Xen.
> How big is the effort for virtual Q35?
I think the most effort are to rebuild all ACPI ta
flight 94806 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94806/
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
Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
Dom0 dynamically) causing dead loop inside the spinlock function.
Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
that has already held by calling CPU leads to deadlock. This happens
whenever dom0 does writes to
The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers to set
baudrate. So, extend the driver probe() to handle SBSA interface
types and set the baudrate to 115200 for SBSA interfaces.
Signed-off-by: Shanker Donthineni
---
https://si
flight 94796 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94796/
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-
The current driver probe fails on hardware which has GICv4 version,
even though it is fully compatible to GICv3. This patch fixes the
issue by registering the same probe function for GICv4 hardware.
Signed-off-by: Shanker Donthineni
---
xen/arch/arm/gic-v3.c | 13 +
xen/include/a
flight 94800 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94800/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start.2 fail REGR. vs. 94765
Tests which did not
On 05/26/2016 12:55 PM, Boris Ostrovsky wrote:
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
> Boris Ostrovsky 05/25/16 9:17 PM >>>
>>> On 05/05/2016 12:58 AM, Lv Zheng wrote:
+static u8
+acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
max_bit_width)
+{
>>
flight 94795 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94795/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 15 guest-start.2 fail REGR. vs. 94743
Regressions which a
flight 94801 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94801/
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
flight 94789 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94789/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail in 94780 pass in 94789
test-amd64-amd64-xl-qemuu-debianhv
flight 94799 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94799/
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 94797 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94797/
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
On Wed, May 25, 2016 at 9:58 AM, David Vrabel wrote:
> This occurs in dom0? Or the guest that's being destroyed?
The lockdep warning comes from dom0 when the HVM guest is being destroyed.
> It's a bug but...
>
>> ==
>> [ INFO: RECLAIM_FS-safe
Hi Feng,
On Thu, 2016-05-26 at 21:39 +0800, Feng Wu wrote:
> Feng Wu (4):
> VMX: Properly handle pi when all the assigned devices are removed
> VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
> VMX: Assign the right value to 'NDST' field in a concern case
> VMX: fixup PI descr
On 05/26/2016 12:26 PM, Jan Beulich wrote:
Boris Ostrovsky 05/25/16 9:17 PM >>>
>> On 05/05/2016 12:58 AM, Lv Zheng wrote:
>>> +static u8
>>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
>>> max_bit_width)
>>> +{
>>> +u64 address;
>>> +
>>> +if (!reg->access_wid
On Thu, May 26, 2016 at 05:10:52PM +0100, Anthony PERARD wrote:
> On Thu, May 26, 2016 at 04:21:56PM +0100, Wei Liu wrote:
> > From: Ian Jackson
> >
> > Each time round the main loop, we now fstat stderr. If it is too big,
> > we dup2 /dev/null onto it. This is not a very pretty patch but it is
>>> Boris Ostrovsky 05/25/16 9:17 PM >>>
>On 05/05/2016 12:58 AM, Lv Zheng wrote:
>> +static u8
>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
>> max_bit_width)
>> +{
>> +u64 address;
>> +
>> +if (!reg->access_width) {
>> +/*
>> + * Detect old regist
On Thursday, May 26, 2016 11:57 PM, Jan Beulich wrote:
> >>> "Xu, Quan" 05/26/16 12:38 PM >>>
> >On May 25, 2016 4:30 PM, Jan Beulich wrote:
> >> The patch getting too large is easy to deal with: Split it at a
> >> reasonable boundary.
> >I recall your suggestion: top one first, then low level o
On May 26, 2016 04:40, "George Dunlap" wrote:
>
> On 26/05/16 04:55, Tamas K Lengyel wrote:
> > 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
On Thu, 2016-05-26 at 13:03 +, Wu, Feng wrote:
> > On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> > >
> > > The patch fixing this issue has already been sent to upstream.
> > >
> > > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> > > blocking list "
> > >
> > > v
On Thu, 2016-05-26 at 10:30 +0900, 조현권 wrote:
> Hi
>
Hi,
> I am studying xen 4.6.0 version now and wonder the usage of spinlock
> which is located in free_heap_pages(xen/common/page_alloc. c)
> As its memory setup is ahead of multicore initialization, spinlock
> seems to be unnecessary during boot
On Thu, May 26, 2016 at 04:21:56PM +0100, Wei Liu wrote:
> From: Ian Jackson
>
> Each time round the main loop, we now fstat stderr. If it is too big,
> we dup2 /dev/null onto it. This is not a very pretty patch but it is
> very simple, easy to see that it's correct, and has a low risk of
> col
On Thu, May 26, 2016 at 04:36:57PM +0100, George Dunlap wrote:
> On Thu, May 26, 2016 at 4:21 PM, Wei Liu wrote:
> > From: Ian Jackson
> >
> > Each time round the main loop, we now fstat stderr. If it is too big,
> > we dup2 /dev/null onto it. This is not a very pretty patch but it is
> > very
>>> "Xu, Quan" 05/26/16 12:38 PM >>>
>On May 25, 2016 4:30 PM, Jan Beulich wrote:
>> The patch getting too large is easy to deal with: Split it at a reasonable
>> boundary.
>
>If I follow the below rule, I need to merge most of patches into this one. I
>can't find a reasonable boundary.
As befo
On Thu, May 26, 2016 at 4:21 PM, Wei Liu wrote:
> From: Ian Jackson
>
> Each time round the main loop, we now fstat stderr. If it is too big,
> we dup2 /dev/null onto it. This is not a very pretty patch but it is
> very simple, easy to see that it's correct, and has a low risk of
> collateral d
On Thu, May 26, 2016 at 04:47:59PM +0100, Wei Liu wrote:
> On Thu, May 26, 2016 at 04:41:53PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for
> > QEMU"):
> > > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
> > > explicitly set
Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU"):
> XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
> explicitly set the limit in libxl for 4.7.
...
> +unsigned long limit = 0;
> +const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT");
> +
> +limi
Wei Liu writes ("[PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk
DoS in Xen setups"):
> The limit is 1Mby by default but can be adjusted by setting a new
> environment variable.
>
> This fixes CVE-2014-3672.
>
> Signed-off-by: Ian Jackson
> Tested-by: Ian Jackson
>
> Set the de
>>> Suravee Suthikulanit 05/25/16 9:01 PM >>>
>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()
>>>
>>> "Xu, Quan" 05/26/16 3:42 AM >>>
>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,
>> >> > +
On Thu, May 26, 2016 at 04:41:53PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU"):
> > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
> > explicitly set the limit in libxl for 4.7.
> ...
> > +unsigned long limit = 0;
>
>>> Suravee Suthikulanit 05/25/16 8:52 PM >>>
>On 5/23/2016 3:23 AM, Paul Durrant wrote:
>> > From: suravee.suthikulpa...@amd.com
>> > Sent: 22 May 2016 00:43
>>> > guest_iommu_init tries to register mmio handler before HVM domain
>>> > is initialized. This cause registration to silently failing.
On 26/05/16 15:05, Boris Ostrovsky wrote:
> On 05/26/2016 06:24 AM, David Vrabel wrote:
>>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>>> pte_t pte)
>>> * page tables for mapping the p2m list, too, and page tables MUST be
>>> * mapped read-only.
>>> */
>>>
From: Ian Jackson
Each time round the main loop, we now fstat stderr. If it is too big,
we dup2 /dev/null onto it. This is not a very pretty patch but it is
very simple, easy to see that it's correct, and has a low risk of
collateral damage.
The limit is 1Mby by default but can be adjusted by
XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We
explicitly set the limit in libxl for 4.7.
Introduce a function for setting the environment variable and call it in
the right places.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_dm.c | 33 ++---
1 file
Two patches for XSA-180 for Xen 4.7 release.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hello,
On 26/05/2016 12:07, Xu, Quan wrote:
On May 26, 2016 9:31 AM, 조현권 wrote:
I am studying xen 4.6.0 version now and wonder the usage of spinlock which is
located in free_heap_pages(xen/common/page_alloc. c)
As its memory setup is ahead of multicore initialization, spinlock seems to be
un
Hi all
Xen 4.7 rc4 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.7.0-rc4
For you convenience there is also tarball at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc4/xen-4.7.0-rc4.tar.gz
And the signature is at:
http://bits.xensource.com/oss-xen/release/
On May 26, 2016 6:38 PM, Xu, Quan wrote:
> On May 25, 2016 4:30 PM, Jan Beulich wrote:
> > The patch getting too large is easy to deal with: Split it at a
> > reasonable boundary.
>
> Jan,
> If I follow the below rule, I need to merge most of patches into this one. I
> can't
> find a reasonable
On 05/26/2016 06:24 AM, David Vrabel wrote:
>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>> pte_t pte)
>> * page tables for mapping the p2m list, too, and page tables MUST be
>> * mapped read-only.
>> */
>> -pfn = pte_pfn(pte);
>> +pfn = (pte & P
When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it. And we need to
carefully handle the situation that calling to vmx_vcpu_block() and
cpu offline occur concurrently.
Signed-off-by: Feng Wu
---
xen/arch/x86/hvm/vmx/vmcs.c|
Normally, in vmx_cpu_block() 'NDST' filed should have the same
value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending
on whether x2apic is enabled. However, in the following scenario,
'NDST' has different value:
'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
other
The current VT-d PI related code may operate incorrectly in the
following scenarios:
1. When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next
This patch handles some concern case when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again.
We should remove the vCPU from the per-cpu blocking list
if it is going to be destroyed.
Signed-off-by: Feng Wu
---
xen/arch/x86/hvm/vmx/vmx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 65f5288..b01128a 100644
--- a/xen/arch/
Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq:
Support 32-bit default_ioport_* accesses"):
> On 05/25/2016 12:09 PM, Ian Jackson wrote:
> > I think this question can only be resolved de jure by looking at what
> > previous ACPI specifications (before this AccessSize field
On Thu, May 26, 2016 at 11:44:15AM +0100, Andrew Cooper wrote:
> On 26/05/16 03:03, Chao Peng wrote:
> > 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.
flight 94790 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94790/
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
On Thu, May 26, 2016 at 01:03:53PM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Thursday, May 26, 2016 6:27 PM
> > To: Wu, Feng
> > Cc: Hao, Xudong ; Xen-devel > de...@lists.xenproject.org>; Wei Liu
> > Subject: Re: [BUG] Xe
On 05/24/2016 09:56 AM, Doug Goldstein wrote:
Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
enabled.
Signed-off-by: Doug Goldstein
Reviewed-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by:
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, May 26, 2016 6:27 PM
> To: Wu, Feng
> Cc: Hao, Xudong ; Xen-devel de...@lists.xenproject.org>; Wei Liu
> Subject: Re: [BUG] Xen panic with VT-d PI
>
> On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng
flight 94784 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94784/
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-
On 26/05/16 09:29, Lan Tianyu wrote:
> Hi All:
> We try pushing virtual iommu support for Xen guest and there are some
> features blocked by it.
>
> Motivation:
> ---
> 1) Add SVM(Shared Virtual Memory) support for Xen guest
> To support iGFX pass-through for SVM enabled devices
On May 26, 2016 9:31 AM, 조현권 wrote:
> I am studying xen 4.6.0 version now and wonder the usage of spinlock which is
> located in free_heap_pages(xen/common/page_alloc. c)
> As its memory setup is ahead of multicore initialization, spinlock seems to
> be unnecessary during booting because it uses
On 24/05/16 01:04, Muhammad Falak R Wani wrote:
> Replace explicit computation of vma page count by a call to
> vma_pages().
Applied to for-linus-4.8, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 26/05/16 03:03, Chao Peng wrote:
> 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
Reviewed-by: Andrew Cooper
Wei: This
On 25/05/16 16:00, 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 expression fixes a
> bogus
On 26/05/16 04:55, Tamas K Lengyel wrote:
> 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_ac
On May 25, 2016 4:30 PM, Jan Beulich wrote:
> The patch getting too large is easy to deal with: Split it at a reasonable
> boundary.
Jan,
If I follow the below rule, I need to merge most of patches into this one. I
can't find a reasonable boundary.
I recall your suggestion: top one first, then
On 11/05/16 14:07, Arnd Bergmann wrote:
> A bugfix patch for the xen balloon driver introduced a forward
> declaration for a static function that is conditionally compiled,
> causing a warning if only the declaration but not the definition
> are there:
>
> drivers/xen/balloon.c:154:13: error: 'rel
>>> @@ -42,11 +38,12 @@ UINT64 __read_mostly efi_boot_remain_var_store_size;
>>> UINT64 __read_mostly efi_boot_max_var_size;
>>>
>>> struct efi __read_mostly efi = {
>>> - .acpi = EFI_INVALID_TABLE_ADDR,
>>> - .acpi20 = EFI_INVALID_TABLE_ADDR,
>>> - .mps= EFI_INVALID_TABLE_ADDR,
>>>
On 10/05/16 10:27, Ross Lagerwall wrote:
> Fix a declared-but-not-defined warning when building with
> XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
> commit dfd74a1edfab
> ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE").
Applied to for-linus-4.7b, thanks.
I hav
>>> @@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER
>>> /
>>> .long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
>>> multiboot1_header_end:
>>>
>>> +/*** MULTIBOOT2 HEADER /
>>> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-
On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote:
> 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.
>
I just went through that thread. There are some open questi
On 17/05/16 16:11, David Vrabel wrote:
> On 11/05/16 11:16, David Vrabel wrote:
>>
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it up afterwards.
>
> Kevin, can you try this patch.
>
> David
>
> 8<-
> x86/xe
On Thu, 26 May 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 16/05/2016 12:11, Stefano Stabellini wrote:
> > On Wed, 11 May 2016, Arnd Bergmann wrote:
> > > A bugfix patch for the xen balloon driver introduced a forward
> > > declaration for a static function that is conditionally compiled,
> > >
On 26/05/16 03:50, suravee.suthikulpa...@amd.com wrote:
> 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
Hi Stefano,
On 16/05/2016 12:11, Stefano Stabellini wrote:
On Wed, 11 May 2016, Arnd Bergmann wrote:
A bugfix patch for the xen balloon driver introduced a forward
declaration for a static function that is conditionally compiled,
causing a warning if only the declaration but not the definition
flight 94787 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94787/
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
flight 94780 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94780/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 94756
build-amd64-rumpuserxen
Hi Stefano,
On 26/05/2016 10:18, Stefano Stabellini wrote:
On Wed, 25 May 2016, Julien Grall wrote:
On 25/05/16 14:14, Jan Beulich wrote:
Also - is Device_nGnRE a term uniform between ARM32 and ARM64?
Actually it should be Device-nGnRE to match with the spec. This has been
introduced on Armv
On Wed, 25 May 2016, Julien Grall wrote:
> 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);
> > > #
On Wed, 25 May 2016, Paolo Bonzini wrote:
> > 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 back
On 25/05/2016 16:10, Dirk Behme wrote:
Hi Julien,
Hello Dirk,
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
If enabling virtual Q35 solves the problem, it has the advantage: When more and
more virtual IOMMU feature comes (likely), we can reuse the KVM code for Xen.
How big is the effort for virtual Q35?
Thx Eddie
> -Original Message-
> From: Lan, Tianyu
> Sent: Thursday, May 26, 2016 4:30 PM
>
Hi
I am studying xen 4.6.0 version now and wonder the usage of spinlock which
is located in free_heap_pages(xen/common/page_alloc. c)
As its memory setup is ahead of multicore initialization, spinlock seems to
be unnecessary during booting because it uses only single core
spinlock looks required
On 24/05/16 16:06, Dario Faggioli wrote:
> which was overlooked in 779511f4bf5ae ("sched: avoid
> races on time values read from NOW()").
>
> Reported-by: Jan Beulich
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
> ---
> Cc: Meng Xu
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Wei
Hi All:
We try pushing virtual iommu support for Xen guest and there are some
features blocked by it.
Motivation:
---
1) Add SVM(Shared Virtual Memory) support for Xen guest
To support iGFX pass-through for SVM enabled devices, it requires
virtual iommu support to emulate relat
Hi Doug,
On 24/05/2016 14:56, Doug Goldstein wrote:
Convert the 'lock_profile' option to Kconfig as CONFIG_LOCK_PROFILE.
Signed-off-by: Doug Goldstein
Reviewed-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
Regards,
--
Julien Grall
Hi Doug,
On 24/05/2016 14:56, Doug Goldstein wrote:
Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
enabled.
Signed-off-by: Doug Goldstein
Reviewed-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
Revie
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 25 May 2016 21:58
> To: Paul Durrant; zhigang.x.w...@oracle.com
> Cc: Wei Liu; Olaf Hering; Stefano Stabellini; Andrew Cooper; xen-
> de...@lists.xen.org; Anthony Perard
> Subject: Re: [Xen-devel] liv
> -Original Message-
> From: Suravee Suthikulanit [mailto:suravee.suthikulpa...@amd.com]
> Sent: 25 May 2016 19:52
> To: Paul Durrant; xen-devel@lists.xen.org; jbeul...@suse.com; George
> Dunlap
> Cc: Keir (Xen.org)
> Subject: Re: [PATCH v3 3/3] AMD IOMMU: Check io_handler before
> register
On 05/26/16 09:15, Egger, Christoph wrote:
> On 26/05/16 03:07, Haozhong Zhang wrote:
> > 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 i
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. While Xen is running on ARM64, the
hardware ID ex
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 generate correct
mask for level3.
Signed-off-by:
In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
as 32-bit register.
We have to provide correct accessing to this register to avoid
unexpected issues that is caused by incorrect MPIDR value.
Wei Chen (4):
xe
Currently, MPIDR_HWID_MASK is using the bit definition of AArch32 MPIDR.
From ARMv8 ARM we can see there are 4 levels of affinity on AArch64
whilst AArch32 has only 3. So, this value is not correct when Xen is
running on AArch64.
Now, we use the value 0xff00ff for this macro on AArch64. But ne
1 - 100 of 103 matches
Mail list logo
