Hi Julien,
> On 6 Sep 2021, at 18:36, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 06/09/2021 09:29, Bertrand Marquis wrote:
>>> On 3 Sep 2021, at 23:49, Stefano Stabellini wrote:
>>>
>>> On Tue, 31 Aug 2021, Bertrand Marquis wrote:
Hi Julien,
> On 31 Aug 2021, at 15:47, Julien
On 06.09.21 17:55, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -811,6 +811,16 @@ int vpci_bar_add_handlers(const struct domain *d,
>> struct pci_dev *pdev)
>> gprintk(XENLOG_ERR,
>>
On 06.09.2021 18:13, Anthony PERARD wrote:
> On Tue, Aug 24, 2021 at 11:49:47AM +0100, Anthony PERARD wrote:
>> build,arm: move LDFLAGS change to arch.mk
> need edit commit description, but otherwise ready
> not needed before [PATCH 21/51] build: set ALL_OBJS to main Makefile;
> move prelink
On 06.09.21 23:35, Sander Eikelenboom wrote:
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I'm encountering some issues in dom0, see below.
--
Sander
xl dmesg gives:
(XEN) [2021-09-06 18:15:04.
On 07.09.2021 09:43, Oleksandr Andrushchenko wrote:
>
> On 06.09.21 17:55, Jan Beulich wrote:
>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -811,6 +811,16 @@ int vpci_bar_add_handlers(const struct domain *d,
>
On 06.09.2021 22:47, Elliott Mitchell wrote:
> On Mon, Sep 06, 2021 at 09:52:17AM +0200, Jan Beulich wrote:
>> On 06.09.2021 00:10, Elliott Mitchell wrote:
>>> I brought this up a while back, but it still appears to be present and
>>> the latest observations appear rather serious.
>>>
>>> I'm unsur
Hi Julien,
> On 06/09/2021 10:04, Hongda Deng wrote:
> > Hi Julien,
>
> Hi Hongda,
>
> > Xen provides vGIC to support Xen guests, and currently xen will return IO
> > unhandled when guests access GICD ICPENRn registers. This works fine with
> Linux
> > guests, for Linux won't access these regist
On 07.09.2021 09:58, Juergen Gross wrote:
> On 06.09.21 23:35, Sander Eikelenboom wrote:
>> L.S.,
>>
>> On my AMD box running:
>> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
>> linux kernel: 5.14.1
>>
>> With this setup I'm encountering some issues in dom0, see be
On 07.09.21 10:11, Jan Beulich wrote:
On 07.09.2021 09:58, Juergen Gross wrote:
On 06.09.21 23:35, Sander Eikelenboom wrote:
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I'm encountering some
On 07.09.21 11:00, Jan Beulich wrote:
> On 07.09.2021 09:43, Oleksandr Andrushchenko wrote:
>> On 06.09.21 17:55, Jan Beulich wrote:
>>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -811,6 +811,16 @@ int vpci_
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
pci_init(..) will be called during xen startup to initialize and probe
the PCI host-bridge driver.
Signed-off-by: Rahul Singh
---
xen/arch/arm/pci/pci.c | 54
xen/include/asm-arm/device.h | 1 +
2
Hello, Jan!
On 06.09.21 16:23, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -864,6 +864,10 @@ static int deassign_device(struct domain *d, uint16_t
>> seg, uint8_t bus,
>> if ( re
On 07.09.2021 08:52, Luca Fancellu wrote:
> Add a design describing a proposal to improve the EFI
> configuration file, adding keywords to describe domU
> guests and allowing to start a dom0less system.
>
> Signed-off-by: Luca Fancellu
> ---
> docs/designs/efi-arm-dom0less.md | 105 +
flight 164869 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164869/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a7cf2c5664b9605162b20ab6b51c7bdcab3e14f0
baseline version:
ovmf 4473834e7d49c555eca81
On 07.09.2021 10:33, Oleksandr Andrushchenko wrote:
> On 06.09.21 16:23, Jan Beulich wrote:
>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -864,6 +864,10 @@ static int deassign_device(struct domain *d, ui
On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
>
> On 07.09.21 11:00, Jan Beulich wrote:
>> On 07.09.2021 09:43, Oleksandr Andrushchenko wrote:
>>> On 06.09.21 17:55, Jan Beulich wrote:
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/
Hi Oleksandr,
> -Original Message-
> From: Xen-devel On Behalf Of
> Oleksandr Tyshchenko
> Sent: Thursday, July 29, 2021 12:19 AM
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Daniel De
> Graaf ; Daniel P. Smith
> ; Ian Jackson ; Wei
> Liu ; Andrew Cooper ; George
> Du
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
XEN during boot will read the PCI device tree node “reg” property
and will map the PCI config space to the XEN memory.
As of now "pci-host-ecam-generic" compatible board is supported.
I think the word "only" is missing.
"linux,pci-domain" d
On 07.09.21 11:49, Jan Beulich wrote:
> On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
>> On 07.09.21 11:00, Jan Beulich wrote:
>>> On 07.09.2021 09:43, Oleksandr Andrushchenko wrote:
On 06.09.21 17:55, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> -
Hi,
On 07/09/2021 09:33, Jan Beulich wrote:
On 07.09.2021 08:52, Luca Fancellu wrote:
Add a design describing a proposal to improve the EFI
configuration file, adding keywords to describe domU
guests and allowing to start a dom0less system.
Signed-off-by: Luca Fancellu
---
docs/designs/efi-
On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
> On 07.09.21 11:49, Jan Beulich wrote:
>> On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
>>> So, if we have a hidden PCI device which can be assigned to a guest and it
>>> is literally untouched
>>> (not enabled in Dom0) then I think there
On 07.09.2021 11:17, Julien Grall wrote:
> On 07/09/2021 09:33, Jan Beulich wrote:
>> I'd like to suggest a different scheme, not the least because I expect
>> the individual domains being independent of e.g. hypervisor command
>> line options or Dom0 kernel versions. Yet varying sets of these are,
Hi Luca,
On 07/09/2021 07:52, Luca Fancellu wrote:
Add a design describing a proposal to improve the EFI
configuration file, adding keywords to describe domU
guests and allowing to start a dom0less system.
Signed-off-by: Luca Fancellu
---
docs/designs/efi-arm-dom0less.md | 105 ++
On 07.09.21 12:19, Jan Beulich wrote:
> On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
>> On 07.09.21 11:49, Jan Beulich wrote:
>>> On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
So, if we have a hidden PCI device which can be assigned to a guest and it
is literally untouched
On 19/08/2021 15:16, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
Sorry for the late reply.
On 19 Aug 2021, at 1:18 pm, Julien Grall wrote:
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
MSI code that implements MSI functionality to support MSI within XEN is
not usable on ARM. Move the
In order to try to debug hypervisor side breakage from XSA-378 I found
myself urged to finally give PVH Dom0 a try. Sadly things didn't work
quite as expected. In the course of investigating these issues I actually
spotted one piece of PV Dom0 breakage as well, a fix for which is also
included here
On 06.09.21 16:53, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is in preparation for dynamic assignment of the vpci register
>> handlers depending on the domain: hwdom or guest.
> I guess why exactly this is going to help is
On 07.09.2021 11:52, Oleksandr Andrushchenko wrote:
>
> On 07.09.21 12:19, Jan Beulich wrote:
>> On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
>>> On 07.09.21 11:49, Jan Beulich wrote:
On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
> So, if we have a hidden PCI device which can
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared.
Hence this variable also needs to be prevented from getting put in .bss,
which is possible because XEN_NATIVE is an enumerator evaluating to
zero. Any use prior to init_hvm_pv_info() setting the variable again
would lead to wr
Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0
to a new XEN_PV_DOM0. (I'm not convinced all are really / should really
be PV-specific, but for starters I've tried to be conservative.)
For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so
without x2APIC s
The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).
While there also bail from the function when the first
domU_write_
With preferred consoles "tty" and "hvc" announced as preferred,
registering "xenboot" early won't result in use of the console: It also
needs to be registered as preferred. Generalize this from being DomU-
only so far.
Signed-off-by: Jan Beulich
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/x
xenboot_write_console() is dealing with these quite fine so I don't see
why xenboot_console_setup() would return -ENOENT in this case.
Adjust documentation accordingly.
Signed-off-by: Jan Beulich
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parame
Without announcing hvc0 as preferred it won't get used as long as tty0
gets registered earlier. This is particularly problematic with there not
being any screen output for PVH Dom0 when the screen is in graphics
mode, as the necessary information doesn't get conveyed yet from the
hypervisor.
Follo
On 06.09.21 17:11, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> @@ -593,6 +625,36 @@ static int init_bars(struct pci_dev *pdev)
>> }
>> REGISTER_VPCI_INIT(init_bars, VPCI_PRIORITY_MIDDLE);
>>
>> +int vpci_bar_add_handlers(const struct domain *d, struct pci_dev
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a PV-only feature.
Signed-off-by: Jan Beul
Two of the variables can live in .init.data, allowing the open-coded
placing in .data to go away. Another "variable" is used to communicate a
size value only to very early assembly code, which hence can be both
const and live in .init.*. Additionally two functions were lacking
__init annotations.
Both xen_pvh and xen_start_flags get written just once aeryl during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.
Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be used from modules.
Signed-off-by: Jan Beul
On 07.09.2021 12:11, Oleksandr Andrushchenko wrote:
> On 06.09.21 17:11, Jan Beulich wrote:
>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>>> @@ -593,6 +625,36 @@ static int init_bars(struct pci_dev *pdev)
>>> }
>>> REGISTER_VPCI_INIT(init_bars, VPCI_PRIORITY_MIDDLE);
>>>
>>> +int v
flight 164870 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164870/
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
flight 164866 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164866/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164848
test-armhf-armhf-libvirt 16 save
On 07.09.21 13:43, Jan Beulich wrote:
> On 07.09.2021 12:11, Oleksandr Andrushchenko wrote:
>> On 06.09.21 17:11, Jan Beulich wrote:
>>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
@@ -593,6 +625,36 @@ static int init_bars(struct pci_dev *pdev)
}
REGISTER_VPCI_INIT(ini
> On 7 Sep 2021, at 10:24, Jan Beulich wrote:
>
> On 07.09.2021 11:17, Julien Grall wrote:
>> On 07/09/2021 09:33, Jan Beulich wrote:
>>> I'd like to suggest a different scheme, not the least because I expect
>>> the individual domains being independent of e.g. hypervisor command
>>> line opti
On 07.09.2021 13:10, Oleksandr Andrushchenko wrote:
>
> On 07.09.21 13:43, Jan Beulich wrote:
>> On 07.09.2021 12:11, Oleksandr Andrushchenko wrote:
>>> On 06.09.21 17:11, Jan Beulich wrote:
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> @@ -593,6 +625,36 @@ static int init_bars(st
flight 164872 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164872/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> On 7 Sep 2021, at 10:35, Julien Grall wrote:
>
> Hi Luca,
>
> On 07/09/2021 07:52, Luca Fancellu wrote:
>> Add a design describing a proposal to improve the EFI
>> configuration file, adding keywords to describe domU
>> guests and allowing to start a dom0less system.
>> Signed-off-by: Luca
Hi,
I have not covered all your comments below yet.
So just one comment:
On Mon, Sep 06, 2021 at 05:57:43PM -0700, Christopher Clark wrote:
> On Thu, Sep 2, 2021 at 12:19 AM AKASHI Takahiro
> wrote:
(snip)
> >It appears that, on FE side, at least three hypervisor calls (and data
> >cop
On 07.09.2021 13:51, Luca Fancellu wrote:
>> On 7 Sep 2021, at 10:35, Julien Grall wrote:
>> On 07/09/2021 07:52, Luca Fancellu wrote:
>>> --- /dev/null
>>> +++ b/docs/designs/efi-arm-dom0less.md
>>> @@ -0,0 +1,105 @@
>>> +# Xen EFI configuration file
>>> +
>>> +The current configuration file used
The primary intention really was the last patch, there you go ...
01: swiotlb-xen: avoid double free
02: swiotlb-xen: fix late init retry
03: swiotlb-xen: maintain slab count properly
04: swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests
05: swiotlb-xen: suppress certain init retri
Of the two paths leading to the "error" label in xen_swiotlb_init() one
didn't allocate anything, while the other did already free what was
allocated.
Fixes: b82776005369 ("xen/swiotlb: Use the swiotlb_late_init_with_tbl to init
Xen-SWIOTLB late when PV PCI is used")
Signed-off-by: Jan Beulich
C
The commit referenced below removed the assignment of "bytes" from
xen_swiotlb_init() without - like done for xen_swiotlb_init_early() -
adding an assignment on the retry path, thus leading to excessively
sized allocations upon retries.
Fixes: 2d29960af0be ("swiotlb: dynamically allocate io_tlb_de
Generic swiotlb code makes sure to keep the slab count a multiple of the
number of slabs per segment. Yet even without checking whether any such
assumption is made elsewhere, it is easy to see that xen_swiotlb_fixup()
might alter unrelated memory when calling xen_create_contiguous_region()
for the
While the hypervisor hasn't been enforcing this, we would still better
avoid issuing requests with GFNs not aligned to the requested order.
Signed-off-by: Jan Beulich
---
I wonder how useful it is to include the alignment in the panic()
message. I further wonder how useful it is to wrap "bytes" i
Only on the 2nd of the paths leading to xen_swiotlb_init()'s "error"
label it is useful to retry the allocation; the first one did already
iterate through all possible order values.
Signed-off-by: Jan Beulich
---
I'm not convinced of the (lack of) indentation of the label, but I made
the new one
Due to the use of max(1024, ...) there's no point retrying (and issuing
bogus log messages) when the number of slabs is already no larger than
this minimum value.
Signed-off-by: Jan Beulich
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -207,7 +207,7 @@ retry:
swiotlb
Commit a98f565462f0 ("xen-swiotlb: split xen_swiotlb_init") should not
only have added __init to the split off function, but also should have
dropped __ref from the one left.
Signed-off-by: Jan Beulich
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -154,7 +154,7 @@ static con
I consider it unhelpful that address and size of the buffer aren't put
in the log file; it makes diagnosing issues needlessly harder. The
majority of callers of swiotlb_init() also passes 1 for the "verbose"
parameter.
Signed-off-by: Jan Beulich
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen
It was introduced by 4035b43da6da ("xen-swiotlb: remove xen_set_nslabs")
and then not removed by 2d29960af0be ("swiotlb: dynamically allocate
io_tlb_default_mem").
Signed-off-by: Jan Beulich
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -152,8 +152,6 @@ static const char *xe
It's module init function does a xen_pv_domain() check first thing.
Hence there's no point building it in non-PV configurations.
Signed-off-by: Jan Beulich
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -110,7 +110,7 @@ config PCI_PF_STUB
config XEN_PCIDEV_FRONTEND
tristate "X
xen_swiotlb and pci_xen_swiotlb_init() are only used within the file
defining them, so make them static and remove the stubs. Otoh
pci_xen_swiotlb_detect() has a use (as function pointer) from the main
pci-swiotlb.c file - convert its stub to a #define to NULL.
Signed-off-by: Jan Beulich
--- a/a
The code is unreachable for HVM or PVH, and it also makes little sense
in auto-translated environments. On Arm, with
xen_{create,destroy}_contiguous_region() both being stubs, I have a hard
time seeing what good the Xen specific variant does - the generic one
ought to be fine for all purposes there
On 07.09.21 14:49, Jan Beulich wrote:
> On 07.09.2021 13:10, Oleksandr Andrushchenko wrote:
>> On 07.09.21 13:43, Jan Beulich wrote:
>>> On 07.09.2021 12:11, Oleksandr Andrushchenko wrote:
On 06.09.21 17:11, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> @
It's not clear to me why only the frontend has been tristate. Switch the
backend to be, too.
Signed-off-by: Jan Beulich
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -214,7 +214,7 @@ config XEN_PVCALLS_FRONTEND
implements them.
config XEN_PVCALLS_BACKEND
- bool "XEN P
On 07.09.2021 14:16, Oleksandr Andrushchenko wrote:
>
> On 07.09.21 14:49, Jan Beulich wrote:
>> On 07.09.2021 13:10, Oleksandr Andrushchenko wrote:
>>> On 07.09.21 13:43, Jan Beulich wrote:
On 07.09.2021 12:11, Oleksandr Andrushchenko wrote:
> On 06.09.21 17:11, Jan Beulich wrote:
>>
On 02/09/2021 08:01, Jan Beulich wrote:
> The initial if() was inverted, invalidating all output from this
> function. Which in turn means the mirroring of P2M mappings into the
> IOMMU didn't always work as intended: Mappings may have got updated when
> there was no need to. There would not have b
On 07.09.21 15:20, Jan Beulich wrote:
> On 07.09.2021 14:16, Oleksandr Andrushchenko wrote:
>> On 07.09.21 14:49, Jan Beulich wrote:
>>> On 07.09.2021 13:10, Oleksandr Andrushchenko wrote:
On 07.09.21 13:43, Jan Beulich wrote:
> On 07.09.2021 12:11, Oleksandr Andrushchenko wrote:
>> O
On 07/09/2021 12:51, Luca Fancellu wrote:
On 7 Sep 2021, at 10:35, Julien Grall wrote:
Hi Luca,
On 07/09/2021 07:52, Luca Fancellu wrote:
Add a design describing a proposal to improve the EFI
configuration file, adding keywords to describe domU
guests and allowing to start a dom0less sy
Hi Julien and Stefano
I found that the "cc-option/cc-option-add" is not working for "-march=xxx"
option on a few very common aarch64 compilers.
Here is what I got when trying to compile XEN on r82 platform.
```
diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
index 11caec86ba..d2d71baef4
On 9/7/21 2:00 AM, Jan Beulich wrote:
On 06.09.2021 18:22, Andrew Cooper wrote:
On 06/09/2021 16:52, Jan Beulich wrote:
On 03.09.2021 21:06, Daniel P. Smith wrote:
--- /dev/null
+++ b/xen/include/xen/alternative-call.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef XEN_AL
On 07/09/2021 07:09, Jan Beulich wrote:
> On 06.09.2021 20:07, Andrew Cooper wrote:
>> On 06/09/2021 16:17, Jan Beulich wrote:
>>> On 06.09.2021 14:00, Jane Malalane wrote:
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -681,6 +681,19 @@ void amd_init_lfence(struct cpui
> On 7 Sep 2021, at 13:30, Julien Grall wrote:
>
>
>
> On 07/09/2021 12:51, Luca Fancellu wrote:
>>> On 7 Sep 2021, at 10:35, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 07/09/2021 07:52, Luca Fancellu wrote:
Add a design describing a proposal to improve the EFI
configuratio
On 06.09.21 17:31, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -400,12 +400,72 @@ static void bar_write(const struct pci_dev *pdev,
>> unsigned int reg,
>> static void guest_bar_write(const
On 9/6/21 2:17 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
Instead of intermixing coding style changes with code changes as they
are come upon in this patch set, moving all coding style changes
into a single commit. The focus of coding style changes here are,
- move t
On 9/6/21 2:31 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
This renames the `struct xsm_operations` to the shorter `struct xsm_ops` and
converts the global xsm_ops from being a pointer to an explicit instance. As
part of this conversion, it reworks the XSM modules ini
On 07.09.2021 15:41, Daniel P. Smith wrote:
> On 9/6/21 2:17 PM, Andrew Cooper wrote:
>> On 03/09/2021 20:06, Daniel P. Smith wrote:
>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>> @@ -69,8 +69,9 @@ void __xsm_action_mismatch_detected(void);
>>>
>>> #endif /* CONFIG_XSM
On 06.09.21 23:35, Sander Eikelenboom wrote:
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I'm encountering some issues in dom0, see below.
Could you test whether the attached patch (only compil
On 9/6/21 2:47 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
diff --git a/xen/include/xsm/xsm-core.h b/xen/include/xsm/xsm-core.h
new file mode 100644
index 00..4555e111dc
--- /dev/null
+++ b/xen/include/xsm/xsm-core.h
@@ -0,0 +1,274 @@
+/*
+ * This file contains
On 9/6/21 2:55 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
SILO implements a few XSM hooks to extended the decision logic beyond
what is defined in the dummy/default policy. For each of the hooks, it
falls back to the dummy/default policy. The fall back is done a slight
On 9/6/21 3:18 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
-static inline int xsm_memtype(xsm_default_t def, uint32_t access)
+#if 0
+/* Could not find any usages */
+static inline int xsm_memtype(xsm_default_t action, uint32_t access)
{
return alternative_call(x
On 9/7/21 9:50 AM, Jan Beulich wrote:
On 07.09.2021 15:41, Daniel P. Smith wrote:
On 9/6/21 2:17 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -69,8 +69,9 @@ void __xsm_action_mismatch_detected(void);
Hi Luca,
On 07/09/2021 14:30, Luca Fancellu wrote:
On 7 Sep 2021, at 13:30, Julien Grall wrote:
On 07/09/2021 12:51, Luca Fancellu wrote:
On 7 Sep 2021, at 10:35, Julien Grall wrote:
What we could do is providing a list of binaries to load and associate a key
for each of them. Something like
On 07.09.2021 15:27, Andrew Cooper wrote:
> On 07/09/2021 07:09, Jan Beulich wrote:
>> On 06.09.2021 20:07, Andrew Cooper wrote:
>>> On 06/09/2021 16:17, Jan Beulich wrote:
On 06.09.2021 14:00, Jane Malalane wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@
(dropping most CC)
On Tue, Aug 24, 2021 at 11:49:51AM +0100, Anthony PERARD wrote:
> In Arm and X86 makefile, generating the linker script is the same, so
> we can simply have both call the same macro.
>
> We need to add *.lds files into extra-y so that Rules.mk can find the
> .*.cmd dependency f
On 07.09.2021 16:09, Daniel P. Smith wrote:
> On 9/7/21 9:50 AM, Jan Beulich wrote:
>> On 07.09.2021 15:41, Daniel P. Smith wrote:
>>> On 9/6/21 2:17 PM, Andrew Cooper wrote:
On 03/09/2021 20:06, Daniel P. Smith wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
>>>
On 24/08/2021 14:15, Jan Beulich wrote:
> On 24.08.2021 14:57, Andrew Cooper wrote:
>> On 19/08/2021 15:38, Jan Beulich wrote:
>>> On 17.08.2021 16:30, Andrew Cooper wrote:
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -317,23 +317,30 @@ static void __init print_de
On 9/7/21 10:27 AM, Jan Beulich wrote:
> On 07.09.2021 16:09, Daniel P. Smith wrote:
>> On 9/7/21 9:50 AM, Jan Beulich wrote:
>>> On 07.09.2021 15:41, Daniel P. Smith wrote:
On 9/6/21 2:17 PM, Andrew Cooper wrote:
> On 03/09/2021 20:06, Daniel P. Smith wrote:
>> --- a/xen/include/xsm/d
> On 7 Sep 2021, at 15:18, Julien Grall wrote:
>
> Hi Luca,
>
> On 07/09/2021 14:30, Luca Fancellu wrote:
>>> On 7 Sep 2021, at 13:30, Julien Grall wrote:
>>> On 07/09/2021 12:51, Luca Fancellu wrote:
> On 7 Sep 2021, at 10:35, Julien Grall wrote:
> What we could do is providing a l
On 07.09.2021 16:55, Daniel P. Smith wrote:
> On 9/7/21 10:27 AM, Jan Beulich wrote:
>> On 07.09.2021 16:09, Daniel P. Smith wrote:
>>> On 9/7/21 9:50 AM, Jan Beulich wrote:
On 07.09.2021 15:41, Daniel P. Smith wrote:
> On 9/6/21 2:17 PM, Andrew Cooper wrote:
>> On 03/09/2021 20:06, Da
On Tue, Sep 07, 2021 at 10:03:51AM +0200, Jan Beulich wrote:
> On 06.09.2021 22:47, Elliott Mitchell wrote:
> > On Mon, Sep 06, 2021 at 09:52:17AM +0200, Jan Beulich wrote:
> >> On 06.09.2021 00:10, Elliott Mitchell wrote:
> >>> I brought this up a while back, but it still appears to be present and
Update subject to follow conventions (use "git log --oneline
drivers/pci/Kconfig"). Should say what this patch does.
Commit log below should also say what this patch does. Currently it's
part of the rationale for the change, but doesn't say what the patch
does.
On Tue, Sep 07, 2021 at 02:10:41P
On 07.09.2021 17:03, Elliott Mitchell wrote:
> On Tue, Sep 07, 2021 at 10:03:51AM +0200, Jan Beulich wrote:
>> On 06.09.2021 22:47, Elliott Mitchell wrote:
>>> On Mon, Sep 06, 2021 at 09:52:17AM +0200, Jan Beulich wrote:
On 06.09.2021 00:10, Elliott Mitchell wrote:
> I brought this up a wh
On 24/08/2021 16:15, Jan Beulich wrote:
> On 24.08.2021 15:26, Andrew Cooper wrote:
>> On 19/08/2021 15:47, Jan Beulich wrote:
>>> On 17.08.2021 16:30, Andrew Cooper wrote:
There is a step change in speculation protections between the Zen1 and Zen2
microarchitectures.
Zen1 and o
On 07.09.2021 17:30, Bjorn Helgaas wrote:
> Update subject to follow conventions (use "git log --oneline
> drivers/pci/Kconfig"). Should say what this patch does.
I can change that; I don't think it'll carry any different information.
> Commit log below should also say what this patch does. Cur
The opencoded legacy Memory Disambiguation logic in init_amd() neglected
Fam19h for the Zen3 microarchitecture. In practice, all Zen2 based system
have the architectural MSR_SPEC_CTRL and the SSBD bit within it.
Implement the algorithm given in AMD's SSBD whitepaper, and leave a
printk_once() beh
flight 164875 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164875/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 07.09.2021 15:33, Oleksandr Andrushchenko wrote:
> On 06.09.21 17:31, Jan Beulich wrote:
>> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -400,12 +400,72 @@ static void bar_write(const struct pci_dev *pdev,
>>>
On Tue, Sep 07, 2021 at 06:14:16PM +0200, Jan Beulich wrote:
> On 07.09.2021 17:30, Bjorn Helgaas wrote:
> > Update subject to follow conventions (use "git log --oneline
> > drivers/pci/Kconfig"). Should say what this patch does.
>
> I can change that; I don't think it'll carry any different info
flight 164871 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest address
space size to the toolstack on Arm in order to properly
calculate the base and size of the extended region (safe range)
for the guest. The extended region is unused address space which
could be safely used by do
From: Oleksandr Tyshchenko
You can find an initial discussion at [1].
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain memory for establishing t
1 - 100 of 124 matches
Mail list logo
