On 16.11.2021 07:31, Penny Zheng wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -692,6 +692,12 @@ int arch_sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> return -EINVAL;
> }
>
> +if ( config->flags &
On 16.11.2021 07:31, Penny Zheng wrote:
> v3 changes:
> - move flag XEN_DOMCTL_CDF_INTERNAL_directmap back to
> xen/include/xen/domain.h,
> to let it be only available for domain created by XEN.
> - name it with extra "INTERNAL" and add comments to warn developers not
> to accidently use its
On 15.11.2021 23:27, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter),
> we goto out_error but we forget to reset xen_store_domain_type to
> XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls
>
On 16.11.2021 05:42, osstest service owner wrote:
> flight 166151 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/166151/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-pvops 6
On 15.11.21 18:56, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a vPCI is removed for a PCI device it is possible that we have
>> scheduled a delayed work for map/unmap operations for that device.
>> For example, the
flight 166153 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166153/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 15.11.2021 20:09, Julien Grall wrote:
> Hi Jan,
>
> On 15/11/2021 10:13, Jan Beulich wrote:
>> On 12.11.2021 17:02, Julien Grall wrote:
>>> Hi Elliott,
>>>
>>> On 12/11/2021 15:44, Elliott Mitchell wrote:
On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
>
>>
On 16.11.2021 01:41, Stefano Stabellini wrote:
> Bertrand's comment about MISRA aside, this style of comments doesn't
> seem to be covered/allowed by our current CODING_STYLE. It would be good
> to keep the CODING_STYLE document up to date: not only it helps us
> during reviews, it also helps
Later, we will introduce allocate_static_memory_11 for allocating static
memory for direct-map domains, and it will share a lot common codes with
the existing allocate_static_memory.
In order not to bring a lot of duplicate codes, and also to make the whole
code more readable, this commit
From: Stefano Stabellini
We always use a fix address to map the vPL011 to domains. The address
could be a problem for direct-map domains.
So, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid potential clashes.
Do the same for the virtual IRQ
From: Stefano Stabellini
Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domain which is using the host memory layout
Considering that DOM0 may not always be directly mapped in the
This commit gates function make_gicv3_domU_node with CONFIG_GICV3, and
also adds ASSERT_UNREACHABLE to catch any misuse.
Signed-off-by: Penny Zheng
---
v3 changes:
- new commit
---
xen/arch/arm/domain_build.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/arm/domain_build.c
From: Stefano Stabellini
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domains that are direct-mapped.
NEW VGIC has different naming schemes, like referring distributor base
From: Stefano Stabellini
This commit creates a new doc to document how to do passthrough without IOMMU.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
---
docs/misc/arm/passthrough-noiommu.txt | 52 +++
1 file changed, 52 insertions(+)
create mode
Cases where domU needs direct-map memory map:
* IOMMU not present in the system.
* IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
a few without, then guest DMA security still could not be
Helper allocate_static_memory is not meant to be reachable when built with
!CONFIG_STATIC_MEMORY, so this commit adds ASSERT_UNREACHABLE in it to catch
potential misuse.
Signed-off-by: Penny Zheng
---
v3 changes:
- new commit
---
xen/arch/arm/domain_build.c | 1 +
1 file changed, 1 insertion(+)
From: Stefano Stabellini
This commit introduces a new arm-specific flag
XEN_DOMCTL_CDF_INTERNAL_directmap to specify that a domain should
have its memory direct-map(guest physical address == physical address)
at domain creation.
Since this flag is only available for domain created by XEN, not
Cases where domU needs direct-map memory map:
* IOMMU not present in the system.
* IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
a few without, then guest DMA security still could not be
From: Stefano Stabellini
This commit avoids setting XEN_DOMCTL_CDF_iommu when the IOMMU is
absent/disabled, otherwise xen will fail later when handling
device assignment.
Signed-off-by: Penny Zheng
Signed-off-by: Stefano Stabellini
---
v3 changes:
- new commit, split from the original "[PATCH
flight 166151 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 165976
On Mon, 15 Nov 2021, Julien Grall wrote:
> On 12/11/2021 22:01, Stefano Stabellini wrote:
> > On Fri, 12 Nov 2021, Luca Fancellu wrote:
> > > > On 12 Nov 2021, at 07:27, Vikram Garhwal wrote:
> > > >
> > > > Update libfdt to v1.6.1 of libfdt taken from
> > > > git://github.com/dgibson/dtc.
> > >
On Mon, 15 Nov 2021, Jan Beulich wrote:
> On 15.11.2021 11:23, Bertrand Marquis wrote:
> > Hi Jan,
> >
> >> On 15 Nov 2021, at 10:20, Jan Beulich wrote:
> >>
> >> On 15.11.2021 11:13, Bertrand Marquis wrote:
> On 11 Nov 2021, at 17:57, Andrew Cooper
> wrote:
> ---
On 16/11/2021 00:36, Stefano Stabellini wrote:
> On Thu, 11 Nov 2021, Julien Grall wrote:
>> On 11/11/2021 17:57, Andrew Cooper wrote:
>>> There are exactly 3 callers of sort() in the hypervisor.
>>>
>>> Both arm callers pass in NULL for the swap function. While this might seem
>>> like an
On Thu, 11 Nov 2021, Julien Grall wrote:
> On 11/11/2021 17:57, Andrew Cooper wrote:
> > There are exactly 3 callers of sort() in the hypervisor.
> >
> > Both arm callers pass in NULL for the swap function. While this might seem
> > like an attractive option at first, it causes generic_swap() to
From: Stefano Stabellini
In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter),
we goto out_error but we forget to reset xen_store_domain_type to
XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls
will still try to initialize xenstore resulting into a crash
On Mon, 15 Nov 2021, Jan Beulich wrote:
> On 12.11.2021 22:47, Stefano Stabellini wrote:
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -983,8 +983,10 @@ static int __init xenbus_init(void)
> > */
> > proc_create_mount_point("xen");
> >
On 15/11/2021 16:21, Jan Beulich wrote:
> On 15.11.2021 15:33, Andrew Cooper wrote:
>> On 15/11/2021 10:53, Jan Beulich wrote:
>>> On 12.11.2021 19:51, Andrew Cooper wrote:
On 10/11/2021 09:19, Jane Malalane wrote:
> Before, user would change turbo status but this had no effect: boolean
+Ian
On Mon, 15 Nov 2021, Julien Grall wrote:
> Hi Luca,
>
> On 10/11/2021 14:02, Luca Fancellu wrote:
> >
> >
> > > On 10 Nov 2021, at 13:36, Julien Grall wrote:
> > >
> > > Hi Luca,
> > >
> > > On 10/11/2021 13:05, Luca Fancellu wrote:
> > > > I thought having the EFI_FILE_HANDLE global
On Mon, Nov 15, 2021 at 10:06:20AM +, Bertrand Marquis wrote:
>
> > On 13 Nov 2021, at 01:03, Elliott Mitchell wrote:
> >
> > On Fri, Nov 12, 2021 at 11:00:54PM +, Julien Grall wrote:
> >> On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell wrote:
> My preference is to introduce a
Hi Jan,
On 15/11/2021 10:13, Jan Beulich wrote:
On 12.11.2021 17:02, Julien Grall wrote:
Hi Elliott,
On 12/11/2021 15:44, Elliott Mitchell wrote:
On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
-Original Message-
From: Xen-devel On Behalf Of
Elliott Mitchell
I've
Hi Luca,
On 10/11/2021 14:02, Luca Fancellu wrote:
On 10 Nov 2021, at 13:36, Julien Grall wrote:
Hi Luca,
On 10/11/2021 13:05, Luca Fancellu wrote:
I thought having the EFI_FILE_HANDLE global in efi-boot.h was a “no go”, but if
it’s not then instead of
calling get_parent_handle in
Hi,
On 12/11/2021 22:01, Stefano Stabellini wrote:
On Fri, 12 Nov 2021, Luca Fancellu wrote:
On 12 Nov 2021, at 07:27, Vikram Garhwal wrote:
Update libfdt to v1.6.1 of libfdt taken from git://github.com/dgibson/dtc.
This update is done to support device tree overlays.
A few minor changes
flight 166149 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 165976
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When a PCI device gets assigned/de-assigned some work on vPCI side needs
> to be done for that device. Introduce a pair of hooks so vPCI can handle
> that.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
>
On 05.11.2021 07:56, 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.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> Since v3:
> - remove all R-b's due
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When a vPCI is removed for a PCI device it is possible that we have
> scheduled a delayed work for map/unmap operations for that device.
> For example, the following scenario can illustrate the problem:
>
>
On 15.11.2021 15:33, Andrew Cooper wrote:
> On 15/11/2021 10:53, Jan Beulich wrote:
>> On 12.11.2021 19:51, Andrew Cooper wrote:
>>> On 10/11/2021 09:19, Jane Malalane wrote:
Before, user would change turbo status but this had no effect: boolean
was set but policy wasn't reevaluated.
On 15.11.2021 16:07, Roger Pau Monné wrote:
> On Mon, Nov 15, 2021 at 03:31:39PM +0100, Jan Beulich wrote:
>> While commit 46c4061cd2bf ("x86/IOMMU: mark IOMMU / intremap not in use
>> when ACPI tables are missing") deals with apic_x2apic_probe() as called
>> from x2apic_bsp_setup(), the
On Mon, Nov 15, 2021 at 03:31:39PM +0100, Jan Beulich wrote:
> While commit 46c4061cd2bf ("x86/IOMMU: mark IOMMU / intremap not in use
> when ACPI tables are missing") deals with apic_x2apic_probe() as called
> from x2apic_bsp_setup(), the check_x2apic_preenabled() path is similarly
> affected:
Hi,
> On 15 Nov 2021, at 14:11, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 15/11/2021 11:23, Bertrand Marquis wrote:
>>> On 15 Nov 2021, at 10:55, Jan Beulich wrote:
>>>
>>> On 15.11.2021 11:23, Bertrand Marquis wrote:
Hi Jan,
> On 15 Nov 2021, at 10:20, Jan Beulich wrote:
On 15/11/2021 10:53, Jan Beulich wrote:
> On 12.11.2021 19:51, Andrew Cooper wrote:
>> On 10/11/2021 09:19, Jane Malalane wrote:
>>> Before, user would change turbo status but this had no effect: boolean
>>> was set but policy wasn't reevaluated. Policy must be reevaluated so
>>> that CPU
While commit 46c4061cd2bf ("x86/IOMMU: mark IOMMU / intremap not in use
when ACPI tables are missing") deals with apic_x2apic_probe() as called
from x2apic_bsp_setup(), the check_x2apic_preenabled() path is similarly
affected: The call needs to occur after acpi_iommu_init(), such that
Hi Bertrand,
On 15/11/2021 11:23, Bertrand Marquis wrote:
On 15 Nov 2021, at 10:55, Jan Beulich wrote:
On 15.11.2021 11:23, Bertrand Marquis wrote:
Hi Jan,
On 15 Nov 2021, at 10:20, Jan Beulich wrote:
On 15.11.2021 11:13, Bertrand Marquis wrote:
On 11 Nov 2021, at 17:57, Andrew Cooper
Hi, Bernard!
On 15.11.21 05:45, Bernard Zhao wrote:
> In function xen_drm_front_gem_import_sg_table, if in error branch,
> there maybe potential memleak if not call gem_free_pages_array.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 8 ++--
> 1 file
On 15/11/2021 09:27, Roger Pau Monné wrote:
> On Fri, Nov 12, 2021 at 06:28:16PM +, Andrew Cooper wrote:
>> powernow_register_driver() is currently written with a K type definition;
>> I'm surprised that compilers don't object to a mismatch with its declaration,
>> which is written in an
On 15/11/2021 13:58, Roger Pau Monné wrote:
> On Mon, Nov 15, 2021 at 12:43:34PM +, Andrew Cooper wrote:
>> On 15/11/2021 12:17, Roger Pau Monne wrote:
>>> Set the grant table version for the created domains to use version 1,
>>> as such tests domains don't require the usage of the grant table
Hi Roger,
On 15/11/2021 12:17, Roger Pau Monne wrote:
Such macro just clamps the passed version to fit in the designated
bits of the domctl field. The main purpose is to make it clearer in
the code when max grant version is being set in the grant_opts field.
Existing users that where setting
On Mon, Nov 15, 2021 at 12:43:34PM +, Andrew Cooper wrote:
> On 15/11/2021 12:17, Roger Pau Monne wrote:
> > Set the grant table version for the created domains to use version 1,
> > as such tests domains don't require the usage of the grant table at
> > all. A TODO note is added to switch
Hi Roger,
> On 15 Nov 2021, at 12:17, Roger Pau Monne wrote:
>
> Such macro just clamps the passed version to fit in the designated
> bits of the domctl field. The main purpose is to make it clearer in
> the code when max grant version is being set in the grant_opts field.
>
> Existing users
On 15/11/2021 12:17, Roger Pau Monne wrote:
> Such max version should be provided by the caller, otherwise the
> bindings will default to specifying a max version of 2, which is
> inline with the current defaults in the hypervisor.
>
> Fixes: 7379f9e10a ('gnttab: allow setting max version
On 15/11/2021 12:17, Roger Pau Monne wrote:
> Set the grant table version for the created domains to use version 1,
> as such tests domains don't require the usage of the grant table at
> all. A TODO note is added to switch those dummy domains to not have a
> grant table at all when possible.
On 15/11/2021 12:17, Roger Pau Monne wrote:
> Set the grant table version for the created domains to use version 1,
> as that's the used by the test cases. Without setting the grant
> version the domains for the tests cannot be created.
>
> Fixes: 7379f9e10a ('gnttab: allow setting max version
On 15/11/2021 12:17, Roger Pau Monne wrote:
> Such macro just clamps the passed version to fit in the designated
> bits of the domctl field. The main purpose is to make it clearer in
> the code when max grant version is being set in the grant_opts field.
>
> Existing users that where setting the
On 15/11/2021 12:19, Roger Pau Monné wrote:
> On Mon, Nov 15, 2021 at 12:03:26PM +, Andrew Cooper wrote:
>> On 15/11/2021 11:08, Roger Pau Monne wrote:
>>> Current ioctl definition was wrong in both FreeBSD and Xen sources, as
>>> the MMAP_RESOURCE ioctl needs to copy back the size of the
On 15.11.2021 13:17, Roger Pau Monne wrote:
> Set the grant table version for the created domains to use version 1,
> as such tests domains don't require the usage of the grant table at
> all. A TODO note is added to switch those dummy domains to not have a
> grant table at all when possible.
On 15.11.2021 13:17, Roger Pau Monne wrote:
> Set the grant table version for the created domains to use version 1,
> as that's the used by the test cases. Without setting the grant
> version the domains for the tests cannot be created.
>
> Fixes: 7379f9e10a ('gnttab: allow setting max version
On 15.11.2021 13:17, Roger Pau Monne wrote:
> Such macro just clamps the passed version to fit in the designated
> bits of the domctl field. The main purpose is to make it clearer in
> the code when max grant version is being set in the grant_opts field.
>
> Existing users that where setting the
On Mon, Nov 15, 2021 at 12:03:26PM +, Andrew Cooper wrote:
> On 15/11/2021 11:08, Roger Pau Monne wrote:
> > Current ioctl definition was wrong in both FreeBSD and Xen sources, as
> > the MMAP_RESOURCE ioctl needs to copy back the size of the resource
> > when passed a zero address and size.
Such max version should be provided by the caller, otherwise the
bindings will default to specifying a max version of 2, which is
inline with the current defaults in the hypervisor.
Fixes: 7379f9e10a ('gnttab: allow setting max version per-domain')
Signed-off-by: Roger Pau Monné
---
Cc: Ian
Set the grant table version for the created domains to use version 1,
as such tests domains don't require the usage of the grant table at
all. A TODO note is added to switch those dummy domains to not have a
grant table at all when possible. Without setting the grant version
the domains for the
Set the grant table version for the created domains to use version 1,
as that's the used by the test cases. Without setting the grant
version the domains for the tests cannot be created.
Fixes: 7379f9e10a ('gnttab: allow setting max version per-domain')
Reported-by: Andrew Cooper
Signed-off-by:
Hello,
The first patch introduces some syntactic sugar for setting the max
grant version on the domctl, while the later 3 patches fix missing
occurrences of xen_domctl_createdomain that didn't set the max grant
version. It's likely patches 2 and 3 could be squashed.
All should be considered for
Such macro just clamps the passed version to fit in the designated
bits of the domctl field. The main purpose is to make it clearer in
the code when max grant version is being set in the grant_opts field.
Existing users that where setting the version in the grant_opts field
are switched to use
On 08.11.2021 12:54, Roger Pau Monné wrote:
> On Mon, Nov 08, 2021 at 12:40:59PM +0100, Jan Beulich wrote:
>> While commit 46c4061cd2bf ("x86/IOMMU: mark IOMMU / intremap not in use
>> when ACPI tables are missing") deals with apic_x2apic_probe() as called
>> from x2apic_bsp_setup(), the
On 15/11/2021 11:08, Roger Pau Monne wrote:
> Current ioctl definition was wrong in both FreeBSD and Xen sources, as
> the MMAP_RESOURCE ioctl needs to copy back the size of the resource
> when passed a zero address and size. FreeBSD encodes in the definition
> of the ioctl number whether
Hi Roger,
On 12/11/2021 12:02, Roger Pau Monne wrote:
This reverts commit 228ab9992ffb1d8f9d2475f2581e68b2913acb88.
Performance analysis has shown that dropping the domctl lock during
domain destruction greatly increases the contention in the heap_lock,
thus making parallel destruction of
On 12/11/2021 18:28, Andrew Cooper wrote:
> Xen already collects CPUID.0x8007.edx by default, meaning that we can
> refer to per-cpu data directly. This also avoids the need IPI the onlining
> CPU to identify whether Core Performance Boost is available.
>
> Signed-off-by: Andrew Cooper
> ---
On 12.11.2021 19:28, Andrew Cooper wrote:
> Xen already collects CPUID.0x8007.edx by default, meaning that we can
> refer to per-cpu data directly. This also avoids the need IPI the onlining
> CPU to identify whether Core Performance Boost is available.
>
> Signed-off-by: Andrew Cooper
Hi Jan,
> On 15 Nov 2021, at 10:55, Jan Beulich wrote:
>
> On 15.11.2021 11:23, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 15 Nov 2021, at 10:20, Jan Beulich wrote:
>>>
>>> On 15.11.2021 11:13, Bertrand Marquis wrote:
> On 11 Nov 2021, at 17:57, Andrew Cooper wrote:
> ---
On 12.11.2021 19:28, Andrew Cooper wrote:
> Currently, each feature_detect() (called on CPU add) hook for both cpufreq
> drivers duplicates cpu_has_aperfmperf in a per-cpu datastructure, and edits
> cpufreq_driver.getavg to point at get_measured_perf().
>
> As all parts of this are
On Mon, Nov 15, 2021 at 12:02:53PM +0100, Jan Beulich wrote:
> On 15.11.2021 11:51, Roger Pau Monne wrote:
> > Set the grant table version for the created domains to use version 1,
> > as that's the used by the test cases. Without setting the grant
> > version the domains for the tests cannot be
On 12.11.2021 19:28, Andrew Cooper wrote:
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -640,13 +640,19 @@ static int __init cpufreq_driver_init(void)
> {
> int ret = 0;
>
> -if ((cpufreq_controller == FREQCTL_xen) &&
> -
On 15.11.2021 10:27, Roger Pau Monné wrote:
> On Fri, Nov 12, 2021 at 06:28:16PM +, Andrew Cooper wrote:
>> @@ -353,25 +349,13 @@ static const struct cpufreq_driver __initconstrel
>> powernow_cpufreq_driver = {
>> .update = powernow_cpufreq_update
>> };
>>
>> -unsigned int __init
Current ioctl definition was wrong in both FreeBSD and Xen sources, as
the MMAP_RESOURCE ioctl needs to copy back the size of the resource
when passed a zero address and size. FreeBSD encodes in the definition
of the ioctl number whether parameters should be copied in (W) and/or
copied out (R).
On 15.11.2021 11:51, Roger Pau Monne wrote:
> Set the grant table version for the created domains to use version 1,
> as that's the used by the test cases. Without setting the grant
> version the domains for the tests cannot be created.
>
> Fixes: 7379f9e10a ('gnttab: allow setting max version
On 15.11.2021 11:23, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 15 Nov 2021, at 10:20, Jan Beulich wrote:
>>
>> On 15.11.2021 11:13, Bertrand Marquis wrote:
On 11 Nov 2021, at 17:57, Andrew Cooper wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1234,15 +1234,18
On 12.11.2021 19:51, Andrew Cooper wrote:
> On 10/11/2021 09:19, Jane Malalane wrote:
>> Before, user would change turbo status but this had no effect: boolean
>> was set but policy wasn't reevaluated. Policy must be reevaluated so
>> that CPU frequency is chosen according to the turbo status and
Set the grant table version for the created domains to use version 1,
as that's the used by the test cases. Without setting the grant
version the domains for the tests cannot be created.
Fixes: 7379f9e10a ('gnttab: allow setting max version per-domain')
Reported-by: Andrew Cooper
Signed-off-by:
On 2021-11-15 11:02+0100, Jan Beulich wrote:
> On 13.11.2021 09:38, Thomas Weißschuh wrote:
> > This configuration option provides a misc device as an API to userspace.
> > Make this API usable without having to select the module as a transitive
> > dependency.
> >
> > This also fixes an issue
Hi Jan,
> On 15 Nov 2021, at 10:20, Jan Beulich wrote:
>
> On 15.11.2021 11:13, Bertrand Marquis wrote:
>>> On 11 Nov 2021, at 17:57, Andrew Cooper wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -1234,15 +1234,18 @@ int vcpu_unpause_by_systemcontroller(struct vcpu
On 15.11.2021 11:13, Bertrand Marquis wrote:
>> On 11 Nov 2021, at 17:57, Andrew Cooper wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1234,15 +1234,18 @@ int vcpu_unpause_by_systemcontroller(struct vcpu *v)
>> return 0;
>> }
>>
>> -static void do_domain_pause(struct
On 12.11.2021 17:02, Julien Grall wrote:
> Hi Elliott,
>
> On 12/11/2021 15:44, Elliott Mitchell wrote:
>> On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
>>>
-Original Message-
From: Xen-devel On Behalf Of
Elliott Mitchell
I've been busy with another
Hi Andrew,
> On 11 Nov 2021, at 17:57, Andrew Cooper wrote:
>
> Retpolines are expensive, and all these do are select between the sync and
> nosync helpers. Pass a boolean instead, and use direct calls everywhere.
>
> Pause/unpause operations on behalf of dom0 are not fastpaths, so avoid
>
On 12.11.2021 22:47, Stefano Stabellini wrote:
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -983,8 +983,10 @@ static int __init xenbus_init(void)
>*/
> proc_create_mount_point("xen");
> #endif
> + return err;
Personally I think such
Hi Elliott,
> On 13 Nov 2021, at 01:03, Elliott Mitchell wrote:
>
> On Fri, Nov 12, 2021 at 11:00:54PM +, Julien Grall wrote:
>> On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell wrote:
My preference is to introduce a per-platform quirk (I believe Stefano was
happy
with this).
On 13.11.2021 09:38, Thomas Weißschuh wrote:
> This configuration option provides a misc device as an API to userspace.
> Make this API usable without having to select the module as a transitive
> dependency.
>
> This also fixes an issue where localyesconfig would select
> CONFIG_XEN_PRIVCMD=m
On 15.11.2021 10:55, Jan Beulich wrote:
> With there being a way to disable v2 support, telling new guests to use
> v2 exclusively is not a good suggestion.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Luca Fancellu
> ---
> v2: s/be able to fall back/default/.
>
> ---
With there being a way to disable v2 support, telling new guests to use
v2 exclusively is not a good suggestion.
Signed-off-by: Jan Beulich
Reviewed-by: Luca Fancellu
---
v2: s/be able to fall back/default/.
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@
On 15.11.2021 07:18, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Friday, November 12, 2021 5:50 PM
>>
>> When an IOMMU implements the full 16 bits worth of DID in context
>> entries, there's no point going through a memory base translation table.
>> For IOMMUs not using Caching Mode we can
On 12.11.2021 15:35, Roger Pau Monné wrote:
> On Fri, Nov 12, 2021 at 02:45:14PM +0100, Jan Beulich wrote:
>> On 12.11.2021 14:42, Roger Pau Monné wrote:
>>> On Fri, Nov 12, 2021 at 10:48:43AM +0100, Jan Beulich wrote:
While domain_context_mapping() invokes domain_context_unmap() in a sub-
On Fri, Nov 12, 2021 at 06:28:16PM +, Andrew Cooper wrote:
> powernow_register_driver() is currently written with a K type definition;
> I'm surprised that compilers don't object to a mismatch with its declaration,
> which is written in an ANSI-C compatible way.
>
> Furthermore, its sole
flight 166147 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166147/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166142
test-armhf-armhf-libvirt 16
flight 166148 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
93 matches
Mail list logo
