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 30b6d08e27c767ba9756a
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 b/xen/arch/x86/hvm/hypercal
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 29/
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 a
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):
test-amd6
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 safe
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.
>>>
>>
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 t
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 lim
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 843f2d0964bd0444fa6bd
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 wri
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
> boilerplate
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 tryin
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:
> * Mo
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
> host
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 Cooper
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 ha
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
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: ae26101
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 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 sti
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 init_irq
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 cd4cebabf5834c403c9d9
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 c
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 {c,o}xen
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
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 th
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
>>
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 c695e3182aa7497833f1b
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 migrate-s
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: ae26101f6bfc
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 4.1
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 emulate
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, Jiqia
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 ra
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 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);
>
> nod
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)
> +{
> +BUG_ON("unimpleme
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 unnecessa
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 opt
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 @@
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 1
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:
>
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 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 a/xen/arch/riscv/include/as
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 +48
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
>>> +++ b/xe
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
> #in
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
test-amd64-amd64-xl-qemut-win7-amd64
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?
>
> However
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 8285
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 |
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 functional
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, gai
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 9518d77eb869034a14179
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 b/
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
>
>
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 irq_ack_non
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 actu
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:
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 cap
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 dow
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 ha
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 q
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 a
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:
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 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 limits.
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:
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
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
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 e7848481160b270ebc59d
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,
> u
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 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
> > CC:
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 b
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 Marczyk
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 t
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 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
> >
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 ced13b93afea87a8a1fe6
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 fall
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 Beu
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 a8dc6bf73f789f38f2930
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 1
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):
test-amd6
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 declaration
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 few
On 30.05.2024 21:52, 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:
>> - GCC 5.1
On 30.05.2024 19:23, 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?
The latter, iirc. In fact I h
On 30.05.2024 20:40, Andrew Cooper wrote:
> Any non-stub implementation of these is going to have to do something here.
For whatever definition of "something", seeing ...
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -31,12 +31,12 @@ struct irq_guest
> unsigned int virq;
> };
>
On Fri, May 31, 2024 at 7:54 AM Christoph Hellwig wrote:
>
> 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
On Fri, May 31, 2024 at 08:48:12AM +0200, Ilya Dryomov wrote:
> We should revert io_opt from opts->alloc_size to objset_bytes (I think
> it's what you meant to say but typoed).
Yes, sorry.
> How do you want to handle it? I can put together a patch, send it to
> ceph-devel and it will be picked b
On 2024-05-31 03:14, Stefano Stabellini wrote:
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 inpu
94 matches
Mail list logo
