Hi Guilherme,
+Desmond
On 2022-05-17 09:42, Guilherme G. Piccoli wrote:
On 17/05/2022 10:57, Petr Mladek wrote:
[...]
--- a/drivers/misc/bcm-vk/bcm_vk_dev.c
+++ b/drivers/misc/bcm-vk/bcm_vk_dev.c
@@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const
struct pci_device_id
flight 170559 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170559/
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 170542 qemu-mainline real [real]
flight 170555 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170542/
http://logs.test-lab.xenproject.org/osstest/logs/170555/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 170553 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170553/
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
flight 170558 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170558/
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
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年5月18日 21:31
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; Jiamei Xie
> ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v3 8/9] xen/x86: add detection of memory interleaves
> for different
flight 170557 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170557/
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 170556 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170556/
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
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年5月18日 21:34
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v3 9/9] xen/x86: use INFO level for node's without
> memory log message
>
> On
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年5月18日 21:05
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu ; Jiamei Xie ; xen-
> de...@lists.xenproject.org
> Subject:
flight 170554 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170554/
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 170552 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170552/
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 Thu, 19 May 2022, Oleksandr wrote:
> > On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
> > > On 18.05.22 17:32, Arnd Bergmann wrote:
> > > > On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
> > > > wrote:
> > > >This would mean having a device
> > > > node for the grant-table
On 17/05/2022 14:21, Roger Pau Monne wrote:
> Under certain conditions guests can get the CPU stuck in an infinite
> loop without the possibility of an interrupt window to occur.
instruction boundary.
It's trivial to create an infinite loop without an interrupt window :)
Also, I'd probably
On 18.05.22 21:59, Rob Herring wrote:
Hello Rob, Arnd
On Wed, May 18, 2022 at 03:32:27PM +0100, Arnd Bergmann wrote:
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko wrote:
diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
On 18.05.22 19:39, Arnd Bergmann wrote:
Hello Arnd
On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
On 18.05.22 17:32, Arnd Bergmann wrote:
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko wrote:
This would mean having a device
node for the grant-table mechanism that can be
On 17/05/2022 14:21, Roger Pau Monne wrote:
> Add support for enabling Bus Lock Detection on Intel systems. Such
> detection works by triggering a vmexit, which is enough of a pause to
> prevent a guest from abusing of the Bus Lock.
"which is enough of a" is a bit firmer than ideal. "which Andy
flight 170549 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170549/
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 170543 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170543/
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 Vikram,
On 08/03/2022 19:47, Vikram Garhwal wrote:
Update sysctl XEN_SYSCTL_dt_overlay to enable support for dtbo nodes addition
using device tree overlay.
xl overlay add file.dtbo:
Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
device_tree_flattened) is
On Wed, May 18, 2022 at 03:32:27PM +0100, Arnd Bergmann wrote:
> On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
> wrote:
> >
> > diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
> > b/Documentation/devicetree/bindings/virtio/mmio.yaml
> > index 10c22b5..29a0932 100644
> >
Hi Vikram,
On 08/03/2022 19:47, Vikram Garhwal wrote:
Introduce sysctl XEN_SYSCTL_dt_overlay to remove device-tree nodes added using
device tree overlay.
xl overlay remove file.dtbo:
Removes all the nodes in a given dtbo.
First, removes IRQ permissions and MMIO accesses. Next, it
flight 170547 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170547/
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 Tue, May 17, 2022 at 05:46:07PM +0200, Jan Beulich wrote:
> On 17.05.2022 17:43, Roger Pau Monné wrote:
> > On Tue, May 17, 2022 at 05:13:46PM +0200, Jan Beulich wrote:
> >> On 17.05.2022 16:48, Roger Pau Monné wrote:
> >>> On Tue, May 17, 2022 at 04:41:31PM +0200, Jan Beulich wrote:
> On
The EFI System Resource Table (ESRT) is necessary for fwupd to identify
firmware updates to install. According to the UEFI specification §23.4,
the ESRT shall be stored in memory of type EfiBootServicesData. However,
memory of type EfiBootServicesData is considered general-purpose memory
by Xen,
On Wed, May 18, 2022 at 11:48 AM Jan Beulich wrote:
>
> On 18.05.2022 17:01, Tamas K Lengyel wrote:
> > On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
> > wrote:
> >>
> >> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné
> >> wrote:
> >>>
> >>> On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K
On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
> On 18.05.22 17:32, Arnd Bergmann wrote:
> > On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
> > wrote:
>
> > This would mean having a device
> > node for the grant-table mechanism that can be referred to using the
> > 'iommus'
> >
flight 170532 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170532/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170454
test-amd64-amd64-xl-qemut-win7-amd64
flight 170544 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170544/
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 18.05.22 17:32, Arnd Bergmann wrote:
Hello Arnd
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko wrote:
diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
b/Documentation/devicetree/bindings/virtio/mmio.yaml
index 10c22b5..29a0932 100644
---
On 18.05.2022 17:01, Tamas K Lengyel wrote:
> On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
> wrote:
>>
>> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné wrote:
>>>
>>> On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
Need to separately specify if the reset is for the
flight 170529 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170529/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail like 170520
On Thu, May 12, 2022 at 9:47 AM Tamas K Lengyel wrote:
>
> On Wed, May 4, 2022 at 9:12 AM Tamas K Lengyel wrote:
> >
> > On Wed, Apr 27, 2022 at 11:51 AM Tamas K Lengyel
> > wrote:
> > >
> > > Add monitor event that hooks the vmexit handler allowing for both sync and
> > > async monitoring of
On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
wrote:
>
> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné wrote:
> >
> > On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
> > > Need to separately specify if the reset is for the memory or for the VM
> > > state,
> > > or both.
> >
On 18/05/2022 15:44, Juergen Gross wrote:
> Today the number of cpupools in a system is unlimited. This can lead to
> multiple problems (e.g. duplicate cpupool-id).
Not to mention scalability issues. Search by ID is O(n).
>
> Limit the number of cpupools to twice the number of maximum possible
On Wed, May 18, 2022 at 11:41:51AM +0200, Juergen Gross wrote:
> On 07.05.22 00:32, Jarkko Sakkinen wrote:
> > On Thu, May 05, 2022 at 10:16:34AM +0200, Juergen Gross wrote:
> > > Simplify tpmfront's ring creation and removal via xenbus_setup_ring()
> > > and xenbus_teardown_ring().
> > >
> > >
On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
wrote:
>
> Problem
> ---
>
> SoC devices require power-off call chaining functionality from kernel.
> We have a widely used restart chaining provided by restart notifier API,
> but nothing for power-off.
>
> Solution
>
>
> Introduce new
Today the number of cpupools in a system is unlimited. This can lead to
multiple problems (e.g. duplicate cpupool-id).
Limit the number of cpupools to twice the number of maximum possible
cpus, allowing to have one cpupool per physical cpu plus some spare
cpupools for special means (there are
flight 170539 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170539/
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
+ Adding toolstack maintainer
> On 18 May 2022, at 12:34, Andrew Cooper wrote:
>
> On 18/05/2022 11:30, Luca Fancellu wrote:
>>> On 18 May 2022, at 11:12, Andrew Cooper wrote:
>>>
>>> On 18/05/2022 10:51, Edwin Torok wrote:
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml
>
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko wrote:
>
> diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
> b/Documentation/devicetree/bindings/virtio/mmio.yaml
> index 10c22b5..29a0932 100644
> --- a/Documentation/devicetree/bindings/virtio/mmio.yaml
> +++
Ping?
On 02.05.22 10:47, Juergen Gross wrote:
libxl_domain_setmaxmem() called during "xl mem-max" should update the
domain's memory/static-max Xenstore node, as otherwise "xl mem-set"
won't be able to set the memory size to the new maximum.
Adjust the related comments and documentation
On 18/05/2022 14:09, Stefan Hajnoczi wrote:
Commit 1b7fd729559c ("block: rename buffer_alignment to
guest_block_size") noted:
At this point, the field is set by the device emulation, but completely
ignored by the block layer.
The last time the value of buffer_alignment/guest_block_size
On 17.05.22 03:27, Rob Herring wrote:
Hello Rob, all
On Sat, May 07, 2022 at 09:19:06PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Introduce Xen specific binding for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent
On Tue, May 03, 2022 at 03:22:07PM +0200, Juergen Gross wrote:
> Some drivers are using pat_enabled() in order to test availability of
> special caching modes (WC and UC-). This will lead to false negatives
> in case the system was booted e.g. with the "nopat" variant and the
> BIOS did setup the
flight 170535 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170535/
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
flight 170538 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170538/
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 11.05.2022 03:46, Wei Chen wrote:
> In previous code, Xen was using KERN_WARNING for log message
> when Xen found a node without memory. Xen will print this
> warning message, and said that this may be an BIOS Bug or
> mis-configured hardware. But actually, this warning is bogus,
> because in
On 11.05.2022 03:46, Wei Chen wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -42,6 +42,12 @@ static struct node node_memblk_range[NR_NODE_MEMBLKS];
> static nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
> static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
>
>
Have is_hvm_pv_evtchn_domain() return true for vector callbacks for
evtchn delivery set up on a per-vCPU basis via
HVMOP_set_evtchn_upcall_vector.
is_hvm_pv_evtchn_domain() returning true is a condition for setting up
physical IRQ to event channel mappings.
Therefore, a CPUID bit is added so
On 18/05/2022 04:33, Petr Mladek wrote:
> [...]
> Anyway, I would distinguish it the following way.
>
> + If the notifier is preserving kernel log then it should be ideally
> treated as kmsg_dump().
>
> + It the notifier is saving another debugging data then it better
> fits into the
On 18/05/2022 04:58, Petr Mladek wrote:
> [...]
>> I does similar things like kmsg_dump() so it should be called in
>> the same location (after info notifier list and before kdump).
>>
>> A solution might be to put it at these notifiers at the very
>> end of the "info" list or make extra "dump"
On 11.05.2022 03:46, Wei Chen wrote:
> NUMA node structure "struct node" is using u64 as node memory
> range. In order to make other architectures can reuse this
> NUMA node relative code, we replace the u64 to paddr_t. And
> use pfn_to_paddr and paddr_to_pfn to replace explicit shift
>
On 18/05/2022 04:38, Petr Mladek wrote:
> [...]
> I have answered this in more detail in the other reply, see
> https://lore.kernel.org/r/YoShZVYNAdvvjb7z@alley
>
> I agree that both notifiers in
>
> drivers/soc/bcm/brcmstb/pm/pm-arm.c
> drivers/firmware/google/gsmi.c
>
> better fit
Commit 1b7fd729559c ("block: rename buffer_alignment to
guest_block_size") noted:
At this point, the field is set by the device emulation, but completely
ignored by the block layer.
The last time the value of buffer_alignment/guest_block_size was
actually used was before commit 339064d50639
On 11.05.2022 03:46, Wei Chen wrote:
> In current code, when Xen is running in a multiple nodes
> NUMA system, it will set dma_bitsize in end_boot_allocator
> to reserve some low address memory as DMA zone.
>
> There are some x86 implications in the implementation.
> Because on x86, memory starts
flight 170537 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170537/
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 11.05.2022 03:46, Wei Chen wrote:
> x86 is using compiler feature testing to decide EFI build
> enable or not. When EFI build is disabled, x86 will use an
> efi/stub.c file to replace efi/runtime.c for build objects.
> Following this idea, we introduce a stub file for Arm, but
> use
On 25.04.2022 10:29, Jan Beulich wrote:
> For a long time we've been rather inefficient with IOMMU page table
> management when not sharing page tables, i.e. in particular for PV (and
> further specifically also for PV Dom0) and AMD (where nowadays we never
> share page tables). While up to about
flight 170536 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170536/
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 11.05.2022 15:48, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:44:11AM +0200, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich
>> Reviewed-by: Kevin tian
>
> Reviewed-by: Roger Pau Monné
Thanks.
> Would be helpful to also have those per-guest I think.
Perhaps, but we don't have
On 18/05/2022 11:30, Luca Fancellu wrote:
>> On 18 May 2022, at 11:12, Andrew Cooper wrote:
>>
>> On 18/05/2022 10:51, Edwin Torok wrote:
diff --git a/tools/ocaml/libs/xc/xenctrl.ml
b/tools/ocaml/libs/xc/xenctrl.ml
index 7503031d8f61..8eab6f60eb14 100644
---
On 18/05/2022 11:27, Luca Fancellu wrote:
> Hi Andrew,
>
>> On 17 May 2022, at 20:41, Andrew Cooper wrote:
>>
>> c/s cfc52148444f ("xen/domain: Reduce the quantity of initialisation for
>> system domains") removed the path in domain_create() which called
>> sched_init_domain() with CPUPOOLID_NONE
On Tue, May 03, 2022 at 08:26:03PM +0300, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> This patch introduces helpers to allocate Virtio MMIO params
> (IRQ and memory region) and create specific device node in
> the Guest device-tree with allocated params. In order to deal
> with multiple
flight 170534 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170534/
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 Tue, May 03, 2022 at 08:26:02PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch adds basic support for configuring and assisting virtio-mmio
> based virtio-disk backend (emulator) which is intended to run out of
> Qemu and could be run in any domain.
> Although
On 18/05/2022 10:07, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 11.05.2022 17:14, Jane Malalane wrote:
>> Have is_hvm_pv_evtchn_vcpu() return true for vector callbacks
On 18.05.2022 12:38, Jane Malalane wrote:
> On 18/05/2022 10:09, Jan Beulich wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>> unless you have verified the sender and know the content is safe.
>>
>> On 13.05.2022 17:39, Roger Pau Monné wrote:
>>> On Wed, May
On 11.05.2022 13:08, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:43:45AM +0200, Jan Beulich wrote:
>> When a page table ends up with all contiguous entries (including all
>> identical attributes), it can be replaced by a superpage entry at the
>> next higher level. The page table itself
On 10.05.2022 17:31, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:43:16AM +0200, Jan Beulich wrote:
>> @@ -94,11 +95,15 @@ static union amd_iommu_pte set_iommu_pte
>> old.iw != iw || old.ir != ir )
>> {
>> set_iommu_pde_present(pde, next_mfn, 0, iw, ir);
>> -
On 18/05/2022 10:09, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 13.05.2022 17:39, Roger Pau Monné wrote:
>> On Wed, May 11, 2022 at 04:14:23PM +0100, Jane Malalane
> On 18 May 2022, at 11:12, Andrew Cooper wrote:
>
> On 18/05/2022 10:51, Edwin Torok wrote:
>>> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
>>> index 7503031d8f61..8eab6f60eb14 100644
>>> --- a/tools/ocaml/libs/xc/xenctrl.ml
>>> +++
Hi Andrew,
> On 17 May 2022, at 20:41, Andrew Cooper wrote:
>
> c/s cfc52148444f ("xen/domain: Reduce the quantity of initialisation for
> system domains") removed the path in domain_create() which called
> sched_init_domain() with CPUPOOLID_NONE for system domains.
>
> Arguably, that
On 10.05.2022 16:30, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote:
>> When a page table ends up with no present entries left, it can be
>> replaced by a non-present entry at the next higher level. The page table
>> itself can then be scheduled for freeing.
On 17.05.22 21:41, Andrew Cooper wrote:
c/s cfc52148444f ("xen/domain: Reduce the quantity of initialisation for
system domains") removed the path in domain_create() which called
sched_init_domain() with CPUPOOLID_NONE for system domains.
Arguably, that changeset should have cleaned up this
Hi Jan,
> -Original Message-
> From: Jan Beulich
>
> On 18.05.2022 11:51, Henry Wang wrote:
> >> -Original Message-
> >> From: Jan Beulich
> >>
> >> On 17.05.2022 17:31, Roger Pau Monne wrote:
> >>> Roger Pau Monne (3):
> >>> amd/msr: implement VIRT_SPEC_CTRL for HVM guests
On 10.05.2022 15:30, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:42:19AM +0200, Jan Beulich wrote:
>> When a page table ends up with no present entries left, it can be
>> replaced by a non-present entry at the next higher level. The page table
>> itself can then be scheduled for freeing.
On 18/05/2022 10:51, Edwin Torok wrote:
>> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
>> index 7503031d8f61..8eab6f60eb14 100644
>> --- a/tools/ocaml/libs/xc/xenctrl.ml
>> +++ b/tools/ocaml/libs/xc/xenctrl.ml
>> @@ -85,6 +85,7 @@ type domctl_create_config =
>>
On 18.05.2022 11:51, Henry Wang wrote:
>> -Original Message-
>> From: Jan Beulich
>>
>> On 17.05.2022 17:31, Roger Pau Monne wrote:
>>> Roger Pau Monne (3):
>>> amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of
>> SPEC_CTRL
>>> amd/msr: allow passthrough of VIRT_SPEC_CTRL for
On 06.05.2022 15:25, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:41:23AM +0200, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/pt-contig-markers.h
>> @@ -0,0 +1,105 @@
>> +#ifndef __ASM_X86_PT_CONTIG_MARKERS_H
>> +#define __ASM_X86_PT_CONTIG_MARKERS_H
>> +
>> +/*
>>
> On 17 May 2022, at 20:41, Andrew Cooper wrote:
>
> Sadly, cpupool IDs are chosen by the caller, not assigned sequentially, so
> this does need to have a full 32 bits of range.
>
> Also leave a BUILD_BUG_ON() to catch more obvious ABI changes in the future.
>
> Fixes: 92ea9c54fc81
Hi Jan, Roger and Andrew,
> -Original Message-
> From: Jan Beulich
>
> On 17.05.2022 17:31, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series implements support for MSR_VIRT_SPEC_CTRL
> > (VIRT_SSBD) on different AMD CPU families.
> >
> > Note that the support is added
On 18.05.2022 11:45, Juergen Gross wrote:
> BTW, the question regarding patches 1, 2 and 4 to go in as being cleanups
> still stands.
I would long have committed these (without waiting for Andrew), but patch 1
continues to lack an x86 side ack (which, as indicated before, I'm not
happy to
On 04.05.22 09:53, Juergen Gross wrote:
On 19.04.22 10:01, Juergen Gross wrote:
On 24.03.22 15:01, Juergen Gross wrote:
In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall
On 17.05.2022 17:31, Roger Pau Monne wrote:
> Hello,
>
> The following series implements support for MSR_VIRT_SPEC_CTRL
> (VIRT_SSBD) on different AMD CPU families.
>
> Note that the support is added backwards, starting with the newer CPUs
> that support MSR_SPEC_CTRL and moving to the older
On 07.05.22 00:32, Jarkko Sakkinen wrote:
On Thu, May 05, 2022 at 10:16:34AM +0200, Juergen Gross wrote:
Simplify tpmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
Please add to the commit message why these provide an
On 17.05.2022 19:07, Demi Marie Obenour wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -39,6 +39,25 @@
>{ 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b,
> 0x23} }
> #define APPLE_PROPERTIES_PROTOCOL_GUID \
>{ 0x91bd12fe, 0xf6c3, 0x44fb, {
flight 170533 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170533/
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 13.05.2022 17:39, Roger Pau Monné wrote:
> On Wed, May 11, 2022 at 04:14:23PM +0100, Jane Malalane wrote:
>> Have is_hvm_pv_evtchn_vcpu() return true for vector callbacks for
>> evtchn delivery set up on a per-vCPU basis via
>> HVMOP_set_evtchn_upcall_vector.
>>
>> is_hvm_pv_evtchn_vcpu()
On 11.05.2022 17:14, Jane Malalane wrote:
> Have is_hvm_pv_evtchn_vcpu() return true for vector callbacks for
> evtchn delivery set up on a per-vCPU basis via
> HVMOP_set_evtchn_upcall_vector.
I'm confused: You say "per-vCPU" here, but ...
> --- a/xen/arch/x86/include/asm/domain.h
> +++
On 16.05.2022 16:31, Roger Pau Monne wrote:
> --- a/xen/arch/x86/include/asm/flushtlb.h
> +++ b/xen/arch/x86/include/asm/flushtlb.h
> @@ -146,7 +146,8 @@ void flush_area_mask(const cpumask_t *, const void *va,
> unsigned int flags);
> #define flush_mask(mask, flags) flush_area_mask(mask, NULL,
flight 170523 linux-linus real [real]
flight 170530 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170523/
http://logs.test-lab.xenproject.org/osstest/logs/170530/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Acked-by: Christian Lindig
mailto:christian.lin...@citrix.com>>
On 17 May 2022, at 20:41, Andrew Cooper
mailto:andrew.coop...@citrix.com>> wrote:
Sadly, cpupool IDs are chosen by the caller, not assigned sequentially, so
this does need to have a full 32 bits of range.
Also leave a
On Tue 2022-05-17 15:57:34, Petr Mladek wrote:
> On Mon 2022-05-16 12:06:17, Guilherme G. Piccoli wrote:
> > >> --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c
> > >> +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c
> > >> @@ -814,7 +814,7 @@ static int brcmstb_pm_probe(struct platform_device
> > >> *pdev)
>
flight 170531 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170531/
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 Tue 2022-05-17 13:42:06, Guilherme G. Piccoli wrote:
> On 17/05/2022 10:57, Petr Mladek wrote:
> >> Disagree here, I'm CCing Florian for information.
> >>
> >> This notifier preserves RAM so it's *very interesting* if we have
> >> kmsg_dump() for example, but maybe might be also relevant in
Hi Stefano,
On 18/05/2022 04:12, Stefano Stabellini wrote:
On Tue, 17 May 2022, Jan Beulich wrote:
Hmm. The present rules written down in docs/process/sending-patches.pandoc
are a result of me having been accused of unduly stripping S-o-b (and maybe
a few other) tags. If that was for a real
On Tue 2022-05-17 13:37:58, Guilherme G. Piccoli wrote:
> On 17/05/2022 10:28, Petr Mladek wrote:
> > [...]
> >>> Disagree here. I'm looping Google maintainers, so they can comment.
> >>> (CCed Evan, David, Julius)
> >>>
> >>> This notifier is clearly a hypervisor notification mechanism. I've
flight 170527 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170527/
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 17.05.22 18:42, Josh Poimboeuf wrote:
On Tue, May 17, 2022 at 04:24:25PM +, Maximilian Heyne wrote:
Since commit 4d65adfcd119 ("x86: xen: insn: Decode Xen and KVM
emulate-prefix signature"), objtool is able to correctly parse the
prefixed instruction in xen_cpuid and emit correct orc
1 - 100 of 105 matches
Mail list logo
