flight 168672 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168672/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168670 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
> Subject: Re: [PATCH 2/3] xen/arm: Add i.MX lpuart early printk support
>
> Hi Peng,
>
> On 28/02/2022 01:07, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Signed-off-by: Peng Fan
> > ---
> > xen/arch/arm/Kconfig.debug | 18 ++
> >
> Subject: Re: [PATCH 3/3] xen/arm: Add i.MX8QM platform support
>
> Hi Peng,
>
> On 28/02/2022 01:07, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Signed-off-by: Peng Fan
> > ---
> > xen/arch/arm/Kconfig.debug | 3 +++
> > xen/arch/arm/platforms/Makefile | 1 +
> >
Hi Julien,
> Subject: Re: [PATCH 1/3] xen/arm: Add i.MX lpuart driver
>
> Hi Peng,
>
> On 28/02/2022 01:07, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Signed-off-by: Peng Fan
> > ---
> > xen/drivers/char/Kconfig | 8 +
> > xen/drivers/char/Makefile | 1 +
> >
flight 168668 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168669 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168669/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> In a few scenarios where owner domain, is defined after borrower domain in
> device tree configuration, then statically shared pages haven't been properly
> allocated if borrower domain tries to do foreign memory map during
> domain
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> We expose the shared memory to the domU using the "xen,shared-memory-v1"
> reserved-memory binding. See
> Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> in Linux for the corresponding device tree binding.
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> If owner property is defined, then owner domain of a static shared memory
> region is not the default dom_shared anymore, but a specific domain.
>
> This commit implements allocating static shared memory to a specific domain
> when
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> This commit introduces process_shm to cope with static shared memory in
> domain construction.
>
> This commit only considers allocating static shared memory to dom_shared
> when owner domain is not explicitly defined in device
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> This commits introduces a new helper guest_physmap_add_shm to set up shared
> memory foreign mapping for borrower domain.
>
> Firstly it should get and take reference of statically shared pages from
> owner dom_shared. Then it will
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> In case to own statically shared pages when owner domain is not
> explicitly defined, this commits propose a special domain DOMID_SHARED,
> and we assign it 0x7FF5, as one of the system domains.
>
> Statically shared memory reuses
On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng
>
> This patch serie introduces a new feature: setting up static
> shared memory on a dom0less system, through device tree configuration.
>
> This commit parses shared memory node at boot-time, and reserve it in
> bootinfo.reserved_mem
On 3/17/22 3:09 PM, Dongli Zhang wrote:
> The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
> copy the written data to persistent page.
>
> ".need_copy = rq_data_dir(req) && info->feature_persistent,"
>
> Signed-off-by: Dongli Zhang
> ---
Looks good.
Reviewed-by:
On 3/17/22 4:46 PM, Colin Ian King wrote:
> Variable i is being assigned a value that is never read, it is being
> re-assigned later in a for-loop. The assignment is redundant and can
> be removed.
>
> Cleans up clang scan build warning:
> drivers/block/xen-blkback/blkback.c:934:14: warning:
flight 168659 qemu-upstream-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168659/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 167686
On Thu, 17 Mar 2022, Ayan Kumar Halder wrote:
> When the data abort is caused due to cache maintenance for an address,
> there are three scenarios:-
>
> 1. Address belonging to a non emulated region - For this, Xen should
> set the corresponding bit in the translation table entry to valid and
>
On Thu, 17 Mar 2022, Ayan Kumar Halder wrote:
> If the abort was caused due to access to stage1 translation table, Xen
> will try to set the p2m entry (assuming that the Stage 1 translation
> table is in a non MMIO region).
> If there is no such entry found, then Xen will try to map the address as
On Thu, 17 Mar 2022, Ayan Kumar Halder wrote:
> When an instruction is trapped in Xen due to translation fault, Xen
> checks if the ISS is invalid (for data abort) or it is an instruction
> abort. If so, Xen tries to resolve the translation fault using p2m page
> tables. In case of data abort, Xen
flight 168664 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168664/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
copy the written data to persistent page.
".need_copy = rq_data_dir(req) && info->feature_persistent,"
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
flight 168666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168666/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi,
On 09/03/2022 11:20, Julien Grall wrote:
From: Julien Grall
Xen is currently not fully compliant with the Arm because it will
switch the TTBR with the MMU on.
In order to be compliant, we need to disable the MMU before
switching the TTBR. The implication is the page-tables should
contain
On 17/03/2022 15:23, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 9 Mar 2022, at 11:20, Julien Grall wrote:
From: Julien Grall
In a follow-up patch, the base address for the common mappings will
vary between arm32 and arm64. To avoid any duplication, define
every mapping in the
flight 168657 qemu-upstream-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168657/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail baseline
untested
flight 168658 qemu-upstream-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168658/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail baseline
untested
On Thu, Mar 17, 2022 at 2:14 PM Andrew Cooper wrote:
>
> On 17/03/2022 17:52, Jason Andryuk wrote:
> > I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
> > device assigned. Xen logged the following Flask denial for a second
> > PVH dom5 (uivm) without any PCI devices
On Tue, Mar 08, 2022 at 11:47:04AM -0800, Vikram Garhwal wrote:
> Signed-off-by: Vikram Garhwal
> ---
> tools/xl/xl.h | 4
> tools/xl/xl_cmdtable.c | 6 ++
> tools/xl/xl_vmcontrol.c | 45 +
> 3 files changed, 55 insertions(+)
>
>
On 17/03/2022 17:52, Jason Andryuk wrote:
> I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
> device assigned. Xen logged the following Flask denial for a second
> PVH dom5 (uivm) without any PCI devices assigned. This is Xen 4.14.4.
>
> (XEN) avc: denied { remove_irq }
I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
device assigned. Xen logged the following Flask denial for a second
PVH dom5 (uivm) without any PCI devices assigned. This is Xen 4.14.4.
(XEN) avc: denied { remove_irq } for domid=5 irq=17
On Tue, Mar 08, 2022 at 11:47:03AM -0800, Vikram Garhwal wrote:
> Signed-off-by: Vikram Garhwal
> ---
> tools/include/libxl.h| 3 ++
> tools/libs/light/Makefile| 1 +
> tools/libs/light/libxl_overlay.c | 67
> 3 files changed, 71
flight 168662 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168662/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 17.03.2022 17:47, Jan Beulich wrote:
> On 10.03.2022 08:34, Juergen Gross wrote:
>> Now that the hypercall handlers are all being called directly instead
>> through a function vector, the "cf_check" attribute can be removed.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> V4:
>> - new patch
>>
On 17.03.22 17:47, Jan Beulich wrote:
On 10.03.2022 08:34, Juergen Gross wrote:
Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.
Signed-off-by: Juergen Gross
---
V4:
- new patch
---
On 10.03.2022 08:34, Juergen Gross wrote:
> Now that the hypercall handlers are all being called directly instead
> through a function vector, the "cf_check" attribute can be removed.
>
> Signed-off-by: Juergen Gross
> ---
> V4:
> - new patch
> ---
> xen/arch/x86/compat.c | 6
> On 11 Mar 2022, at 19:11, Bjoern Doebel wrote:
>
> Fix a couple of typos in livepatch code.
NIT: I would say: [...] in livepatch code comments.
>
> Signed-off-by: Bjoern Doebel
With or without it:
Reviewed-by: Luca Fancellu
Cheers,
Luca
> CC: Konrad Rzeszutek Wilk
> CC: Ross
On 17/03/2022 16:28, Jan Beulich wrote:
> On 17.03.2022 17:19, Andrew Cooper wrote:
>> On 17/03/2022 09:17, Jan Beulich wrote:
>>> On 16.03.2022 20:23, Andrew Cooper wrote:
On 16/03/2022 08:33, Jan Beulich wrote:
> On 15.03.2022 17:53, Andrew Cooper wrote:
>> ---
On 17.03.2022 17:19, Andrew Cooper wrote:
> On 17/03/2022 09:17, Jan Beulich wrote:
>> On 16.03.2022 20:23, Andrew Cooper wrote:
>>> On 16/03/2022 08:33, Jan Beulich wrote:
On 15.03.2022 17:53, Andrew Cooper wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@
On 17/03/2022 09:17, Jan Beulich wrote:
> On 16.03.2022 20:23, Andrew Cooper wrote:
>> On 16/03/2022 08:33, Jan Beulich wrote:
>>> On 15.03.2022 17:53, Andrew Cooper wrote:
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -215,8 +215,9 @@ SECTIONS
} PHDR(text)
On Thu, Mar 17, 2022 at 12:07 PM Jan Beulich wrote:
>
> On 17.03.2022 16:59, Tamas K Lengyel wrote:
> > On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich wrote:
> >>
> >> On 17.03.2022 15:43, Tamas K Lengyel wrote:
> >>> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich wrote:
> On 10.03.2022 19:44,
On 17.03.2022 16:59, Tamas K Lengyel wrote:
> On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich wrote:
>>
>> On 17.03.2022 15:43, Tamas K Lengyel wrote:
>>> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich wrote:
On 10.03.2022 19:44, Tamas K Lengyel wrote:
> @@ -1155,6 +1154,8 @@ static int
On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich wrote:
>
> On 17.03.2022 15:43, Tamas K Lengyel wrote:
> > On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich wrote:
> >> On 10.03.2022 19:44, Tamas K Lengyel wrote:
> >>> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain
> >>> *d,
During VM forking and resetting a failed vmentry has been observed due
to the guest non-register state going out-of-sync with the guest register
state. For example, a VM fork reset right after a STI instruction can trigger
the failed entry. This is due to the guest non-register state not being
Hi Vikram,
On Tue, Mar 08, 2022 at 11:47:02AM -0800, Vikram Garhwal wrote:
> diff --git a/tools/libs/ctrl/xc_overlay.c b/tools/libs/ctrl/xc_overlay.c
> new file mode 100644
> index 00..8fe780d75a
> --- /dev/null
> +++ b/tools/libs/ctrl/xc_overlay.c
Could rename this new file? I don't
On 17/03/2022 14:26, Luca Fancellu wrote:
> I’ve tested on the ARM side, I’ve started/destroyed few guests from Dom0,
> connect to the console, run
> some network communications between guest and Dom0, everything works:
>
> Tested-by: Luca Fancellu
Thanks! I tested on x86 (in a QEMU VM) by
Hi Julien,
> On 9 Mar 2022, at 11:20, Julien Grall wrote:
>
> From: Julien Grall
>
> In a follow-up patch, the base address for the common mappings will
> vary between arm32 and arm64. To avoid any duplication, define
> every mapping in the common region from the previous one.
>
> Take the
On 17.03.2022 15:43, Tamas K Lengyel wrote:
> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich wrote:
>> On 10.03.2022 19:44, Tamas K Lengyel wrote:
>>> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain
>>> *d, hvm_domain_context_t *h)
>>> v->arch.dr6 = ctxt.dr6;
>>>
On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich wrote:
>
> On 10.03.2022 19:44, Tamas K Lengyel wrote:
> > During VM fork resetting a failed vmentry has been observed when the reset
> > is performed immediately after a STI instruction executed. This is due to
> > the guest interruptibility state in
flight 168663 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 17/03/2022 14:21, Jan Beulich wrote:
> On 17.03.2022 15:06, Andrew Cooper wrote:
>> For livepatching, we need to look at a potentially clobbered function and
>> determine whether it used to have an ENDBR64 instruction.
>>
>> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and
> On 16 Mar 2022, at 18:58, Andrew Cooper wrote:
>
> On 16/03/2022 18:38, Raphael Ning wrote:
>> From: Raphael Ning
>>
>> Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
>> if it fails to lock the FIFO event queue(s), or if the guest has not
>> initialized the FIFO
On 17/03/2022 14:16, Roger Pau Monné wrote:
> On Thu, Mar 17, 2022 at 02:00:19PM +, Andrew Cooper wrote:
>> On 17/03/2022 11:08, Roger Pau Monne wrote:
>>> A side effect of ignoring such sections is that symbols belonging to
>>> them won't be resolved, and that could make relocations belonging
On 17.03.2022 15:06, Andrew Cooper wrote:
> For livepatching, we need to look at a potentially clobbered function and
> determine whether it used to have an ENDBR64 instruction.
>
> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
> check-endbr.sh to look for it. The
On Thu, Mar 17, 2022 at 02:00:19PM +, Andrew Cooper wrote:
> On 17/03/2022 11:08, Roger Pau Monne wrote:
> > A side effect of ignoring such sections is that symbols belonging to
> > them won't be resolved, and that could make relocations belonging to
> > other sections that reference those
On 17.03.2022 15:00, Andrew Cooper wrote:
> On 17/03/2022 11:08, Roger Pau Monne wrote:
>> A side effect of ignoring such sections is that symbols belonging to
>> them won't be resolved, and that could make relocations belonging to
>> other sections that reference those symbols fail.
>>
>> For
For livepatching, we need to look at a potentially clobbered function and
determine whether it used to have an ENDBR64 instruction.
Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
check-endbr.sh to look for it. The same logic can check for the absence of
any endbr32
On 17.03.2022 12:06, Tamas K Lengyel wrote:
> Another question I would be interested to hear from the maintainers is in
> regards to the hvm context compat macros. Right now they differentiate
> between hvm hw cpu struct versions based on size. So since this patch
> doesn't change the size how is
When the data abort is caused due to cache maintenance for an address,
there are three scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the corresponding bit in the translation table entry to valid and
return to the guest to retry the instruction. This can
When an instruction is trapped in Xen due to translation fault, Xen
checks if the ISS is invalid (for data abort) or it is an instruction
abort. If so, Xen tries to resolve the translation fault using p2m page
tables. In case of data abort, Xen will try to map the mmio region to
the guest (ie
If the abort was caused due to access to stage1 translation table, Xen
will try to set the p2m entry (assuming that the Stage 1 translation
table is in a non MMIO region).
If there is no such entry found, then Xen will try to map the address as
a MMIO region (assuming that the Stage 1 translation
Hi All,
The patch series continues with the support to decode instructions by Xen when
ISS is invalid. Currently, when the guest executes post indexing ldr/str
instructions
on emulated MMIO, these instructions are trapped into Xen as a data abort.
Xen reads hsr_dabt.isv == 0, so ISS is invalid.
On 17/03/2022 11:08, Roger Pau Monne wrote:
> A side effect of ignoring such sections is that symbols belonging to
> them won't be resolved, and that could make relocations belonging to
> other sections that reference those symbols fail.
>
> For example it's likely to have an empty
On 10.03.2022 19:44, Tamas K Lengyel wrote:
> During VM fork resetting a failed vmentry has been observed when the reset
> is performed immediately after a STI instruction executed. This is due to
> the guest interruptibility state in the VMCS being modified by STI but the
> subsequent reset
On Thu, Mar 17, 2022 at 02:26:50PM +0100, Jan Beulich wrote:
> On 17.03.2022 12:08, Roger Pau Monne wrote:
> > Track whether symbols belong to ignored sections in order to avoid
> > applying relocations referencing those symbols. The address of such
> > symbols won't be resolved and thus the
On 17.03.2022 12:08, Roger Pau Monne wrote:
> Track whether symbols belong to ignored sections in order to avoid
> applying relocations referencing those symbols. The address of such
> symbols won't be resolved and thus the relocation will likely fail or
> write garbage to the destination.
>
>
flight 168661 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168661/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 17.03.2022 12:08, Roger Pau Monne wrote:
> I wonder whether it's possible to have unresolved symbols if we only
> ignore non SHF_ALLOC sections, so we could maybe error out earlier if we
> found a symbols that belongs to a non SHF_ALLOC section in
> livepatch_elf_resolve_symbols. The current
On 17.03.22 11:00, Jiamei Xie wrote:
-Original Message-
From: Xen-devel On Behalf Of
Jiamei Xie
Sent: 2022年3月17日 17:17
To: Ross Lagerwall ; Bjoern Doebel
; xen-devel@lists.xenproject.org
Cc: Michael Kurth ; Martin Pohlack
; Roger Pau Monne ;
Andrew Cooper ; Konrad Rzeszutek Wilk
On 17.03.22, 12:10, "Xen-devel on behalf of Roger Pau Monne"
wrote:
Hello,
Relocations that reference symbols that belong to sections with a size
of 0 are not properly resolved, as the address of those symbols won't be
resolved in the first place.
Fix this by not
flight 168644 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168644/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168515
test-amd64-i386-xl-qemut-win7-amd64 19
flight 168653 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168653/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 17/03/2022 10:43, Jan Beulich wrote:
> On 17.03.2022 11:02, Andrew Cooper wrote:
>> For livepatching, we need to look at a potentially clobbered function and
>> determine whether it used to have an ENDBR64 instruction.
>>
>> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and
Hello,
Following up a discussion from the v1 of "XTF on arm" patch series(it's been
almost a year),
I created a new version with the following major changes:
-fixed comments from v1
-no non-MMU environment for arm64
-no PL011 driver
-no test-naming/xtf-runner modifications to make OSSTEST happy
On 17.03.22 12:07, Julien Grall wrote:
Hi Juergen,
On 16/03/2022 16:10, Juergen Gross wrote:
Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.
Signed-off-by: Juergen Gross
On 17/03/2022 11:07, Julien Grall wrote:
Hi Juergen,
On 16/03/2022 16:10, Juergen Gross wrote:
Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.
Signed-off-by: Juergen
A side effect of ignoring such sections is that symbols belonging to
them won't be resolved, and that could make relocations belonging to
other sections that reference those symbols fail.
For example it's likely to have an empty .altinstr_replacement with
symbols pointing to it, and marking the
Track whether symbols belong to ignored sections in order to avoid
applying relocations referencing those symbols. The address of such
symbols won't be resolved and thus the relocation will likely fail or
write garbage to the destination.
Return an error in that case, as leaving unresolved
Hello,
Relocations that reference symbols that belong to sections with a size
of 0 are not properly resolved, as the address of those symbols won't be
resolved in the first place.
Fix this by not ignoring sections with a size of 0, while still properly
handling the detection of whether a
Hi Juergen,
On 16/03/2022 16:10, Juergen Gross wrote:
Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.
Signed-off-by: Juergen Gross
---
docs/misc/xenstore-ring.txt | 1 +
On Thu, Mar 17, 2022, 2:09 AM Tian, Kevin wrote:
> > From: Tamas K Lengyel
> > Sent: Monday, March 14, 2022 8:14 PM
> >
> > On Mon, Mar 14, 2022 at 3:22 AM Tian, Kevin
> wrote:
> > >
> > > > From: Lengyel, Tamas
> > > > Sent: Friday, March 11, 2022 2:45 AM
> > > >
> > > > During VM fork
On 16/03/2022 18:58, Andrew Cooper wrote:
> On 16/03/2022 18:38, Raphael Ning wrote:
>> From: Raphael Ning
>>
>> Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
>> if it fails to lock the FIFO event queue(s), or if the guest has not
>> initialized the FIFO control block
On 17.03.2022 11:02, Andrew Cooper wrote:
> For livepatching, we need to look at a potentially clobbered function and
> determine whether it used to have an ENDBR64 instruction.
>
> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
> check-endbr.sh to look for it.
>
>
Hi Julien,
On 11/03/2022 18:34, Julien Grall wrote:
Hi,
On 10/03/2022 17:45, Ayan Kumar Halder wrote:
When the data abort is caused due to cache maintenance for an address,
there are three scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the corresponding
On 17.03.2022 11:00, Jiamei Xie wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Jiamei Xie
>> Sent: 2022年3月17日 17:17
>>
>>> -Original Message-
>>> From: Xen-devel On Behalf Of
>>> Ross Lagerwall
>>> Sent: 2022年3月10日 1:12
>>> To: Bjoern Doebel ;
flight 168642 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168642/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
Tests which are
For livepatching, we need to look at a potentially clobbered function and
determine whether it used to have an ENDBR64 instruction.
Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
check-endbr.sh to look for it.
The choice of nop has some complicated consequences.
> -Original Message-
> From: Xen-devel On Behalf Of
> Jiamei Xie
> Sent: 2022年3月17日 17:17
> To: Ross Lagerwall ; Bjoern Doebel
> ; xen-devel@lists.xenproject.org
> Cc: Michael Kurth ; Martin Pohlack
> ; Roger Pau Monne ;
> Andrew Cooper ; Konrad Rzeszutek Wilk
>
> Subject: RE: [PATCH
On 16.03.2022 15:00, Andrew Cooper wrote:
> STIBP and PSFD are slightly weird bits, because they're both implied by other
> bits in MSR_SPEC_CTRL. Add fine grain controls for them, and take the
> implications into account when setting IBRS/SSBD.
>
> Rearrange the IBPB text/variables/logic to
flight 168649 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 16.03.2022 20:23, Andrew Cooper wrote:
> On 16/03/2022 08:33, Jan Beulich wrote:
>> On 15.03.2022 17:53, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -215,8 +215,9 @@ SECTIONS
>>>} PHDR(text)
>>>DECL_SECTION(.init.data) {
>>> #endif
>>>
Hi Bjoern,
> -Original Message-
> From: Xen-devel On Behalf Of
> Ross Lagerwall
> Sent: 2022年3月10日 1:12
> To: Bjoern Doebel ; xen-devel@lists.xenproject.org
> Cc: Michael Kurth ; Martin Pohlack
> ; Roger Pau Monne ;
> Andrew Cooper ; Konrad Rzeszutek Wilk
>
> Subject: Re: [PATCH v5
On Wed, Mar 16, 2022 at 09:13:15AM +, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware
On 17.03.2022 06:55, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Monday, March 14, 2022 3:33 PM
>>
>> On 14.03.2022 05:01, Tian, Kevin wrote:
From: Jan Beulich
Sent: Friday, February 18, 2022 4:31 PM
On 18.02.2022 06:20, Tian, Kevin wrote:
>> From: Jan Beulich
On 17/03/2022 06:28, Juergen Gross wrote:
On 16.03.22 19:38, Raphael Ning wrote:
From: Raphael Ning
Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
if it fails to lock the FIFO event queue(s), or if the guest has not
initialized the FIFO control block for the
On Wed, Mar 16, 2022 at 11:28:48AM +0100, Michal Orzel wrote:
> Hi Roger,
>
> On 14.03.2022 11:55, Roger Pau Monne wrote:
> > Detect GNU and LLVM ld implementations. This is required for further
> > patches that will introduce diverging behaviour depending on the
> > linker implementation in use.
flight 168651 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168638 qemu-mainline real [real]
flight 168647 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168638/
http://logs.test-lab.xenproject.org/osstest/logs/168647/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 16.03.22 19:38, Raphael Ning wrote:
From: Raphael Ning
Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
if it fails to lock the FIFO event queue(s), or if the guest has not
initialized the FIFO control block for the target vCPU. A well-behaved
guest should never
> From: Jane Malalane
> Sent: Wednesday, March 16, 2022 5:13 PM
>
> Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
> XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC
> and
> x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
> can subsequently be enabled on
1 - 100 of 101 matches
Mail list logo
