On 2024/6/17 22:52, Jan Beulich wrote:
> On 17.06.2024 11:00, Jiqian Chen wrote:
>> The gsi of a passthrough device must be configured for it to be
>> able to be mapped into a hvm domU.
>> But When dom0 is PVH, the gsis don't get registered, it causes
>> the info of apic, pin and irq not be added i
flight 186387 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186387/
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 2024/6/17 22:45, Jan Beulich wrote:
> On 17.06.2024 11:00, Jiqian Chen wrote:
>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>> a passthrough device by using gsi, see qemu code
>> xen_pt_realize->xc_physdev_map_pirq and libxl code
>> pci_add_dm_done->xc_physdev_map_pirq. Then
Am 18.06.24 um 02:57 schrieb Demi Marie Obenour:
On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki
wrote:
> On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roger Pau Monné wrote:
>> On Sun, Jun 16, 2024 at 08:38:19PM -0400, Demi Marie Obenour wrote:
>>> In both cases, the device phy
On 2024/6/17 22:17, Jan Beulich wrote:
> On 17.06.2024 11:00, Jiqian Chen wrote:
>> --- a/xen/drivers/pci/physdev.c
>> +++ b/xen/drivers/pci/physdev.c
>> @@ -2,11 +2,17 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #ifndef COMPAT
>> typedef long ret_t;
>> #endif
>>
>> +sta
flight 186385 linux-linus real [real]
flight 186388 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186385/
http://logs.test-lab.xenproject.org/osstest/logs/186388/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 6/16/24 23:04, Christoph Hellwig wrote:
> Fold blk_flush_policy into the only caller to prepare for pending changes
> to it.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Bart Van Assche
> Reviewed-by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
> ---
>
Looks good.
Reviewed-by:
On 6/16/24 23:04, Christoph Hellwig wrote:
> queue_attr_store updates attributes used to control generating I/O, and
> can cause malformed bios if changed with I/O in flight. Freeze the queue
> in common code instead of adding it to almost every attribute.
>
> Signed-off-by: Christoph Hellwig
> Re
On 6/16/24 23:04, Christoph Hellwig wrote:
> virtblk_update_cache_mode boils down to a single call to
> blk_queue_write_cache. Remove it in preparation for moving the cache
> control flags into the queue_limits.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Bart Van Assche
> Reviewed-by: Ste
On 6/16/24 23:04, Christoph Hellwig wrote:
> Since commit 7437bb73f087 ("block: remove support for the host aware zone
> model"), only ZBC devices expose a zoned access model. sd_is_zoned is
> used to check for that and thus return false for host aware devices.
>
> Replace the helper with the simp
On Mon, 10 Jun 2024, Nicola Vetrini wrote:
> On 2024-06-10 09:43, Jan Beulich wrote:
> > On 07.06.2024 22:13, Nicola Vetrini wrote:
> > > Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are added
> > > to the list of clean guidelines.
> >
> > Why is 20.9 being mentioned here when
On Fri, 7 Jun 2024, Nicola Vetrini wrote:
> The DEFINE macro in asm-offsets.c (for all architectures) still generates
> violations despite the file(s) being excluded from compliance, due to the
> fact that in its expansion it sometimes refers entities in non-excluded files.
> These corner cases are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roger Pau Monné wrote:
> > On Sun, Jun 16, 2024 at 08:38:19PM -0400, Demi Marie Obenour wrote:
> > > In both cases, the device phy
On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roger Pau Monné wrote:
> On Sun, Jun 16, 2024 at 08:38:19PM -0400, Demi Marie Obenour wrote:
> > In both cases, the device physical
> > addresses are identical to dom0’s physical addresses.
>
> Yes, but a PV dom0 physical address space can be very scattere
flight 186381 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186381/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-qcow2 8 xen-boot fail in 186377 pass in 186381
test-armhf-armhf-xl-raw 8 x
struct type_descriptor is arranged with a NUL terminated string following the
kind/info fields.
The only reason this doesn't trip UBSAN detection itself (on more modern
compilers at least) is because struct type_descriptor is only referenced in
suppressed regions.
Switch the declaration to be a r
Only minor changes in v4 vs v3. See patches for details.
The end result has been tested across the entire XenServer hardware lab. This
found several false assupmtion about how the dynamic sizes behave.
Patches 1 and 6 the main bugfixes from this series. There's still lots more
work to do in or
Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for
every call. This is expensive, being used for domain create/migrate, as well
as to service certain guest CPUID instructions.
Instead, arrange to check the sizes once at boot. See the code comments for
details. Right
First, if XSAVE is available in hardware but not visible to the guest, the
dynamic leaves shouldn't be filled in.
Second, the comment concerning XSS state is wrong. VT-x doesn't manage
host/guest state automatically, but there is provision for "host only" bits to
be set, so the implications are s
The clobbering of this_cpu(xcr0) and this_cpu(xss) to architecturally invalid
values is to force the subsequent set_xcr0() and set_msr_xss() to reload the
hardware register.
While XCR0 is reloaded in xstate_init(), MSR_XSS isn't. This causes
get_msr_xss() to return the invalid value, and logic of
Make use of xstate_uncompressed_size() helper rather than maintaining the
running calculation while accumulating feature components.
The rest of the CPUID data can come direct from the raw cpu policy. All
per-component data form an ABI through the behaviour of the X{SAVE,RSTOR}*
instructions.
Us
This is a tangle, but it's a small step in the right direction.
In the following change, xstate_init() is going to start using the Raw policy.
calculate_raw_cpu_policy() is sufficiently separate from the other policies to
safely move like this.
No functional change.
Signed-off-by: Andrew Cooper
With the exception of one case in read_bndcfgu() which can use ilog2(),
the *_POS defines are unused. Drop them.
X86_XCR0_X87 is the name used by both the SDM and APM, rather than
X86_XCR0_FP.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Ro
We're soon going to need a compressed helper of the same form.
The size of the uncompressed image depends on the single element with the
largest offset + size. Sadly this isn't always the element with the largest
index.
Name the per-xstate-component cpu_policy struture, for legibility of the log
On 17/06/2024 11:25 am, Jan Beulich wrote:
> On 14.06.2024 20:26, Andrew Cooper wrote:
>> On 23/05/2024 4:44 pm, Jan Beulich wrote:
>>> On 23.05.2024 13:16, Andrew Cooper wrote:
This is a tangle, but it's a small step in the right direction.
xstate_init() is shortly going to want dat
flight 186382 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186382/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 128513afcdfa77e94c9637e643898e61c8218e34
baseline version:
ovmf 9fc61309bf56aa7863e36
On Mon, Jun 17, 2024 at 05:39:23PM +0200, Jan Beulich wrote:
> On 17.06.2024 17:17, Demi Marie Obenour wrote:
> > On Mon, Jun 17, 2024 at 11:07:54AM +0200, Jan Beulich wrote:
> >> On 14.06.2024 18:44, Demi Marie Obenour wrote:
> >>> On Fri, Jun 14, 2024 at 10:12:40AM +0200, Jan Beulich wrote:
> >>>
On 17.06.2024 17:17, Demi Marie Obenour wrote:
> On Mon, Jun 17, 2024 at 11:07:54AM +0200, Jan Beulich wrote:
>> On 14.06.2024 18:44, Demi Marie Obenour wrote:
>>> On Fri, Jun 14, 2024 at 10:12:40AM +0200, Jan Beulich wrote:
On 14.06.2024 09:21, Roger Pau Monné wrote:
> I'm not sure it's p
On 17/06/2024 3:40 pm, Anthony PERARD wrote:
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index 3545f3fd..d974fea5 100644
> --- a/Osstest/Debian.pm
> +++ b/Osstest/Debian.pm
> @@ -972,7 +972,19 @@ END
> # is going to be added to dom0's initrd, which is used by some guests
>
On 17.06.2024 11:00, Jiqian Chen wrote:
> Some type of domain don't have PIRQs, like PVH, it doesn't do
> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
> to guest base on PVH dom0, callstack
> pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
> domain_pirq_to_irq, becaus
On Mon, Jun 17, 2024 at 11:07:54AM +0200, Jan Beulich wrote:
> On 14.06.2024 18:44, Demi Marie Obenour wrote:
> > On Fri, Jun 14, 2024 at 10:12:40AM +0200, Jan Beulich wrote:
> >> On 14.06.2024 09:21, Roger Pau Monné wrote:
> >>> I'm not sure it's possible to ensure that when using system RAM such
On 17.06.2024 11:00, Jiqian Chen wrote:
> In PVH dom0, it uses the linux local interrupt mechanism,
> when it allocs irq for a gsi, it is dynamic, and follow
> the principle of applying first, distributing first. And
> irq number is alloced from small to large, but the applying
> gsi number is not,
On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roger Pau Monné wrote:
> On Sun, Jun 16, 2024 at 08:38:19PM -0400, Demi Marie Obenour wrote:
> > On Fri, Jun 14, 2024 at 10:39:37AM +0200, Roger Pau Monné wrote:
> > > On Fri, Jun 14, 2024 at 10:12:40AM +0200, Jan Beulich wrote:
> > > > On 14.06.2024 09:21,
Hello Xen Community!
I'm on the lookout for volunteers who are willing to host some local Xen
events or workshops.
The goal of our meetups is to connect our community members. Meetups allow
members (that’s you) to network, collaborate, and have a pulse on their
local network. We welcome professio
On 17.06.2024 11:00, Jiqian Chen wrote:
> The gsi of a passthrough device must be configured for it to be
> able to be mapped into a hvm domU.
> But When dom0 is PVH, the gsis don't get registered, it causes
> the info of apic, pin and irq not be added into irq_2_pin list,
> and the handler of irq_
On 17.06.2024 11:00, Jiqian Chen wrote:
> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
> a passthrough device by using gsi, see qemu code
> xen_pt_realize->xc_physdev_map_pirq and libxl code
> pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
> will call into Xen, but
From: Anthony PERARD
We have a few machine (arndale-*) that have a nic without mac address,
so the kernel assign a random one. For those there's a flags
"force-mac-address" which tells osstest to make it so that the machine
changes the mac address to a predefined one at boot. This normally
tells
On Mon, Jun 17, 2024 at 04:22:21PM +0200, Jan Beulich wrote:
> On 17.06.2024 16:13, Frediano Ziglio wrote:
> > Current timer tick is causing some deadline to fail.
> > The current high value constant was probably due to an old
> > bug in the Xen timer implementation causing errors if the
> > deadli
On Mon, Jun 17, 2024 at 08:04:53AM +0200, Christoph Hellwig wrote:
> @@ -352,7 +355,6 @@ enum blk_bounce {
No more users of "enum blk_bounce" after this, so you can delete that
too.
> struct queue_limits {
> unsigned intfeatures;
> unsigned intflags;
> - e
On 17.06.2024 16:03, Marek Marczykowski-Górecki wrote:
> On Mon, Jun 17, 2024 at 01:22:37PM +0200, Jan Beulich wrote:
>> Hello,
>>
>> while it feels like we had a similar situation before, I can't seem to be
>> able to find traces thereof, or associated (Linux) commits.
>
> Is it some AMD Threadri
On 17.06.2024 16:13, Frediano Ziglio wrote:
> Current timer tick is causing some deadline to fail.
> The current high value constant was probably due to an old
> bug in the Xen timer implementation causing errors if the
> deadline was in the future.
> This was fixed in Xen commit:
> 19c6cbd90965 xe
On 17.06.2024 11:00, Jiqian Chen wrote:
> --- a/xen/drivers/pci/physdev.c
> +++ b/xen/drivers/pci/physdev.c
> @@ -2,11 +2,17 @@
> #include
> #include
> #include
> +#include
>
> #ifndef COMPAT
> typedef long ret_t;
> #endif
>
> +static const struct pci_device_state_reset_method
> +
Current timer tick is causing some deadline to fail.
The current high value constant was probably due to an old
bug in the Xen timer implementation causing errors if the
deadline was in the future.
This was fixed in Xen commit:
19c6cbd90965 xen/vcpu: ignore VCPU_SSHOTTMR_future
Signed-off-by: Fred
On Mon, Jun 17, 2024 at 01:22:37PM +0200, Jan Beulich wrote:
> Hello,
>
> while it feels like we had a similar situation before, I can't seem to be
> able to find traces thereof, or associated (Linux) commits.
Is it some AMD Threadripper system by a chance? Previous thread on this
issue:
https://
On 14.06.2024 18:12, Alessandro Zucchelli wrote:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -593,79 +593,79 @@ int __init e820_add_range(uint64_t s, uint64_t e,
> uint32_t type)
> }
>
> int __init e820_change_range_type(
> -struct e820map *e820, uint64_t s, uint64_t e,
>
On 14.06.2024 18:12, Alessandro Zucchelli wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4703,7 +4703,7 @@ long arch_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> struct xen_foreign_memory_map fmap;
> struct domain *d;
> -st
On 13.06.2024 16:58, Alessandro Zucchelli wrote:
> This addresses violations of MISRA C:2012 Rule 7.3 which states as
> following: The lowercase character `l' shall not be used in a literal
> suffix.
>
> Changed moreover suffixes 'u' in 'U' for better readability next to
> the 'L's.
>
> No functi
On 17.06.2024 15:36, Teddy Astie wrote:
> Le 13/06/2024 à 16:32, Jan Beulich a écrit :
>> On 13.06.2024 15:50, Teddy Astie wrote:
>>> @@ -214,6 +215,38 @@ struct xen_add_to_physmap_range {
>>> };
>>> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
>>>
>>> +/*
>>> + * With some legacy d
flight 186379 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186379/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9fc61309bf56aa7863e36b8f418a49ca6d8364d0
baseline version:
ovmf 587100a95d7bfddc60bc5
On 13.06.2024 18:56, Roger Pau Monne wrote:
> fixup_irqs() is used to evacuate interrupts from to be offlined CPUs. Given
> the CPU is to become offline, the normal migration logic used by Xen where the
> vector in the previous target(s) is left configured until the interrupt is
> received on the
Le 13/06/2024 à 16:32, Jan Beulich a écrit :
> On 13.06.2024 15:50, Teddy Astie wrote:
>> @@ -214,6 +215,38 @@ struct xen_add_to_physmap_range {
>> };
>> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
>>
>> +/*
>> + * With some legacy devices, certain guest-physical addresses cannot safe
On 13.06.2024 18:56, Roger Pau Monne wrote:
> Currently there's logic in fixup_irqs() that attempts to prevent
> _assign_irq_vector() from failing, as fixup_irqs() is required to evacuate all
> interrupts from the CPUs not present in the input mask. The current logic in
> fixup_irqs() is incomplet
On 13.06.2024 18:56, Roger Pau Monne wrote:
> Given the current logic it's possible for ->arch.old_cpu_mask to get out of
> sync: if a CPU set in old_cpu_mask is offlined and then onlined
> again without old_cpu_mask having been updated the data in the mask will no
> longer be accurate, as when bro
flight 186377 linux-linus real [real]
flight 186380 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186377/
http://logs.test-lab.xenproject.org/osstest/logs/186380/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 17/06/24 12:03, Jan Beulich wrote:
On 17.06.2024 11:49, Federico Serafini wrote:
MISRA C Rule 16.4 states that every `switch' statement shall have a
`default' label" and a statement or a comment prior to the
terminating break statement.
This patch addresses some violations of the rule relate
On 17.06.2024 13:18, Andrew Cooper wrote:
> On 17/06/2024 10:54 am, Jan Beulich wrote:
>> On 14.06.2024 19:07, Andrew Cooper wrote:
>>> More fallout from looking at the code generation...
>>>
>>> for_each_set_bit() forces it's bitmap parameter out into memory. For an
>>> arbitrary sized bitmap, th
Hello,
while it feels like we had a similar situation before, I can't seem to be
able to find traces thereof, or associated (Linux) commits.
With
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x400
...
(XEN) Dom0 alloc.: 00044000->00044800 (619175 pages to be
a
On 17/06/2024 10:54 am, Jan Beulich wrote:
> On 14.06.2024 19:07, Andrew Cooper wrote:
>> More fallout from looking at the code generation...
>>
>> for_each_set_bit() forces it's bitmap parameter out into memory. For an
>> arbitrary sized bitmap, this is fine - and likely preferable as it's an
>>
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the bounce flag into the features field to reclaim a little bit of
space.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-settings.c| 1 -
block/blk.h | 2 +-
drivers/scsi/scsi_lib.c | 2 +-
include
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the skip_tagset_quiesce flag into the queue_limits feature field so
that it can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/nvme/host/core.c
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the pci_p2pdma flag into the queue_limits feature field so that it
can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/nvme/host/core.c | 8 +++--
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the zone_resetall flag into the queue_limits feature field so that
it can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/block/null_blk/zo
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the zoned flags into the features field to reclaim a little
bit of space.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-settings.c | 5 ++---
drivers/block/null_blk/zoned.c | 2 +-
drivers/block/ublk_d
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the poll flag into the queue_limits feature field so that it can
be set atomically with the queue frozen.
Stacking drivers are simplified in that they now can simply set the
flag, and blk_stack_limits will clear it when the features is not
supporte
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the dax flag into the queue_limits feature field so that it can be
set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/md/dm-table.c| 4 ++--
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the nowait flag into the queue_limits feature field so that it can
be set atomically with the queue frozen.
Stacking drivers are simplified in that they now can simply set the
flag, and blk_stack_limits will clear it when the features is not
suppor
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the synchronous flag into the queue_limits feature field so that it
can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c| 1 -
drivers/block/brd.c
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the stable_writes flag into the queue_limits feature field so that
it can be set atomically with the queue frozen.
The flag is now inherited by blk_stack_limits, which greatly simplifies
the code in dm, and fixed md which previously did not pass on
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the io_stat flag into the queue_limits feature field so that it can
be set atomically with the queue frozen.
Simplify md and dm to set the flag unconditionally instead of avoiding
setting a simple flag for cases where it already is set by other mea
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the add_random flag into the queue_limits feature field so that it
can be set atomically with the queue frozen.
Note that this also removes code from dm to clear the flag based on
the underlying devices, which can't be reached as dm devices will
al
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the nonrot flag into the queue_limits feature field so that it can
be set atomically with the queue frozen.
Use the chance to switch to defaulting to non-rotational and require
the driver to opt into rotational, which matches the polarity of the
sy
On 6/17/24 08:04, Christoph Hellwig wrote:
Move the cache control settings into the queue_limits so that the flags
can be set atomically with the device queue frozen.
Add new features and flags field for the driver set flags, and internal
(usually sysfs-controlled) flags in the block layer. Not
On 14.06.2024 20:26, Andrew Cooper wrote:
> On 23/05/2024 4:44 pm, Jan Beulich wrote:
>> On 23.05.2024 13:16, Andrew Cooper wrote:
>>> This is a tangle, but it's a small step in the right direction.
>>>
>>> xstate_init() is shortly going to want data from the Raw policy.
>>> calculate_raw_cpu_polic
On 14.06.2024 15:56, Andrew Cooper wrote:
> On 23/05/2024 4:34 pm, Jan Beulich wrote:
>> On 23.05.2024 13:16, Andrew Cooper wrote:
>>> Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in
>>> for
>>> every call. This is expensive, being used for domain create/migrate, as
>>
On 6/17/24 08:04, Christoph Hellwig wrote:
Move a bit of code that sets up the zone flag and the write granularity
into sd_zbc_read_zones to be with the rest of the zoned limits.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 21 +
drivers/scsi/sd_zbc.c | 9
On 6/17/24 08:04, Christoph Hellwig wrote:
blkfront always had a robust negotiation protocol for detecting a write
cache. Stop simply disabling cache flushes in the block layer as the
flags handling is moving to the atomic queue limits API that needs
user context to freeze the queue for that. I
On 17.06.2024 11:49, Federico Serafini wrote:
> MISRA C Rule 16.4 states that every `switch' statement shall have a
> `default' label" and a statement or a comment prior to the
> terminating break statement.
>
> This patch addresses some violations of the rule related to the
> "notifier pattern":
flight 186378 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186378/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 587100a95d7bfddc60bc5699ae0cca45914f1d81
baseline version:
ovmf a7dbd2ac7b359644b4961
On 14.06.2024 19:07, Andrew Cooper wrote:
> More fallout from looking at the code generation...
>
> for_each_set_bit() forces it's bitmap parameter out into memory. For an
> arbitrary sized bitmap, this is fine - and likely preferable as it's an
> in-memory to begin with.
>
> However, more than
MISRA C Rule 16.4 states that every `switch' statement shall have a
`default' label" and a statement or a comment prior to the
terminating break statement.
This patch addresses some violations of the rule related to the
"notifier pattern": a frequently-used pattern whereby only a few values
are ha
Hi Daniel,
On 2024/6/17 17:00, Jiqian Chen wrote:
> Some type of domain don't have PIRQs, like PVH, it doesn't do
> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
> to guest base on PVH dom0, callstack
> pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
> domain_pirq_to_
On 17.06.2024 02:38, Demi Marie Obenour wrote:
> On Fri, Jun 14, 2024 at 10:39:37AM +0200, Roger Pau Monné wrote:
>> On Fri, Jun 14, 2024 at 10:12:40AM +0200, Jan Beulich wrote:
>>> On 14.06.2024 09:21, Roger Pau Monné wrote:
On Fri, Jun 14, 2024 at 08:38:51AM +0200, Jan Beulich wrote:
> O
On 14.06.2024 18:44, Demi Marie Obenour wrote:
> On Fri, Jun 14, 2024 at 10:12:40AM +0200, Jan Beulich wrote:
>> On 14.06.2024 09:21, Roger Pau Monné wrote:
>>> I'm not sure it's possible to ensure that when using system RAM such
>>> memory comes from the guest rather than the host, as it would lik
On 14.06.2024 18:35, Demi Marie Obenour wrote:
> On Fri, Jun 14, 2024 at 08:38:51AM +0200, Jan Beulich wrote:
>> On 13.06.2024 20:43, Demi Marie Obenour wrote:
>>> 2. Add support for `XEN_DOMCTL_memory_mapping` to use system RAM, not
>>>just IOMEM. Mappings made with `XEN_DOMCTL_memory_mapping
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
irq number is alloced from small to large, but the applying
gsi number is not, may gsi 38 comes before gsi 28, that
causes the i
Some type of domain don't have PIRQs, like PVH, it doesn't do
PHYSDEVOP_map_pirq for each gsi. When passthrough a device
to guest base on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
domain_pirq_to_irq, because PVH has no mapping of gsi, pirq and
irq on Xen s
Hi All,
This is v10 series to support passthrough when dom0 is PVH
v9->v10 changes:
* patch#2: Indent the comments above PHYSDEVOP_map_pirq according to the code
style.
* patch#3: Modified the description in the commit message, changing "it calls"
to "it will need to call",
indicating
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see qemu code
xen_pt_realize->xc_physdev_map_pirq and libxl code
pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
is not allo
The gsi of a passthrough device must be configured for it to be
able to be mapped into a hvm domU.
But When dom0 is PVH, the gsis don't get registered, it causes
the info of apic, pin and irq not be added into irq_2_pin list,
and the handler of irq_desc is not set, then when passthrough a
device, s
When a device has been reset on dom0 side, the vpci on Xen
side won't get notification, so the cached state in vpci is
all out of date compare with the real device state.
To solve that problem, add a new hypercall to clear all vpci
device state. When the state of device is reset on dom0 side,
dom0
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The helper macro bitmap_switch has parameters that cannot be parenthesized
in order to comply with the rule, as that would break its functionality.
Moreover, the risk of misus
Hi all,
this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.
Note that by applying this series the rule has a few leftover violations.
Mo
Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
1 file changed, 1 insertion(+),
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The local helpers GRP2 and XADD in the x86 emulator use their first
argument as the constant expression for a case label. This pattern
is deviated project-wide, because it is
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
flight 186376 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186376/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 8 xen-boot fail pass in 186367
Tests which did not succeed, but
> On 11 Jun 2024, at 10:14, Jan Beulich wrote:
>
> On 11.06.2024 10:00, Petr Beneš wrote:
>> On Tue, Jun 11, 2024 at 8:41 AM Jan Beulich wrote:
>>>
>>> On 10.06.2024 19:10, Petr Beneš wrote:
From: Petr Beneš
Encapsulate the altp2m options within a struct. This change is prep
On Mon, Jun 17, 2024 at 08:04:28AM +0200, Christoph Hellwig wrote:
> blkfront always had a robust negotiation protocol for detecting a write
> cache. Stop simply disabling cache flushes in the block layer as the
> flags handling is moving to the atomic queue limits API that needs
> user context to
1 - 100 of 102 matches
Mail list logo
