On Thu, May 30, 2024 at 09:48:06PM +0200, Ilya Dryomov wrote:
> For rbd, this change effectively lowers max_sectors from 4M to 64K or
> less and that is definitely not desirable. From previous interactions
> with users we want max_sectors to match max_hw_sectors -- this has come
> up a quite a
On Thu, May 30, 2024 at 10:16:33AM +0100, John Garry wrote:
>> -static void sd_config_write_same(struct scsi_disk *);
>> +static void sd_config_discard(struct scsi_disk *sdkp, struct queue_limits
>> *lim,
>> +unsigned int mode);
>
> Are there any reasons why we keep forward
flight 186200 xen-unstable real [real]
flight 186207 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186200/
http://logs.test-lab.xenproject.org/osstest/logs/186207/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 186204 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186204/
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 186205 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186205/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5f68a363d0d95bd0d383861ae21886d9824a8cd4
baseline version:
ovmf
On Mon, 27 May 2024, Jan Beulich wrote:
> On 24.05.2024 22:03, Andrew Cooper wrote:
> > Just like ffs() in the previous changes. Express the upper bound of the
> > testing in terms of BITS_PER_LONG as it varies between architectures.
> >
> > Signed-off-by: Andrew Cooper
>
> Reviewed-by: Jan
On Fri, 24 May 2024, Andrew Cooper wrote:
> Perform constant-folding unconditionally, rather than having it implemented
> inconsistency between architectures.
>
> Confirm the expected behaviour with compile time and boot time tests.
>
> For non-constant inputs, use arch_ffs() if provided but
flight 186203 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186203/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a8dc6bf73f789f38f2930641b20dfd6d9e38f411
baseline version:
ovmf
On Mon, 27 May 2024, Jan Beulich wrote:
> On 24.05.2024 22:03, Andrew Cooper wrote:
> > generic_f?s() being static inline is the cause of lots of the complexity
> > between the common and arch-specific bitops.h
> >
> > They appear to be static inline for constant-folding reasons (ARM uses them
>
On Fri, 24 May 2024, Andrew Cooper wrote:
> This is in order to maintain bisectability through the subsequent changes, as
> the order of definitions is altered.
>
> Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
On Thu, 30 May 2024, Marek Marczykowski-Górecki wrote:
> On Wed, May 29, 2024 at 03:19:43PM +0100, Andrew Cooper wrote:
> > This restriction doesn't provide any security because anyone with suitable
> > permissions on the HW runners can bypass it with this local patch.
> >
> > Requiring branches
On Wed, 29 May 2024, Andrew Cooper wrote:
> Have PPC put serial to stdout like all other tests, so it shows up in the main
> job log.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Michal Orzel
> CC: Marek
On 30/05/2024 5:44 pm, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
>> To allow CONFIG_ARGO build happy it was included to
>>
>> as ARGO requires p2m_type_t ( p2m_ram_rw ) and declaration of
>> check_get_page_from_gfn() from xen/p2m-common.h.
Actually, this is an ARGO
On Wed, 29 May 2024, Michal Orzel wrote:
> Hi Andrew,
>
> On 29/05/2024 16:19, Andrew Cooper wrote:
> >
> >
> > ... like the other hardware tests. This gets more value out of the testing.
> >
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Roger Pau Monné
> > CC: Stefano Stabellini
> >
On Wed, 29 May 2024, Andrew Cooper wrote:
> ... like the other hardware tests. This gets more value out of the testing.
>
> Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
> ---
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Michal Orzel
> CC: Marek Marczykowski-Górecki
>
On 29/05/2024 3:30 pm, Alejandro Vallejo wrote:
> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
> index e01f494b772a..85d56f26537b 100644
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -799,15 +799,23 @@ int xc_cpu_policy_set_domain(xc_interface *xch,
>
flight 186201 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186201/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ced13b93afea87a8a1fe6ddbb67240a84cb2e3d3
baseline version:
ovmf
flight 186196 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-vhd 8 xen-boot fail REGR. vs. 186174
build-amd64-xsm
On 5/28/24 22:04, Christoph Hellwig wrote:
A few drivers optimistically try to support discard, write zeroes and
secure erase and disable the features from the I/O completion handler
if the hardware can't support them. This disable can't be done using
the atomic queue limits API because the I/O
On 5/28/24 22:04, Christoph Hellwig wrote:
Remove all APIs that are unused now that sd and sr have been converted
to the atomic queue limits API.
Reviewed-by: Bart Van Assche
On 5/28/24 22:04, Christoph Hellwig wrote:
Consolidate setting zone-related queue limits in sd_zbc_read_zones
instead of splitting them between sd_zbc_revalidate_zones and
sd_zbc_read_zones, and move the early_zone_information initialization
in sd_zbc_read_zones above setting up the queue
On 5/28/24 22:04, Christoph Hellwig wrote:
Fall through to the main call to blk_queue_max_discard_sectors given that
max_blocks has been initialized to zero above instead of duplicating the
call.
Reviewed-by: Bart Van Assche
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> diff --git a/README b/README
> index c8a108449e..30da5ff9c0 100644
> --- a/README
> +++ b/README
> @@ -48,6 +48,10 @@ provided by your OS distributor:
>- For ARM 64-bit:
> - GCC 5.1 or later
> - GNU Binutils 2.24 or later
>
On 5/28/24 22:04, Christoph Hellwig wrote:
Add helper to disable WRITE SAME when it is not supported and use it
instead of sd_config_write_same in the I/O completion handler. This
avoids touching more fields than required in the I/O completion handler
and prepares for converting sd to use the
On 5/28/24 22:04, Christoph Hellwig wrote:
Add helper to disable discard when it is not supported and use it
instead of sd_config_discard in the I/O completion handler. This avoids
touching more fields than required in the I/O completion handler and
prepares for converting sd to use the atomic
On 5/28/24 22:04, Christoph Hellwig wrote:
Don't reset the discard settings to no-op over and over when a user
writes to the provisioning attribute as that is already the default
mode for ZBC devices. In hindsight we should have made writing to
the attribute fail for ZBC devices, but the code
On Wed, May 29, 2024 at 7:05 AM Christoph Hellwig wrote:
>
> The soft max_sectors limit is normally capped by the hardware limits and
> an arbitrary upper limit enforced by the kernel, but can be modified by
> the user. A few drivers want to increase this limit (nbd, rbd) or
> adjust it up or
On 5/28/24 22:04, Christoph Hellwig wrote:
The soft max_sectors limit is normally capped by the hardware limits and
an arbitrary upper limit enforced by the kernel, but can be modified by
the user. A few drivers want to increase this limit (nbd, rbd) or
adjust it up or down based on hardware
On Thu, 2024-05-30 at 19:40 +0100, Andrew Cooper wrote:
> Having no_irq_type defined per arch, but using common callbacks is a
> mess, and
> particualrly hard to bootstrap a new architecture with.
>
> Now that the ack()/end() hooks have been exported suitably, move the
> definition of no_irq_type
On 5/28/24 22:04, Christoph Hellwig wrote:
Discard and Write Zeroes are different operation and implemented
by different fallocate opcodes for ubd. If one fails the other one
can work and vice versa.
Split the code to disable the operations in ubd_handler to only
disable the operation that
On Thu, 2024-05-30 at 19:40 +0100, Andrew Cooper wrote:
> Any non-stub implementation of these is going to have to do something
> here.
>
> irq_end_none() is more complicated and has arch-specific interactions
> with
> irq_ack_none(), so make it optional.
>
> For PPC, introduce a stub
On Thu, 2024-05-30 at 19:40 +0100, Andrew Cooper wrote:
> Found when reviewing Oleksii's series to enable the RISC-V build.
>
> The way no_irq_type works is horrifying. Make it less-so.
>
> Andrew Cooper (2):
> arch/irq: Make irq_ack_none() mandatory
> arch/irq: Centralise no_irq_type
>
>
flight 186199 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186199/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e7848481160b270ebc59d68ecbc8d2722e3aed8c
baseline version:
ovmf
On 30/05/2024 7:27 pm, Oleksii K. wrote:
> On Thu, 2024-05-30 at 18:45 +0100, Andrew Cooper wrote:
>> On 30/05/2024 6:12 pm, Oleksii K. wrote:
>>> On Thu, 2024-05-30 at 17:48 +0100, Andrew Cooper wrote:
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/stubs.c
Any non-stub implementation of these is going to have to do something here.
irq_end_none() is more complicated and has arch-specific interactions with
irq_ack_none(), so make it optional.
For PPC, introduce a stub irq_ack_none().
For ARM and x86, export the existing {ack,end}_none() helpers,
Having no_irq_type defined per arch, but using common callbacks is a mess, and
particualrly hard to bootstrap a new architecture with.
Now that the ack()/end() hooks have been exported suitably, move the
definition of no_irq_type into common/irq.c, and into .rodata for good
measure.
No
Found when reviewing Oleksii's series to enable the RISC-V build.
The way no_irq_type works is horrifying. Make it less-so.
Andrew Cooper (2):
arch/irq: Make irq_ack_none() mandatory
arch/irq: Centralise no_irq_type
xen/arch/arm/include/asm/irq.h | 3 +++
xen/arch/arm/irq.c |
On Thu, 2024-05-30 at 18:45 +0100, Andrew Cooper wrote:
> On 30/05/2024 6:12 pm, Oleksii K. wrote:
> > On Thu, 2024-05-30 at 17:48 +0100, Andrew Cooper wrote:
> > > On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > > > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
> > > > index
On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Acked-by: Jan Beulich
>
> This patch looks like it can go in independently? Or does it depend
> on
> having bitops.h working in practice?
>
>
flight 186194 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186194/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186186
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> index fe3a43be20..2c3fb7d72e 100644
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -1,5 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
>
> +#include
> #include
>
On 30/05/2024 6:12 pm, Oleksii K. wrote:
> On Thu, 2024-05-30 at 17:48 +0100, Andrew Cooper wrote:
>> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
>>> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
>>> index 8285bcffef..bda35fc347 100644
>>> --- a/xen/arch/riscv/stubs.c
>>> +++
Hi,
On 30/05/2024 18:22, Andrew Cooper wrote:
On 30/05/2024 6:16 pm, Oleksii K. wrote:
On Thu, 2024-05-30 at 17:47 +0100, Andrew Cooper wrote:
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
diff --git a/README b/README
index c8a108449e..30da5ff9c0 100644
--- a/README
+++ b/README
@@ -48,6
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich
This patch looks like it can go in independently? Or does it depend on
having bitops.h working in practice?
However, one very strong suggestion...
> diff --git
On 30/05/2024 6:16 pm, Oleksii K. wrote:
> On Thu, 2024-05-30 at 17:47 +0100, Andrew Cooper wrote:
>> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
>>> diff --git a/README b/README
>>> index c8a108449e..30da5ff9c0 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -48,6 +48,10 @@ provided by your OS
On Thu, 2024-05-30 at 17:47 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > diff --git a/README b/README
> > index c8a108449e..30da5ff9c0 100644
> > --- a/README
> > +++ b/README
> > @@ -48,6 +48,10 @@ provided by your OS distributor:
> > - For ARM 64-bit:
>
flight 186197 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186197/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, 2024-05-30 at 17:48 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
> > index 8285bcffef..bda35fc347 100644
> > --- a/xen/arch/riscv/stubs.c
> > +++ b/xen/arch/riscv/stubs.c
> > @@ -24,12 +24,6 @@
On Thu, 2024-05-30 at 10:14 +0200, Roger Pau Monné wrote:
> On Thu, May 30, 2024 at 09:04:08AM +0100, Andrew Cooper wrote:
> > On 30/05/2024 8:53 am, Roger Pau Monne wrote:
> > > For HVM based control domains XENMEM_machine_memory_map must be
> > > available so
> > > that the `e820_host` xl.cfg
On Thu, 2024-05-30 at 17:44 +0100, Andrew Cooper wrote:
>
> The subject should say "update Kconfig", because you're not (only)
> disabling.
>
> I'd suggest "xen/riscv: Update Kconfig in preparation for a full Xen
> build".
>
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > Disables
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
> new file mode 100644
> index 00..8285bcffef
> --- /dev/null
> +++ b/xen/arch/riscv/stubs.c
> @@ -0,0 +1,439 @@
>
> +void udelay(unsigned long usecs)
> +{
> +
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
> index 8285bcffef..bda35fc347 100644
> --- a/xen/arch/riscv/stubs.c
> +++ b/xen/arch/riscv/stubs.c
> @@ -24,12 +24,6 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>
>
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> diff --git a/README b/README
> index c8a108449e..30da5ff9c0 100644
> --- a/README
> +++ b/README
> @@ -48,6 +48,10 @@ provided by your OS distributor:
>- For ARM 64-bit:
> - GCC 5.1 or later
> - GNU Binutils 2.24 or later
>
The subject should say "update Kconfig", because you're not (only)
disabling.
I'd suggest "xen/riscv: Update Kconfig in preparation for a full Xen build".
On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> Disables unnecessary configs for two cases:
> 1. By utilizing EXTRA_FIXED_RANDCONFIG for
On 30.05.2024 13:19, Chen, Jiqian wrote:
> On 2024/5/29 20:22, Jan Beulich wrote:
>> On 29.05.2024 13:13, Chen, Jiqian wrote:
>>> On 2024/5/29 15:10, Jan Beulich wrote:
On 29.05.2024 08:56, Chen, Jiqian wrote:
> On 2024/5/29 14:31, Jan Beulich wrote:
>> On 29.05.2024 04:41, Chen,
On Thu, May 30, 2024 at 02:48:10PM +0100, Alejandro Vallejo wrote:
> I'll try to do that soon-ish. I suspect the pain points are going to be
> making it work nicely as well on 1vCPU systems with no APIC (are
> those expected to work?).
We do not allow creation of PVH/HVM domains without an
On Thu, 2024-05-30 at 10:44 +0100, Andrew Cooper wrote:
> On 29/05/2024 3:30 pm, Alejandro Vallejo wrote:
> > Alejandro Vallejo (2):
> > tools/xg: Streamline cpu policy serialise/deserialise calls
> > tools/xg: Clean up xend-style overrides for CPU policies
>
> Oleksii: Please consider for
On Thu, 2024-05-30 at 11:14 +0100, Andrew Cooper wrote:
> When reinstating some of systemd.m4 between v1 and v2, I reintroduced
> a little
> too much. While {c,o}xenstored are indeed no longer linked against
> libsystemd, ./configure still looks for it.
>
> Drop this too.
>
> Fixes:
flight 186190 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186190/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186179
test-amd64-amd64-libvirt 15
flight 186198 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186198/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9518d77eb869034a141799b3d28cac20ecb60fe0
baseline version:
ovmf
On 30/05/2024 12:08, Andrew Cooper wrote:
> On 29/05/2024 3:32 pm, Alejandro Vallejo wrote:
>> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
>> index f033d22785be..b70b22d55fcf 100644
>> --- a/xen/lib/x86/policy.c
>> +++ b/xen/lib/x86/policy.c
>> @@ -2,6 +2,17 @@
>>
>> #include
>>
Hi Julien,
> On 30 May 2024, at 12:35, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 30/05/2024 10:40, Bertrand Marquis wrote:
>>> But we are making assumption that all TEE implementation will have its
>>> node inside "/firmware/". I am not 100% sure that this is correct. For
>>> example I saw
On Thu, May 30, 2024 at 02:45:18PM +0200, Jürgen Groß wrote:
> On 29.05.24 18:03, Roger Pau Monné wrote:
> > On Wed, May 29, 2024 at 03:08:49PM +0200, Jürgen Groß wrote:
> > > On 29.05.24 14:46, Roger Pau Monné wrote:
> > > > On Wed, May 29, 2024 at 01:47:09PM +0200, Jürgen Groß wrote:
> > > > >
On Thu, May 30, 2024 at 12:12:19PM +0100, Andrew Cooper wrote:
> On 30/05/2024 12:02 pm, Roger Pau Monné wrote:
> > On Thu, May 30, 2024 at 11:14:39AM +0100, Andrew Cooper wrote:
> >> When reinstating some of systemd.m4 between v1 and v2, I reintroduced a
> >> little
> >> too much. While
On 29.05.24 18:03, Roger Pau Monné wrote:
On Wed, May 29, 2024 at 03:08:49PM +0200, Jürgen Groß wrote:
On 29.05.24 14:46, Roger Pau Monné wrote:
On Wed, May 29, 2024 at 01:47:09PM +0200, Jürgen Groß wrote:
On 28.05.24 13:22, Roger Pau Monné wrote:
Hello,
When the stop_machine_run() call in
flight 186195 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186195/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c695e3182aa7497833f1b0fc69f6776fec8cb8cf
baseline version:
ovmf
On 2024/5/29 20:22, Jan Beulich wrote:
> On 29.05.2024 13:13, Chen, Jiqian wrote:
>> On 2024/5/29 15:10, Jan Beulich wrote:
>>> On 29.05.2024 08:56, Chen, Jiqian wrote:
On 2024/5/29 14:31, Jan Beulich wrote:
> On 29.05.2024 04:41, Chen, Jiqian wrote:
>> But I found in function
On 30/05/2024 12:02 pm, Roger Pau Monné wrote:
> On Thu, May 30, 2024 at 11:14:39AM +0100, Andrew Cooper wrote:
>> When reinstating some of systemd.m4 between v1 and v2, I reintroduced a
>> little
>> too much. While {c,o}xenstored are indeed no longer linked against
>> libsystemd, ./configure
On 29/05/2024 3:32 pm, Alejandro Vallejo wrote:
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785be..b70b22d55fcf 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -2,6 +2,17 @@
>
> #include
>
> +uint32_t x86_x2apic_id_from_vcpu_id(const struct
On Thu, May 30, 2024 at 11:14:39AM +0100, Andrew Cooper wrote:
> When reinstating some of systemd.m4 between v1 and v2, I reintroduced a little
> too much. While {c,o}xenstored are indeed no longer linked against
> libsystemd, ./configure still looks for it.
>
> Drop this too.
>
> Fixes:
flight 186189 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186189/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-vhd 8 xen-boot fail REGR. vs. 186174
build-amd64-xsm
Hi Bertrand,
On 30/05/2024 10:40, Bertrand Marquis wrote:
But we are making assumption that all TEE implementation will have its
node inside "/firmware/". I am not 100% sure that this is correct. For
example I saw that Google Trusty uses "/trusty" node (directly inside
the DTS root). On other
When reinstating some of systemd.m4 between v1 and v2, I reintroduced a little
too much. While {c,o}xenstored are indeed no longer linked against
libsystemd, ./configure still looks for it.
Drop this too.
Fixes: ae26101f6bfc ("tools: Drop libsystemd as a dependency")
Signed-off-by: Andrew
On Wed, May 29, 2024 at 03:32:31PM +0100, Alejandro Vallejo wrote:
> This allows the initial x2APIC ID to be sent on the migration stream. The
> hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> Given the vlapic data is zero-extended on restore, fix up migrations from
>
On Wed, May 29, 2024 at 03:32:30PM +0100, Alejandro Vallejo wrote:
> While doing this, factor out checks common to architectural and hidden state.
>
> Signed-off-by: Alejandro Vallejo
Reviewed-by: Roger PAu Monné
With the BUG() possibly replaced with ASSERT_UNREACHABLE(),
> ---
> v3:
> *
On 29/05/2024 3:30 pm, Alejandro Vallejo wrote:
> Alejandro Vallejo (2):
> tools/xg: Streamline cpu policy serialise/deserialise calls
> tools/xg: Clean up xend-style overrides for CPU policies
Oleksii: Please consider for 4.19.
This is internal clean-up to CPUID handling which has been
On Wed, May 29, 2024 at 03:30:38PM +0100, Alejandro Vallejo wrote:
> Factor out policy getters/setters from both (CPUID and MSR) policy override
> functions. Additionally, use host policy rather than featureset when
> preparing the cur policy, saving one hypercall and several lines of
>
Hi Volodomyr,
First: thanks a lot for this as having a solution for selecting the tee
for guests on a dom0less configuration was something needed.
Let me answer a bit more on the rest of the patch,
> On 29 May 2024, at 23:34, Volodymyr Babchuk
> wrote:
>
>
> Hi Julien,
>
> Julien Grall
flight 186193 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186193/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cd4cebabf5834c403c9d9ac4f162e8336024bbcd
baseline version:
ovmf
On 29/05/2024 06:04, Christoph Hellwig wrote:
Assign all queue limits through a local queue_limits variable and
queue_limits_commit_update so that we can't race updating them from
multiple places, and free the queue when updating them so that
in-progress I/O submissions don't see half-updated
Hi Julien,
> On 30 May 2024, at 09:59, Julien Grall wrote:
>
>
>
> On 29/05/2024 22:34, Volodymyr Babchuk wrote:
>> Hi Julien,
>
> Hi Volodymyr,
>
>> Julien Grall writes:
>>> Hi Volodymyr,
>>>
>>> Can you clarify whether this is intended for the next release cycle?
>> Well, I don't think
On 30/05/2024 9:14 am, Roger Pau Monné wrote:
> On Thu, May 30, 2024 at 09:04:08AM +0100, Andrew Cooper wrote:
>> On 30/05/2024 8:53 am, Roger Pau Monne wrote:
>>> For HVM based control domains XENMEM_machine_memory_map must be available so
>>> that the `e820_host` xl.cfg option can be used.
>>>
On Thu, May 30, 2024 at 09:04:08AM +0100, Andrew Cooper wrote:
> On 30/05/2024 8:53 am, Roger Pau Monne wrote:
> > For HVM based control domains XENMEM_machine_memory_map must be available so
> > that the `e820_host` xl.cfg option can be used.
> >
> > Signed-off-by: Roger Pau Monné
>
> Seems
flight 186186 xen-unstable real [real]
flight 186192 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186186/
http://logs.test-lab.xenproject.org/osstest/logs/186192/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 30/05/2024 8:53 am, Roger Pau Monne wrote:
> For HVM based control domains XENMEM_machine_memory_map must be available so
> that the `e820_host` xl.cfg option can be used.
>
> Signed-off-by: Roger Pau Monné
Seems safe enough to allow.
Does this want a reported-by, or some further discussion
On 29/05/2024 22:34, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Hi Volodymyr,
Can you clarify whether this is intended for the next release cycle?
Well, I don't think that this patch should be committed ASAP if this is
what you are asking about.
On
For HVM based control domains XENMEM_machine_memory_map must be available so
that the `e820_host` xl.cfg option can be used.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/hypercall.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hypercall.c
flight 186191 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186191/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 843f2d0964bd0444fa6bdbb1ee79dc838cfa4452
baseline version:
ovmf
88 matches
Mail list logo
