flight 139247 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139247/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 138883
test-arm64-arm64-exam
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org
On 22.07.19 21:20, Andrew Cooper wrote:
a.k.a. (at least in this form) Andrew's "work which might be offloadable to
someone else" list.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
CC
On 22.07.19 23:37, Andrew Cooper wrote:
On 22/07/2019 22:21, Stefano Stabellini wrote:
Hi Juergen,
We are working on a technology to limit cache interference between
guests running on the same SoC. It works well, but as a consequence, all
memory allocations are 4K only: higher granularities (2M
Hi Russell, Stefano
> Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Any comments?
>
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So to ARM64, need use __GFP_DMA32.
>
>
flight 139250 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139250/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 133ea4fff43567cfeae6c032ac202656c6108db3
baseline version:
freebsd 37af220308d
On 23/07/2019 00:50, Johnson, Ethan wrote:
> Hi all,
>
> I'm interested in using Xen as a research platform for enforcing novel memory
> protection schemes on hypervisors and guests. Specifically, I'm looking to do
> this in an environment containing PVH(v2) and potentially HVM guests.
>
> To kno
flight 139242 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139242/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrat
Hi all,
I'm interested in using Xen as a research platform for enforcing novel memory
protection schemes on hypervisors and guests. Specifically, I'm looking to do
this in an environment containing PVH(v2) and potentially HVM guests.
To know what my options are for this, I need to know where th
On 23/07/2019 00:36, Roman Shaposhnik wrote:
> Hi Everyone!
>
> Thanks a million for an extremely quick turnaround. I am in my lab
> again next to the box in question.
>
> Should I go ahead and test the latest patch or wait for the official
> one to be submitted?
>
> Thanks,
> Roman.
Use this patc
Hi Everyone!
Thanks a million for an extremely quick turnaround. I am in my lab
again next to the box in question.
Should I go ahead and test the latest patch or wait for the official
one to be submitted?
Thanks,
Roman.
On Mon, Jul 22, 2019 at 8:22 AM Roger Pau Monné wrote:
>
> On Mon, Jul 22,
On 07/22/19 21:45, Laszlo Ersek wrote:
> we place the 32-bit PCI IOMMU aperture based on [...]
Do I get a medal for this hugely confusing typo? :)
In earnest, I'm sorry about it -- my comment had nothing to do with
"IOMMU"; I meant "MMIO". (At least I got it right in the rest of the email.)
Sor
flight 139240 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
test-amd64-amd64-xl-
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to
avoid TLB incoherency.
A branch in the success case can be avoided by inverting the branch
condition. At the same time, remove a pointless comment as Xen can only
run at Hypervisor Mode.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
Changes in v2:
At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cache will be bypassed when zeroing the BSS section.
On Arm64, per the Image protocol [1], the state of the cache for BSS region
is not known because it is not part of the "loaded kernel image".
On Arm32, the
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
setup_fixmap() will setup the fixmap in the boot page tables in order to
use earlyprintk and also update the register r11 holding the address to
the UART.
However, secondary CPUs are not using earlyprintk between turning the
MMU on and switching to the runtime page table. So setting up the
fixmap
The current implementation of the macro PRINT will clobber r14/lr. This
means the user should save r14 if it cares about it.
Follow-up patches will introduce more use of PRINT in places where lr
should be preserved. Rather than requiring all the user to preserve lr,
the macro PRINT is modified to
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid using conditional instruction and make the call
clearer, launch() is reworked to take in parameters the entry point and its
arguments.
The current implementation of the macro PRINT will clobber x30/lr. This
means the user should save lr if it cares about it.
Follow-up patches will introduce more use of PRINT in place where lr
should be preserved. Rather than requiring all the users to preserve
lr, the macro PRINT is modified to s
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/arm32/head.S b/x
Anything executed after the label common_start can be executed on all
CPUs. However most of the instructions executed between the label
common_start and init_uart are not executed on the boot CPU.
The only instructions executed are to lookup the CPUID so it can be
printed on the console (if earlyp
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to
avoid TLB incoherency.
A branch in the success case can be avoided by inverting the branch
condition. At the same time, remove a pointless comment as Xen can only
run at EL2.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
--
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
Changes in v2:
- x2 and x3 are also clobbers. Update the comment accordingly
- s/ID/1:1/
---
xen/arch/arm/arm64/head.S | 7 +++
1 file changed, 7 insertions(+)
diff -
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
switching between two differents set of page-tables without turning off
the MMU. Turning off the MMU is imp
Anything executed after the label common_start can be executed on all
CPUs. However most of the instructions executed between the label
common_start and init_uart are not executed on the boot CPU.
The only instructions executed are to lookup the CPUID so it can be
printed on the console (if earlyp
The return address of a function is always stored in x30. For convenience,
introduce a register alias so "lr" can be used in assembly.
This is defined in asm-arm/arm64/macros.h to allow all assembly files
to use it.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
x
Adjust the coding style used in the comments within cpu_init(). Take the
opportunity to alter the early print to match the function name.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
Changes in v2:
- We don't clobber
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e
On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed. It also means that x26 does not need to be set for secondary
CPU.
Note that we will need to keep x26 around for the boot CPU as BSS should
not be rese
Arm64 provides instructions to load a PC-relative address, but with some
limitations:
- adr is enable to cope with +/-1MB
- adrp is enale to cope with +/-4GB but relative to a 4KB page
address
Because of that, the code requires to use 2 instructions to load any Xen
symbol. To make the c
On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Fix typo in the commit title
- Add Stefano's reviewed-by
---
xen/arch/arm/arm64/head
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate function
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate function
Document the behavior and the main registers usage within the function.
Note that r6 is now only used within the function, so it does not need
to be part of the common register.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 30 +
At the moment, TTBR_EL2 is setup in create_page_tables(). This is fine
as it is called by every CPUs.
However, such assumption may not hold in the future. To make change
easier, the TTBR_EL2 is not setup in enable_mmu().
Take the opportunity to add the missing isb() to ensure the TTBR_EL2 is
seen
The current boot code is using the pattern ldr rX, =... to move an
immediate constant into a 32-bit register.
This pattern implies to load the immediate constant from a literal pool,
meaning a memory access will be performed.
The memory access can be avoided by using movw/movt instructions.
A ne
setup_fixmap() will setup the fixmap in the boot page tables in order to
use earlyprintk and also update the register x23 holding the address to
the UART.
However, secondary CPUs are not using earlyprintk between turning the
MMU on and switching to the runtime page table. So setting up the
fixmap
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid a branch for the decision and make the code clearer,
launch() is reworked to take in parameters the entry point and its
arguments.
La
At the moment, the user should save r14/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the value to register r0
if it was stored in a different register.
For convenience, a new macro
Hi all,
This is part of the boot/memory rework for Xen on Arm, but not sent as
MM-PARTx as this is focusing on the boot code.
Similar to the memory code, the boot code is not following the Arm Arm and
could lead to memory corruption/TLB conflict abort. I am not aware
of any platforms where Xen fa
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
switching between two differents set of page-tables without turning off
the MMU. Turning off the MMU is imp
At the moment, HTTBR is setup in create_page_tables(). This is fine as
it is called by every CPUs.
However, such assumption may not hold in the future. To make change
easier, the HTTBR is not setup in enable_mmu().
Take the opportunity to add the missing isb() to ensure the HTTBR is
seen before t
Adjust the coding style used in the comments within create_pages_tables()
Lastly, document the behavior and the main registers usage within the
function. Note that x25 is now only used within the function, so it does
not need to be part of the common register.
Signed-off-by: Julien Grall
---
xe
At the moment, the user should save x30/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the value to register x0
if it was stored in a different register.
For convenience, a new macro
On 22/07/2019 22:21, Stefano Stabellini wrote:
> Hi Juergen,
>
> We are working on a technology to limit cache interference between
> guests running on the same SoC. It works well, but as a consequence, all
> memory allocations are 4K only: higher granularities (2M, 1G) do not
> work at all.
>
> On
Hi Juergen,
We are working on a technology to limit cache interference between
guests running on the same SoC. It works well, but as a consequence, all
memory allocations are 4K only: higher granularities (2M, 1G) do not
work at all.
One of the issues I am seeing after upgrading dom0 kernel is th
flight 139261 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139261/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 07/22/19 16:53, Anthony PERARD wrote:
> On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
>> On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
>>> When running as a Xen PVH guest, there is no CMOS to read the memory
>>> size from. Rework GetSystemMemorySize(Below|Ab
On Mon, 22 Jul 2019, Andrew Cooper wrote:
> On 22/07/2019 03:57, Kevin Buckley wrote:
>> bash-5.0# /usr/lib/xen/bin/pygrub --debug --offset=1048576
>> --list-entries /dev/vg_xen_vbds/lv_4g_02
>> Using to parse /boot/grub/grub.cfg
>> Traceback (most recent call last):
>> File "/usr/lib/xen/bin/p
On Mon, Jul 22, 2019 at 07:27:09PM +, Nadav Amit wrote:
> > On Jul 22, 2019, at 12:14 PM, Peter Zijlstra wrote:
> > But then we can still do something like the below, which doesn't change
> > things and still gets rid of that dual function crud, simplifying
> > smp_call_function_many again.
On 07/22/19 15:49, Anthony PERARD wrote:
> On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monné wrote:
>> On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
>>> ACPI Timer does not work in a PVH guest, but local APIC works on both
>>
>> This is not accurate. It's not that the ACPI
> On Jul 22, 2019, at 12:14 PM, Peter Zijlstra wrote:
>
> On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
>> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask
>> *cpumask,
>> * doing a speculative memory access.
>> */
>> if (info->freed_tables) {
a.k.a. (at least in this form) Andrew's "work which might be offloadable to
someone else" list.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
CC: Lars Kurth
CC: Paul Durrant
CC: Roger
On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask
> *cpumask,
>* doing a speculative memory access.
>*/
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, flush_tlb_func
On 07/19/19 18:42, Anthony PERARD wrote:
> On Fri, Jul 05, 2019 at 02:21:13PM +0200, Laszlo Ersek wrote:
>> The patches on the list are malformed. They have
>>
>> Content-Transfer-Encoding: quoted-printable
>>
>> which is fine, in itself; however, they have CR-CR-LF line terminators.
>>
>> For exam
flight 139241 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139241/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5f89bcc4604ea9e439039d873e34a8c06b47c707
baseline version:
ovmf 8ff68cd5e4c91c97f36ac
On Mon, 22 Jul 2019, Arnd Bergmann wrote:
> Building the privcmd code as a loadable module on ARM, we get
> a link error due to the private cache management functions:
>
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>
> Move the code into a new that is always built in wh
flight 139256 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139256/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Jul 10, 2019 at 12:48:57PM +0200, Laszlo Ersek wrote:
> On 07/04/19 16:42, Anthony PERARD wrote:
> > On a Xen PVH guest, none of the existing serial or console interface
> > works, so we add a new one, based on XenConsoleSerialPortLib, and
> > implemented via SerialDxe.
> >
> > That is a s
On 19/07/2019 14:07, Igor Druzhinin wrote:
> Following 6ff560f7f ("x86/SMP: don't try to stop already stopped CPUs")
> an incorrect condition was placed into kexec transition path
> leaving crashing CPU always online breaking kdump kernel entering.
> Correct it by unifying the condition with smp_se
On 20.07.19 21:25, Julien Grall wrote:
Hi,
Hi, Julien.
Apologies for the late answer. I have been traveling for the past few
weeks.
Absolutely no problem. Thank you for your review.
On 6/26/19 11:30 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMS
Hello everyone,
Following up on discussions that we had at the last Xen summit, we’re
submitting a Xen subproject proposal, regarding XCP-ng project (
https://xcp-ng.org). Feel free to give your feedback!
Regards,
Olivier Lambert and XCP-ng team
# XCP-ng proposal
## The Project
XCP-ng is a tu
flight 139239 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139239/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 8 reboot fail pass in 139225
Tests which did not succeed, but
Clarify why relaxed hardware domains don't need iommu page-table
syncing.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
xen/drivers/passthrough/iommu.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 79ec67
On 22/07/2019 16:01, Jan Beulich wrote:
> On 22.07.2019 15:36, Andrew Cooper wrote:
>> On 22/07/2019 09:34, Jan Beulich wrote:
>>> On 19.07.2019 19:27, Andrew Cooper wrote:
On 16/07/2019 17:38, Jan Beulich wrote:
> @@ -142,7 +178,15 @@ static void free_intremap_entry(const st
> {
>
> -Original Message-
> From: Roger Pau Monne
> Sent: 22 July 2019 16:32
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; George Dunlap
> ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Paul Durrant
>
> Subject: [PATCH] x86/p2m: fix non-translated handling of iommu mappings
>
The current usage of need_iommu_pt_sync in p2m for non-translated
guests is wrong because it doesn't correctly handle a relaxed PV
hardware domain, that has need_sync set to false, but still need
entries to be added from calls to {set/clear}_identity_p2m_entry.
Adjust the code in guest_physmap_add
On 22.07.2019 15:45, Andrew Cooper wrote:
> On 22/07/2019 09:43, Jan Beulich wrote:
>> On 19.07.2019 19:31, Andrew Cooper wrote:
>>> On 16/07/2019 17:39, Jan Beulich wrote:
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
@@ -416,6
On Mon, Jul 22, 2019 at 05:02:35PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 22 July 2019 15:40
> > To: Paul Durrant
> > Cc: 'Roman Shaposhnik' ; xen-devel@lists.xenproject.org;
> > jgr...@suse.com; Andrew
> > Cooper ; boris.ostrov...@oracle.co
On 22.07.2019 15:36, Andrew Cooper wrote:
> On 22/07/2019 09:34, Jan Beulich wrote:
>> On 19.07.2019 19:27, Andrew Cooper wrote:
>>> On 16/07/2019 17:38, Jan Beulich wrote:
@@ -142,7 +178,15 @@ static void free_intremap_entry(const st
{
union irte_ptr entry = get_intremap
> -Original Message-
> From: Roger Pau Monne
> Sent: 22 July 2019 15:40
> To: Paul Durrant
> Cc: 'Roman Shaposhnik' ; xen-devel@lists.xenproject.org;
> jgr...@suse.com; Andrew
> Cooper ; boris.ostrov...@oracle.com;
> jbeul...@suse.com
> Subject: Re: [Xen-devel] [BUG] After upgrade to
On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > When running as a Xen PVH guest, there is no CMOS to read the memory
> > size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> > works without CMOS
On Mon, Jul 22, 2019 at 04:03:44PM +0200, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > > diff --git a/xen/drivers/passthrough/iommu.c
> > > > b/xen/drivers/passthrough/iommu.c
> > > > index 79ec6719f5..9d91f0d633 100644
> > > > --- a/xen/drivers/passthrough/iommu.c
> > > > +++
flight 139237 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
133580
test-amd64-i386-
On 19/07/2019 14:57, Juergen Gross wrote:
> I have now a git branch with the two problems corrected and rebased to
> current staging available:
>
> github.com/jgross1/xen.git sched-v1b
Many thanks for the branch! As for the crashes, vcpu_sleep_sync() one
seems to be fixed now. But I can still re
> -Original Message-
[snip]
> > > diff --git a/xen/drivers/passthrough/iommu.c
> > > b/xen/drivers/passthrough/iommu.c
> > > index 79ec6719f5..9d91f0d633 100644
> > > --- a/xen/drivers/passthrough/iommu.c
> > > +++ b/xen/drivers/passthrough/iommu.c
> > > @@ -185,7 +185,7 @@ void __hwdom_in
On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
> > ACPI Timer does not work in a PVH guest, but local APIC works on both
>
> This is not accurate. It's not that the ACPI timer doesn't work, it's
> just that it's no
On Mon, Jul 22, 2019 at 01:54:00PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 22 July 2019 12:49
> > To: Paul Durrant ; 'Roman Shaposhnik'
> >
> > Cc: xen-devel@lists.xenproject.org; jgr...@suse.com; Andrew Cooper
> > ;
> > boris.ostrov...@orac
On 22/07/2019 09:43, Jan Beulich wrote:
> On 19.07.2019 19:31, Andrew Cooper wrote:
>> On 16/07/2019 17:39, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>>> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>>> @@ -416,6 +416,25 @@ union amd_iommu_ext_features {
>>>
On 22/07/2019 09:34, Jan Beulich wrote:
> On 19.07.2019 19:27, Andrew Cooper wrote:
>> On 16/07/2019 17:38, Jan Beulich wrote:
>>> @@ -142,7 +178,15 @@ static void free_intremap_entry(const st
>>>{
>>>union irte_ptr entry = get_intremap_entry(iommu, bdf, index);
>>>
>>> -ACCESS_
Instead of dynamically decide whether the previous vcpu was using full
or default GDT just add a percpu variable for that purpose. This at
once removes the need for testing vcpu_ids to differ twice.
This change improves performance by 0.5% - 1% on my test machine when
doing parallel compilation.
flight 139252 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139252/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 22.07.2019 14:39, Alexandru Stefan ISAILA wrote:
> Ping,
>
> Any reviews on this patch are appreciated.
FAOD I think I've provided all the feedback I have. The patch doesn't
seem to have a tool stack maintainer ack yet, and I think I had made
clear previously that I'm willing to look at change
On 22.07.19 14:18, Jan Beulich wrote:
On 22.07.2019 14:06, Andrew Cooper wrote:
Does reverting back to credit1 make the issue go away? I've never
encountered this on any smt=0 test, but I also don't use credit2 at all.
I'll try to remember trying this out the next time I see it. I can't
see a
On 22/07/2019 03:57, Kevin Buckley wrote:
> This follows on from
>
> pygrub gives "raise RuntimeError("Unable to find partition containing
> kernel")"
>
> https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01589.html
>
> and for some reason I submitted my latest findings onto the grub
On 19.07.2019 20:44, Andrew Cooper wrote:
> On 19/07/2019 17:16, Jan Beulich wrote:
>> On 19.07.2019 17:56, Andrew Cooper wrote:
>>> On 16/07/2019 17:36, Jan Beulich wrote:
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by intro
Ping,
Any reviews on this patch are appreciated.
Regards,
Alex
On 07.06.2019 14:50, Jan Beulich wrote:
On 07.06.19 at 12:55, wrote:
>> @@ -4735,6 +4736,28 @@ static int do_altp2m_op(
>> _gfn(a.u.change_gfn.old_gfn),
>> _gfn(a.u.change_gfn.new_gfn
Hi,
On 22/07/2019 13:11, Jan Beulich wrote:
On 22.07.2019 14:02, Julien Grall wrote:
On 22/07/2019 11:23, Jan Beulich wrote:
On 22.07.2019 11:30, Andrii Anisov wrote:
On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
Let vunmap align passed virtual address by
On 22.07.2019 14:06, Andrew Cooper wrote:
> Does reverting back to credit1 make the issue go away? I've never
> encountered this on any smt=0 test, but I also don't use credit2 at all.
I'll try to remember trying this out the next time I see it. I can't
see a connection to the used scheduler thou
On 22/07/2019 09:49, Jan Beulich wrote:
> On 19.07.2019 19:55, Andrew Cooper wrote:
>> On 16/07/2019 17:41, Jan Beulich wrote:
>> As an observation, I wonder whether continually sprinkling
>> process_pending_softirqs() is the best thing to do for keyhandlers.
>> We've got a number of other which in
On 22.07.2019 14:02, Julien Grall wrote:
> On 22/07/2019 11:23, Jan Beulich wrote:
>> On 22.07.2019 11:30, Andrii Anisov wrote:
>>>
>>>
>>> On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
> Let vunmap align passed virtual address by PAGE_SIZE.
Desp
On 22/07/2019 10:16, Jan Beulich wrote:
> On 21.07.2019 22:06, Andy Smith wrote:
>> Hi,
>>
>> My first time using smt=0 on hypervisor command line so not sure how
>> many versions and different pieces of hardware this happens with,
>> but I noticed this during the microcode update stage of boot:
>>
On 22/07/2019 11:23, Jan Beulich wrote:
On 22.07.2019 11:30, Andrii Anisov wrote:
On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
Let vunmap align passed virtual address by PAGE_SIZE.
Despite seeing Andrew's R-b you've already got I'd like to point out
that
> -Original Message-
> From: Roger Pau Monne
> Sent: 22 July 2019 12:49
> To: Paul Durrant ; 'Roman Shaposhnik'
>
> Cc: xen-devel@lists.xenproject.org; jgr...@suse.com; Andrew Cooper
> ;
> boris.ostrov...@oracle.com; jbeul...@suse.com
> Subject: Re: [Xen-devel] [BUG] After upgrade to Xe
On Mon, Jul 22, 2019 at 08:20:36AM +, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > (XEN) Domain heap initialised
> > > (XEN) ACPI: 32/64X FACS address mismatch in FADT -
> > > 8ce8ef80/, using 32
> > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec000
1 - 100 of 121 matches
Mail list logo
