arch/x86/xen/multicalls.c:102
> xen_mc_flush+0x176/0x1a0
> [34321.304288] Modules linked in:
> [34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted
> 5.14.1-20210906-doflr-mac80211debug+ #1
> [34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
> V1.8B1 09/13/2010
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 +++
1 file changed, 105 insertions(+)
c
On 06.09.21 13:38, Julien Grall wrote:
> Hi Oleksandr,
>
> On 06/09/2021 11:06, Oleksandr Andrushchenko wrote:
>> On 06.09.21 12:53, Julien Grall wrote:
>>> However, looking at the rest of the code, we already have a check for
>>> vpci in the common IOREQ code.
>>
>> Which may not
On 06.09.2021 21:53, Andrew Cooper wrote:
> On 01/09/2021 14:08, Jan Beulich wrote:
> Restricting execute permissions is something unique to virt. It doesn't
> exist in a non-virtualised system, as I and D side reads are
> indistinguishable outside of the core.
>
> Furthermore,
On 06.09.2021 18:13, Anthony PERARD wrote:
> I hope this is useful:
>
> On Tue, Aug 24, 2021 at 11:49:47AM +0100, Anthony PERARD wrote:
>> Anthony PERARD (51):
>> build: introduce cpp_flags macro
>> build: use if_changed on built_in.o
>> build: use if_changed_rules with %.o:%.c targets
>
>
On 24.08.2021 12:49, Anthony PERARD wrote:
> This replace the use of a single .c file use for multiple .o file by
> creating multiple .c file including the first one.
>
> There's quite a few issues with trying to build more than one object
> file from a single source file: there's is a duplication
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 cpuinfo_x86 *c)
>>> c->x86_ca
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_ALTERNATIVE_CALL
>>> +#
flight 164865 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164865/
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-
flight 164867 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164867/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 91d215a4ed1463ab14d1f68e497117ac1255e05e
baseline version:
xtf 0bb720b3c486bd3de62b8c
On 06.09.21 13:23, Jan Beulich wrote:
On 06.09.2021 13:18, Andrew Cooper wrote:
On 06/09/2021 12:14, Andrew Cooper wrote:
On 06/09/2021 12:00, Juergen Gross wrote:
In case a domain is created with a cpupool other than Pool-0 specified
it will be moved to that cpupool before any vcpus are alloc
On 06.09.21 19:07, Rafael J. Wysocki wrote:
On Fri, Sep 3, 2021 at 11:02 AM Juergen Gross wrote:
On 03.09.21 10:56, Greg Kroah-Hartman wrote:
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
In there is no legacy RTC device, don't try to use it for storing trace
data across sus
flight 164864 qemu-mainline real [real]
flight 164868 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164864/
http://logs.test-lab.xenproject.org/osstest/logs/164868/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Hi Stefano
> -Original Message-
> From: Stefano Stabellini
> Sent: Friday, September 3, 2021 5:31 AM
> To: Penny Zheng
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH v5 2/7] xen/arm: introduce doma
Hi Julien and Stefano
> -Original Message-
> From: Julien Grall
> Sent: Friday, September 3, 2021 3:42 PM
> To: Stefano Stabellini
> Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
> Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH v5 7/7] xen/arm: introduce allocate_static_me
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Wednesday, September 1, 2021 4:57 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH v5 1/7] xen/arm: introduce new helper
> device_tree
On Sun, Sep 5, 2021 at 7:24 PM AKASHI Takahiro via Stratos-dev <
stratos-...@op-lists.linaro.org> wrote:
> Alex,
>
> On Fri, Sep 03, 2021 at 10:28:06AM +0100, Alex Benn??e wrote:
> >
> > AKASHI Takahiro writes:
> >
> > > Alex,
> > >
> > > On Wed, Sep 01, 2021 at 01:53:34PM +0100, Alex Benn??e wro
Design Session notes for: VirtIO Cross-Project BoF (Birds of a Feather) for
Xen and Guest OS (Linux, Windows, FreeBSD) developers
---
Xen Design & Developer Summit, 27th May 2021
Session Host: Juergen Gross
Notes by: Christopher Clark, with thanks to Rich Persaud
Apologies
On Thu, Sep 2, 2021 at 12:19 AM AKASHI Takahiro
wrote:
> Hi Christopher,
>
> Thank you for your feedback.
>
> On Mon, Aug 30, 2021 at 12:53:00PM -0700, Christopher Clark wrote:
> > [ resending message to ensure delivery to the CCd mailing lists
> > post-subscription ]
> >
> > Apologies for being
flight 164863 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164863/
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
0x1a0
[34321.304288] Modules linked in:
[34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted
5.14.1-20210906-doflr-mac80211debug+ #1
[34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1
09/13/2010
[34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
[34321.304300] Code:
flight 164860 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164860/
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-
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 unsure of the entire set of conditions for reproduct
On 01/09/2021 14:08, Jan Beulich wrote:
Restricting execute permissions is something unique to virt. It doesn't
exist in a non-virtualised system, as I and D side reads are
indistinguishable outside of the core.
Furthermore, it is inexpressible on some systems/configuratio
On 06/09/2021 01:06, Bhasker C V wrote:
> Hi,
> I have a domU and that domU has network vf attached to it.
> The save and restore leads to crash of the domU after restore.
> Am I doing anything wrong?
xl save/restore really ought to give up early and refuse the operation.
CC-ing the toolstack
On 06/09/2021 16:55, Jan Beulich wrote:
> On 06.09.2021 17:48, Andrew Cooper wrote:
>> On 02/09/2021 09:33, Jan Beulich wrote:
>>> To become independent of the sequence of mapping operations, permit
>>> "access" to accumulate for Dom0, noting that there's not going to be an
>>> introspection agent
On 06/09/2021 13:00, Jane Malalane wrote:
> diff --git a/xen/include/public/arch-x86/cpufeatureset.h
> b/xen/include/public/arch-x86/cpufeatureset.h
> index 380b51b1b3..e5a7c94c78 100644
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -2
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(xsm_ops.memtype, access);
> }
> +
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
> round-about way.
"done in a slight
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 the XSM hook definitions fo
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 init function to return
> their xsm_ops str
flight 164862 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164862/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4473834e7d49c555eca81f96383a1d6d6f5f4bb2
baseline version:
ovmf cae735f61328d64e2e899
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 trailing comments to line above
> -
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 cpuinfo_x86 *c)
>>c->x86_capability);
>> }
>>
>> +void detect_zen2_null_
On 03/09/2021 20:06, Daniel P. Smith wrote:
> The type xsm_op_t masks the use of void pointers. This commit drops the
> xsm_op_t type and
> replaces it and all its uses with an explicit void.
>
> Signed-off-by: Daniel P. Smith
Acked-by: Andrew Cooper
HYPERCALL_xsm_op really ought to be renamed
On 03/09/2021 20:06, Daniel P. Smith wrote:
> On Linux when SELinux is put into permissive mode the descretionary access
> controls are still in place. Whereas for Xen when the enforcing state of flask
> is set to permissive, all operations for all domains would succeed, i.e. it
> does not fall bac
On 06/09/2021 10:09, Michal Orzel wrote:
On 06.09.2021 11:07, Julien Grall wrote:
The rest of the patch looks fine. So I would be happy to deal with the fixes on
commit:
Please do. Thanks.
Pushed. I have also re-wrapped the commit message to 72 characters per line.
Cheers,
--
Julien Gra
flight 164855 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164855/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164834
test-amd64-amd64-qemuu-nested-amd 2
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 Grall wrote:
On 31/08/2021 14:17, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On
On Fri, Sep 3, 2021 at 11:02 AM Juergen Gross wrote:
>
> On 03.09.21 10:56, Greg Kroah-Hartman wrote:
> > On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
> >> In there is no legacy RTC device, don't try to use it for storing trace
> >> data across suspend/resume.
> >>
> >> Cc:
> >>
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_ALTERNATIVE_CALL
>> +#define XEN_ALTERNATIVE_CALL
>> +
>> +/*
>> + * Some
I hope this is useful:
On Tue, Aug 24, 2021 at 11:49:47AM +0100, Anthony PERARD wrote:
> Anthony PERARD (51):
> build: introduce cpp_flags macro
> build: use if_changed on built_in.o
> build: use if_changed_rules with %.o:%.c targets
all 3 ready to commit
> build: factorise generation of
On 06.09.2021 17:48, Andrew Cooper wrote:
> On 02/09/2021 09:33, Jan Beulich wrote:
>> To become independent of the sequence of mapping operations, permit
>> "access" to accumulate for Dom0, noting that there's not going to be an
>> introspection agent for it which this might interfere with. While
On 02/09/2021 09:32, Jan Beulich wrote:
> One of the changes comprising the fixes for XSA-378 disallows replacing
> MMIO mappings by code paths not intended for this purpose. At least in
> the case of PVH Dom0 hitting an RMRR covered by an E820 ACPI region,
> this is too strict. Generally short-cir
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_ALTERNATIVE_CALL
> +#define XEN_ALTERNATIVE_CALL
> +
> +/*
> + * Some subsystems in Xen may have multiple implementions,
On 02/09/2021 09:33, Jan Beulich wrote:
> To become independent of the sequence of mapping operations, permit
> "access" to accumulate for Dom0, noting that there's not going to be an
> introspection agent for it which this might interfere with. While e.g.
> ideally only ROM regions would get mappe
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 cpuinfo_x86 *c)
> c->x86_capability);
> }
>
> +void detect_zen2_null_seg_behaviour(void)
This can in principle be ma
On 06.09.2021 14:00, Jane Malalane wrote:
> AMD Zen3 adds the NullSelectorClearsBase bit to indicate that loading
> a NULL segment selector zeroes the base and limit fields, as well as
> just attributes.
>
> Expose bit to all guests.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jane Malalane
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> From: Rahul Singh
>
> Fixes: 9c244fdef7e7 ("vpci: add header handlers")
In which way is that original change broken? The title doesn't
clarify this, and the description is empty ...
Jan
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,
> "%pp: failed to add BAR handlers fo
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> @@ -37,12 +41,28 @@ static int map_range(unsigned long s, unsigned long e,
> void *data,
> unsigned long *c)
> {
> const struct map_data *map = data;
> +gfn_t start_gfn;
> int rc;
>
> for ( ; ; )
>
flight 164861 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 164674
build-amd64
On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Instead of handling a single range set, that contains all the memory
> regions of all the BARs and ROM, have them per BAR.
Without looking at how you carry out this change - this look wrong (as
in: wasteful)
On 06.09.2021 16:05, Andrew Cooper wrote:
> On 26/08/2021 11:09, Jan Beulich wrote:
>> By default all guests are permitted to have up to 1024 maptrack frames,
>> which on 64-bit means an 8k frame table. Yet except for driver domains
>> guests normally don't make use of grant mappings. Defer allocat
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 struct pci_dev *pdev, unsigned int reg,
>
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 *pdev)
> +{
> +int rc;
> +
> +/* Remove
On 26/08/2021 11:09, Jan Beulich wrote:
> By default all guests are permitted to have up to 1024 maptrack frames,
> which on 64-bit means an 8k frame table. Yet except for driver domains
> guests normally don't make use of grant mappings. Defer allocating the
> table until a map track handle is fir
On 06.09.2021 15:35, Julien Grall wrote:
> On 26/08/2021 11:12, Jan Beulich wrote:
>> In all cases call the function just once instead of up to four times, at
>
> extra NIT: It is more like two because there is a else in
> gnttab_release_mappings() :)
Well, I was viewing things from code gen pov
On 06.09.2021 15:33, Julien Grall wrote:
> On 06/09/2021 14:29, Jan Beulich wrote:
>> On 06.09.2021 15:13, Julien Grall wrote:
>>> On 26/08/2021 11:09, Jan Beulich wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -633,6 +633,34 @@ get_maptrack_handle(
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 going to be seen in
subsequent patches. To a
From: Oleksandr Tyshchenko
Allocate anonymous domheap pages as there is no strict need to
account them to a particular domain.
Since XSA-383 "xen/arm: Restrict the amount of memory that dom0less
domU and dom0 can allocate" the dom0 cannot allocate memory outside
of the pre-allocated region. This
Hi Jan,
On 26/08/2021 11:13, Jan Beulich wrote:
Like done in gnttab_setup_table(), check the handle once early in the
function and use the lighter-weight (for PV) copying function in the
loop.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Cheers,
--- a/xen/common/grant_table.c
++
Hi Jan,
On 26/08/2021 11:12, Jan Beulich wrote:
In all cases call the function just once instead of up to four times, at
extra NIT: It is more like two because there is a else in
gnttab_release_mappings() :)
the same time avoiding to store a dangling pointer in a local variable.
Signed-of
Hi Jan,
On 06/09/2021 14:29, Jan Beulich wrote:
On 06.09.2021 15:13, Julien Grall wrote:
On 26/08/2021 11:09, Jan Beulich wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -633,6 +633,34 @@ get_maptrack_handle(
if ( likely(handle != INVALID_MAPTRACK_HANDLE) )
On 06.09.2021 15:13, Julien Grall wrote:
> On 26/08/2021 11:09, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -633,6 +633,34 @@ get_maptrack_handle(
>> if ( likely(handle != INVALID_MAPTRACK_HANDLE) )
>> return handle;
>>
>> +if
flight 164859 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164859/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 164674
build-amd64
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 ( ret )
> goto out;
>
> +ret = vpci_deassign_dev
flight 164850 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164850/
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-
Hi Jan,
On 26/08/2021 11:11, Jan Beulich wrote:
This gnttab_host_mapping_get_page_type() invocation sits in the "else"
path of a conditional controlled by "map->flags & GNTMAP_readonly".
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/common/grant_table.c
+++ b/xen/co
Hi Jan,
On 26/08/2021 11:09, Jan Beulich wrote:
By default all guests are permitted to have up to 1024 maptrack frames,
which on 64-bit means an 8k frame table. Yet except for driver domains
guests normally don't make use of grant mappings. Defer allocating the
table until a map track handle is
From: Chen Yu
Because cpuidle assumes worst-case C-state parameters, PC6 parameters
are used for describing C6, which is worst-case for requesting CC6.
When PC6 is enabled, this is appropriate. But if PC6 is disabled
in the BIOS, the exit latency and target residency should be adjusted
accordingl
This patch adds Icelake Xeon D support to the intel_idle driver.
Since Icelake D and Icelake SP C-state characteristics the same,
we use Icelake SP C-states table for Icelake D as well.
Signed-off-by: Artem Bityutskiy
Acked-by: Chen Yu
Signed-off-by: Rafael J. Wysocki
[Linux commit: 22141d5f41
From: Artem Bityutskiy
Change IceLake Xeon C6 latency from 128 us to 170 us. The latency
was measured with the "wult" tool and corresponds to the 99.99th
percentile when measuring with the "nic" method. Note, the 128 us
figure correspond to the median latency, but in intel_idle we use
the "worst
From: Artem Bityutskiy
Add C-state table for the SnowRidge SoC which is found on Intel Jacobsville
platforms.
The following has been changed.
1. C1E latency changed from 10us to 15us. It was measured using the
open source "wult" tool (the "nic" method, 15us is the 99.99th
percentile).
From: Alexander Monakov
Intel SDM does not explicitly say that entering a C-state via MWAIT will
implicitly flush CPU caches as appropriate for that C-state. However,
documentation for individual Intel CPU generations does mention this
behavior.
Since intel_idle binds to any Intel CPU with MWAIT
flight 164858 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164858/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 164674
build-amd64
Before the code freeze I thought I'd check the original driver again,
and indeed there were a few changes we want to inherit.
1: mention assumption that WBINVD is not needed
2: add SnowRidge C-state table
3: update ICX C6 data
4: add Icelake-D support
5: adjust the SKX C6 parameters if PC6 is disa
Hi Jan,
On 30/08/2021 14:05, Jan Beulich wrote:
Passing byte granular values will not have the intended effect. Address
the immediate issue, but I don't think what we do is actually
sufficient: At least some devices allow access to their registers via
either I/O ports or MMIO. In such aliasing c
flight 164857 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164857/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 164674
build-amd64
Zen2 CPUs actually have this behaviour, but the CPUID bit couldn't be
introduced into Zen2 due to a lack of leaves. So, it was added in a
new leaf in Zen3. Nonetheless, hypervisors can synthesize the CPUID
bit in software.
So, on Zen2 hardware, Xen probes for NSCB (NullSelectorClearsBit) and
synth
AMD Zen3 adds the NullSelectorClearsBase bit to indicate that loading
a NULL segment selector zeroes the base and limit fields, as well as
just attributes.
Expose bit to all guests.
Suggested-by: Andrew Cooper
Signed-off-by: Jane Malalane
---
CC: Wei Liu
CC: Jan Beulich
CC: Andrew Cooper
CC:
Jane Malalane (2):
x86/cpuid: Expose NullSelectorClearsBase CPUID bit to guests
x86/cpuid: Detect null segment behaviour on Zen2 CPUs
tools/libs/light/libxl_cpuid.c | 1 +
tools/misc/xen-cpuid.c | 1 +
xen/arch/x86/cpu/amd.c | 18 ++
flight 164856 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164856/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 164674
build-amd64
On 06.09.2021 13:18, Andrew Cooper wrote:
> On 06/09/2021 12:14, Andrew Cooper wrote:
>> On 06/09/2021 12:00, Juergen Gross wrote:
>>> In case a domain is created with a cpupool other than Pool-0 specified
>>> it will be moved to that cpupool before any vcpus are allocated.
>>>
>>> This will lead t
flight 164848 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164848/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 164819 pass in 164848
test-amd64-amd64-xl-rtds 20
On 06.09.21 13:14, Andrew Cooper wrote:
On 06/09/2021 12:00, Juergen Gross wrote:
In case a domain is created with a cpupool other than Pool-0 specified
it will be moved to that cpupool before any vcpus are allocated.
This will lead to a NULL pointer dereference in sched_move_domain().
Fix tha
On Mon, Sep 06, 2021 at 12:30:07PM +0200, Jan Beulich wrote:
> On 06.09.2021 12:06, Anthony PERARD wrote:
> > On Thu, Sep 02, 2021 at 12:08:58PM +0200, Jan Beulich wrote:
> >> On 24.08.2021 12:49, Anthony PERARD wrote:
> >>> +# To be use with $(a_flags) or $(c_flags) to produce CPP flags
> >>> +cpp
On 06/09/2021 12:14, Andrew Cooper wrote:
> On 06/09/2021 12:00, Juergen Gross wrote:
>> In case a domain is created with a cpupool other than Pool-0 specified
>> it will be moved to that cpupool before any vcpus are allocated.
>>
>> This will lead to a NULL pointer dereference in sched_move_domain
On 06/09/2021 12:00, Juergen Gross wrote:
> In case a domain is created with a cpupool other than Pool-0 specified
> it will be moved to that cpupool before any vcpus are allocated.
>
> This will lead to a NULL pointer dereference in sched_move_domain().
>
> Fix that by tolerating vcpus not being a
Hi Jan,
On 30/08/2021 15:27, Jan Beulich wrote:
Both comment and message string associated with GNTST_no_device_space
suggest a connection to the IOMMU. A lack of maptrack handles has
nothing to do with that; it's unclear to me why commit 6213b696ba65
("Grant-table interface redone") introduced
In case a domain is created with a cpupool other than Pool-0 specified
it will be moved to that cpupool before any vcpus are allocated.
This will lead to a NULL pointer dereference in sched_move_domain().
Fix that by tolerating vcpus not being allocated yet.
Fixes: 70fadc41635b9b6 ("xen/cpupool:
Hi Jan,
On 30/08/2021 15:26, Jan Beulich wrote:
There's no point checking ->dev_bus_addr when GNTMAP_device_map isn't
set (and hence the field isn't going to be consumed). And if there is a
mismatch, use the so far unused GNTST_bad_dev_addr error indicator - if
not here, where else would this (s
Hi,
On 24/08/2021 07:11, Jan Beulich wrote:
On 23.08.2021 19:02, Costin Lupu wrote:
These changes introduce the page related definitions needed for mapping and
accessing guests memory. These values are intended to be used by any toolstack
component that needs to map guests memory. Until now, th
Hi Oleksandr,
On 06/09/2021 11:06, Oleksandr Andrushchenko wrote:
On 06.09.21 12:53, Julien Grall wrote:
However, looking at the rest of the code, we already have a check for vpci in
the common IOREQ code.
Which may not be enabled as it depends on CONFIG_IOREQ_SERVER.
Right. My point is wh
On 06.09.2021 12:06, Anthony PERARD wrote:
> On Thu, Sep 02, 2021 at 12:08:58PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:49, Anthony PERARD wrote:
>>> Signed-off-by: Anthony PERARD
>>
>> Reviewed-by: Jan Beulich
>> albeit with a remark:
>>
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@
flight 164854 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 164674
build-amd64
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 registers. But for Zephyr, this mecha
HI Juergen,
> On 6 Sep 2021, at 10:28, Juergen Gross wrote:
>
> On 06.09.21 10:46, Andrew Cooper wrote:
>> On 06/09/2021 09:23, Juergen Gross wrote:
>>> On 03.09.21 17:41, Bertrand Marquis wrote:
Hi,
While doing some investigation with cpupools I encountered a crash
when try
flight 164852 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164852/
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 06.09.21 12:53, Julien Grall wrote:
> Hi Oleksandr,
>
> On 06/09/2021 10:14, Oleksandr Andrushchenko wrote:
>>
>> On 06.09.21 11:48, Julien Grall wrote:
>>> On 06/09/2021 08:02, Oleksandr Andrushchenko wrote:
Hi, Julien!
>>>
>>> Hi Oleksandr,
>>>
On 03.09.21 12:04, Julien Grall wrote:
1 - 100 of 123 matches
Mail list logo
