Hello,
In QubesOS I had the following issue
(https://github.com/QubesOS/qubes-issues/issues/4321):
When I create a HVM and passthrough a GPU (pci device), it seems to
trash the memory of the guest and either prevent the HVM to be started
or prevent the GPU to be used.
Looking more at the deta
flight 183969 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183969/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183961
test-amd64-amd64-xl-qemut-win7-amd64
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-6.7a-rc4-tag
xen: branch for v6.7-rc4
It contains 2 fixes:
- A fix for the Xen event driver setting the correct return value when
experiencing an allocation failure
- A fix for al
Pipeline #1091754937 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: def73fc1 (
https://gitlab.com/xen-project/xen/-/commit/def73fc14407252cc801f35cd7746e60ccd70884
)
Commit Message: automation/ec
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> On Thu, Nov 30, 2023 at 07:15:17PM -0800, Stefano Stabellini wrote:
> > On Thu, 30 Nov 2023, Roger Pau Monné wrote:
> > > On Wed, Nov 29, 2023 at 07:53:59PM -0800, Stefano Stabellini wrote:
> > > > On Fri, 24 Nov 2023, Jiqian Chen wrote:
> > > > > This p
On Mon, 27 Nov 2023, Jan Beulich wrote:
> On 24.11.2023 18:29, Simone Ballarin wrote:
> > Rule 13.1: Initializer lists shall not contain persistent side effects
> >
> > The assignment operation in:
> >
> > .irq = rc = uart->irq,
> >
> > is a persistent side effect in a struct initializer list.
>
On Fri, 24 Nov 2023, Simone Ballarin wrote:
> Rule 13.1: Initializer lists shall not contain persistent side effects
>
> Invocations of functions in initializer lists cause violations of rule
> 13.1 if the called functions are not tagged with __attribute_pure__ or
> __attribute_const__ as they can
On Fri, 24 Nov 2023, Federico Serafini wrote:
> Tag arm64/efibind.h as "adopted":
> it is used to build the efi stub, which is a separate entry point
> for Xen when booted from EFI firmware.
>
> Tag common/coverage/* as "out-of-scope":
> it is code to support gcov, hence it is part of the testing
On Mon, Nov 27, 2023 at 06:00:57PM +0100, Jan Beulich wrote:
> On 24.11.2023 02:47, Marek Marczykowski-Górecki wrote:
> > GCC gets confused about 'desc' variable:
> >
> > arch/x86/hvm/vmsi.c: In function ‘msixtbl_range’:
> > arch/x86/hvm/vmsi.c:553:8: error: ‘desc’ may be used uninitialize
On Fri, 1 Dec 2023, Jan Beulich wrote:
> On 01.12.2023 03:47, Stefano Stabellini wrote:
> > On Wed, 29 Nov 2023, Nicola Vetrini wrote:
> >> No functional change.
> >>
> >> Signed-off-by: Nicola Vetrini
> >> ---
> >> The preferred way to deviate is to use asmlinkage, but this modification
> >> is
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> On Mon, Nov 13, 2023 at 05:21:13PM -0500, Stewart Hildebrand wrote:
> > @@ -1618,6 +1630,14 @@ int iommu_do_pci_domctl(
> > bus = PCI_BUS(machine_sbdf);
> > devfn = PCI_DEVFN(machine_sbdf);
> >
> > +if ( needs_vpci(d) && !has_
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> > > @@ -1261,6 +1269,7 @@ struct xen_sysctl {
> > > struct xen_sysctl_livepatch_op livepatch;
> > > #if defined(__i386__) || defined(__x86_64__)
> > > struct xen_sysctl_cpu_policycpu_policy;
> > > +struct xen_sysct
In xen-all.c there are unneeded dependencies on xen-legacy-backend.c:
- xen_init() uses xen_pv_printf() to report errors, but it does not
provide a pointer to the struct XenLegacyDevice, so it is kind of
useless, we can use standard error_report() instead.
- xen-all.c has function xenstore_re
From: Oleksandr Tyshchenko
The bridge is needed for virtio-pci support, as QEMU can emulate the
whole bridge with any virtio-pci devices connected to it.
This patch provides a flexible way to configure PCIe bridge resources
using QEMU machine properties. We made this for several reasons:
- We d
This patch makes legacy backends optional. As was discussed at [1]
this is a solution to a problem when we can't run QEMU as a device
model in a non-privileged domain. This is because legacy backends
assume that they are always running in domain with ID = 0. Actually,
this may prevent running QEMU
Xen PV devices in QEMU can be created in two ways: either by QEMU
itself, if they were passed via command line, or by Xen toolstack. In
the latter case, QEMU scans XenStore entries and configures devices
accordingly.
In the second case we don't want QEMU to write/delete front-end
entries for two r
From: David Woodhouse
This allows a XenDevice implementation to know whether it was created
by QEMU, or merely discovered in XenStore after the toolstack created
it. This will allow us to create frontend/backend nodes only when we
should, rather than unconditionally attempting to overwrite them f
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest vi
From: Oleksandr Andrushchenko
Use a previously introduced per-domain read/write lock to check
whether vpci is present, so we are sure there are no accesses to the
contents of the vpci struct if not. This lock can be used (and in a
few cases is used right away) so that vpci removal can be performe
This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.
in v11:
- Added my Signed-off-by tag to all patches
- Patch "vpci/header: emulate PCI_COMMAND register for guests" is in
intermediate state, because it was agreed to rewor
Previously pci_enable_msi() function obtained pdev pointer by itself,
but taking into account upcoming changes to PCI locking, it is better
when caller passes already acquired pdev pointer to the function,
because caller knows better how to obtain the pointer and which locks
are needed to be used.
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity
Introduce "fail" label in init_bars() function to have the centralized
error return path. This is the pre-requirement for the future changes
in this function.
This patch does not introduce functional changes.
Signed-off-by: Volodymyr Babchuk
Suggested-by: Roger Pau Monné
Acked-by: Roger Pau Mon
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an error back to MMIO handler, otherwise it is possible to
provide more data than requested: i.e. guest issues LDRB instruction
to read one byte, but we are w
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
Plea
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs g
Add per-domain d->pci_lock that protects access to
d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
that underlying pdev will not disappear under feet. This is a rw-lock,
but this patch adds only write_lock()s. There will be read_lock()
users in the next patches.
This lock sho
From: Stewart Hildebrand
Move iomem_caps initialization earlier (before arch_domain_create()).
Signed-off-by: Stewart Hildebrand
Signed-off-by: Volodymyr Babchuk
---
Changes in v10:
* fix off-by-one
* also permit access to GUEST_VPCI_PREFETCH_MEM_ADDR
Changes in v9:
* new patch
This is sort
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by: Oleksan
This function can be used when user wants to remove all rangeset
entries but do not want to destroy rangeset itself.
Signed-off-by: Volodymyr Babchuk
---
Changes in v11:
- Now the function only empties rangeset, without removing it from
domain's list
Changes in v10:
- New in v10. The funct
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned we need to
initialize/de-initialize vPCI state for the device.
Also, rename vpci_add_handlers() to vpci_assign_device() and
vpci_remove_device() to vpci_deassign_device() to better reflect role
of the functions.
Signed-of
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that rangese
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's view of this will want to be zero initially, the host having set
it to 1 may not easily be overwritten with 0, or else
flight 183965 xen-unstable real [real]
flight 183970 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183965/
http://logs.test-lab.xenproject.org/osstest/logs/183970/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Hi,
On 01/12/2023 00:01, Timothy Pearson wrote:
- Original Message -
From: "Julien Grall"
To: "Timothy Pearson"
Cc: "Shawn Anastasio" , "xen-devel"
, "Jan Beulich"
, "Daniel P. Smith" , "Stefano
Stabellini" ,
"Bertrand Marquis" , "Michal Orzel" ,
"Oleksii"
Sent: Friday, December
On Fri, Dec 1, 2023 at 9:44 PM Stefano Stabellini
wrote:
> By the informal
> voting, we have 3 against "broken" and 2 in favor (not 1 as George wrote
> as Andrew's vote counts too).
Just to clarify: The opinions on that thread (if you include all
versions of the series) were:
Andy, Daniel for ke
- Original Message -
> From: "Julien Grall"
> To: "Timothy Pearson"
> Cc: "Shawn Anastasio" , "xen-devel"
> , "Jan Beulich"
> , "Daniel P. Smith" ,
> "Stefano Stabellini" ,
> "Bertrand Marquis" , "Michal Orzel"
> , "Oleksii"
>
> Sent: Friday, December 1, 2023 4:35:55 PM
> Subject:
Hi,
On 01/12/2023 22:10, tpear...@raptorengineering.com wrote:
(+ Arm and RISC-V folks)
Hi Shawn,
On 01/12/2023 20:59, Shawn Anastasio wrote:
Adapt arm's earlyfdt parsing code to ppc64 and enable Xen's early boot
allocator. Routines for parsing arm-specific devicetree nodes (e.g.
multiboot) w
flight 183968 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183968/
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
Replying here on a couple of different people on this thread.
On Thu, 30 Nov 2023, Tamas K Lengyel wrote:
> I think this form is bad and is not helpful.
I agree with Tamas and (also Jan) that this form is not helpful.
On Fri, 1 Dec 2023, George Dunlap wrote:
> If most people in the community
flight 183961 linux-linus real [real]
flight 183967 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183961/
http://logs.test-lab.xenproject.org/osstest/logs/183967/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
> (+ Arm and RISC-V folks)
>
> Hi Shawn,
>
> On 01/12/2023 20:59, Shawn Anastasio wrote:
>> Adapt arm's earlyfdt parsing code to ppc64 and enable Xen's early boot
>> allocator. Routines for parsing arm-specific devicetree nodes (e.g.
>> multiboot) were excluded, reducing the overall footprint of co
(+ Arm and RISC-V folks)
Hi Shawn,
On 01/12/2023 20:59, Shawn Anastasio wrote:
Adapt arm's earlyfdt parsing code to ppc64 and enable Xen's early boot
allocator. Routines for parsing arm-specific devicetree nodes (e.g.
multiboot) were excluded, reducing the overall footprint of code that
was cop
Some headers are common between several architectures, so the current patch
series
provide them.
Another one reason to have them as generic is a simplification of adding support
necessary to make a complete Xen build as it was/is being done in the patch
series [1]
and [2].
Also, instead of prov
The header is shared between several archs so it is
moved to asm-generic.
Switch partly Arm and PPC to asm-generic/monitor.h and only
arch_monitor_get_capabilities() left in arch-specific/monitor.h.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5:
- Switched partly Arm
ifdefing inclusion of in
allows to avoid generation of empty header
for the case when !CONFIG_MEM_ACCESS.
For Arm it was explicitly added inclusion of for p2m.c
and traps.c because they require some functions from which
aren't available in case of !CONFIG_MEM_ACCESS.
Suggested-by: Jan Beulic
Arm, PPC and RISC-V use the same device.h thereby device.h
was moved to asm-generic. Arm's device.h was taken as a base with
the following changes:
- #ifdef PCI related things.
- #ifdef ACPI related things.
- Rename #ifdef guards.
- Add SPDX tag.
- #ifdef CONFIG_HAS_DEVICE_TREE related things.
is common through some archs so it is moved
to asm-generic.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Michal Orzel
Acked-by: Jan Beulich
Acked-by: Shawn Anastasio
---
Changes in V5:
- Added Acked-by: Jan Beulich
- Updated the comment around first_valid_mfn. ( Arm -> GENERIC )
- Adde
is common between Arm, PPC and RISC-V so it is
moved to asm-generic.
Drop Arm and PPC's softirq.h and use asm-generic version instead.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Michal Orzel
Acked-by: Jan Beulich
Acked-by: Shawn Anastasio
---
Changes in V5:
- Strayed "Added" in commit mes
Ifdef-ing inclusion of allows to avoid
generation of empty for cases when
CONFIG_GRANT_TABLE is not enabled.
The following changes were done for Arm:
should be included directly because it contains
gnttab_dom0_frames() macros which is unique for Arm and is used in
arch/arm/domain_build.c.
is #
All archs have the do_div implementation for BITS_PER_LONG == 64
so do_div64.h is moved to asm-generic.
x86 and PPC were switched to asm-generic version of div64.h.
Arm was switched partly because Arm has different implementation
for 32-bits.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
When I move a domain from pool0 with credit2 to any pool with credit(1) I get
the following crash.
Software: Xen-4.17.3 / Qubes OS 4.2.0-RC5
Firmware: Dasharo 0.9.0 - Z790P
Hardware: 13900K
(XEN) Xen BUG at common/sched/credit.c:1051(XEN) [ Xen-4.17.3-pre x86_64
debug=y Not tainted ]
On 01/12/2023 7:59 pm, René Winther Højgaard wrote:
> If I set smt=off and try to configure cpupools with credit(1) as if
> all cores are available, I get the following crash.
>
> The crash happens when I try to use xl cpupool-add-cpu on the disabled
> HT sibling cores.
>
> Hyper-threading is ena
If I set smt=off and try to configure cpupools with credit(1) as if all cores
are available, I get the following crash.
The crash happens when I try to use xl cpupool-add-cpu on the disabled HT
sibling cores.
Hyper-threading is enabled in the firmware, and only disabled with smt=off.
So
Adapt arm's earlyfdt parsing code to ppc64 and enable Xen's early boot
allocator. Routines for parsing arm-specific devicetree nodes (e.g.
multiboot) were excluded, reducing the overall footprint of code that
was copied.
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/Makefile| 1 +
Hello all,
This series enables the Xen boot time allocator on Power by parsing
the available memory regions from the firmware-provided device tree.
The device tree processing and bookkeeping code was adapted from Arm,
but it was trimmed down to exclude code for parsing Arm-specific dt
nodes.
Add
In the initial mm-radix implementation, the in-memory partition and
process tables required to configure the MMU were allocated statically
since the boot allocator was not yet available.
Now that it is, allocate these tables at runtime and bump the size of
the Process Table to its maximum supporte
Now that we have common code building, there's no need to keep the old
itoa64+debug print function in mm-radix.c
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/mm-radix.c | 58 +
1 file changed, 12 insertions(+), 46 deletions(-)
diff --git a/xen/arch/ppc
On Fri, Nov 10, 2023 at 1:41 PM Juergen Gross wrote:
> +static void fill_buffer(struct ring *ring, uint8_t cmd, uint16_t tag,
> +const char *fmt, ...)
> +{
> +struct p9_header *hdr = ring->buffer;
> +void *data = hdr + 1;
> +const char *f;
> +const void *par
Hi Jan,
On 30/11/2023 08:36, Jan Beulich wrote:
On 29.11.2023 14:10, Anthony PERARD wrote:
On Wed, Nov 29, 2023 at 11:47:24AM +0100, Julien Grall wrote:
+ Anthony for the tools
+ Juergen for Xenstored
On 29/11/2023 11:34, Alexander Kanavin wrote:
On 11/29/23 08:51, Jan Beulich wrote:
On 28
Hi Luca,
On 30/11/2023 13:17, Luca Fancellu wrote:
On 30 Nov 2023, at 09:57, Michal Orzel wrote:
Move static event channel feature related code to a separate module
(static-evtchn.{c,h}) in the spirit of fine granular configuration, so
that the feature can be disabled if not needed.
Introduce
Currently if user enables HVC_DCC config option in Linux, it invokes
access to debug data transfer registers (ie DBGDTRTX_EL0 on arm64,
DBGDTRTXINT on arm32). As these registers are not emulated, Xen injects
an undefined exception to the guest. And Linux crashes.
We wish to avoid this crash by add
On 01/12/2023 18:47, Julien Grall wrote:
From: Julien Grall
Several maintainers have expressed a stronger preference
to use '-' when in filename and option that contains multiple
words.
So document it in CODING_STYLE.
Signed-off-by: Julien Grall
---
CODING_STYLE | 9 +
1 file c
flight 183966 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183966/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70b174e24db4a6de1590fda65846074dcb9fd7d3
baseline version:
ovmf 534021965f6f7c417610a
From: Julien Grall
Several maintainers have expressed a stronger preference
to use '-' when in filename and option that contains multiple
words.
So document it in CODING_STYLE.
Signed-off-by: Julien Grall
---
CODING_STYLE | 9 +
1 file changed, 9 insertions(+)
diff --git a/CODING_STY
On Wed, Nov 29, 2023 at 02:55:53PM -0500, Stefan Hajnoczi wrote:
> The AioContext lock no longer exists.
>
> There is one noteworthy change:
>
> - * More specifically, these functions use BDRV_POLL_WHILE(bs), which
> - * requires the caller to be either in the main thread and hold
> - * the
On Wed, Nov 29, 2023 at 02:55:52PM -0500, Stefan Hajnoczi wrote:
> The AioContext lock no longer exists.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> include/qemu/job.h | 20
> 1 file changed, 20 deletions(-)
>
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engi
On 2023-11-30 17:41, Jan Beulich wrote:
On 29.11.2023 16:24, Nicola Vetrini wrote:
The comment referred to the declaration for do_mca, which
now is part of hypercall-defs.h, therefore the comment is stale.
If the comments were stale, the #include-s should also be able to
disappear?
--- a/xen
Currently, Xen vPCI only supports virtualizing the MSI and MSI-X capabilities.
Hide all other PCI capabilities (including extended capabilities) from domUs for
now, even though there may be certain devices/drivers that depend on being able
to discover certain capabilities.
We parse the physical PC
Introduce a handler for the PCI status register, with ability to mask
the capabilities bit. The status register contains RsvdZ bits,
read-only bits, and write-1-to-clear bits. Additionally, we use RsvdP to
mask the capabilities bit. Introduce bitmasks to handle these in vPCI.
If a bit in the bitmas
This small series enables vPCI to filter which PCI capabilities we expose to a
domU. This series adds vPCI register handlers within
xen/drivers/vpci/header.c:init_bars(), along with some supporting functions.
Note there are minor rebase conflicts with the in-progress vPCI series [1].
These conflic
flight 183959 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183959/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-installfail pass in 183952
Tests which did not succeed, but
On 01/12/23 14:48, Julien Grall wrote:
On 01/12/2023 13:42, Simone Ballarin wrote:
On 01/12/23 12:48, Julien Grall wrote:
Hi Simone,
On 01/12/2023 11:37, Simone Ballarin wrote:
From: Maria Celeste Cesario
Remove or amend casts to comply with Rule 11.8.
The violations are resolved either
On 01/12/2023 13:42, Simone Ballarin wrote:
On 01/12/23 12:48, Julien Grall wrote:
Hi Simone,
On 01/12/2023 11:37, Simone Ballarin wrote:
From: Maria Celeste Cesario
Remove or amend casts to comply with Rule 11.8.
The violations are resolved either by adding missing const
qualifiers in c
On 01/12/23 14:03, Jan Beulich wrote:
On 01.12.2023 12:48, Julien Grall wrote:
On 01/12/2023 11:37, Simone Ballarin wrote:
--- a/xen/arch/arm/include/asm/regs.h
+++ b/xen/arch/arm/include/asm/regs.h
@@ -48,7 +48,7 @@ static inline bool regs_mode_is_32bit(const struct
cpu_user_regs *regs)
On 01/12/23 12:48, Julien Grall wrote:
Hi Simone,
On 01/12/2023 11:37, Simone Ballarin wrote:
From: Maria Celeste Cesario
Remove or amend casts to comply with Rule 11.8.
The violations are resolved either by adding missing const
qualifiers in casts or by removing unnecessary cast.
Change ty
flight 183963 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183963/
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 01.12.2023 12:48, Julien Grall wrote:
> On 01/12/2023 11:37, Simone Ballarin wrote:
>> --- a/xen/arch/arm/include/asm/regs.h
>> +++ b/xen/arch/arm/include/asm/regs.h
>> @@ -48,7 +48,7 @@ static inline bool regs_mode_is_32bit(const struct
>> cpu_user_regs *regs)
>>
>> static inline bool gue
On 01.12.2023 12:31, Roger Pau Monné wrote:
> On Fri, Dec 01, 2023 at 11:59:09AM +0100, Jan Beulich wrote:
>> On 01.12.2023 11:21, Roger Pau Monné wrote:
>>> On Fri, Dec 01, 2023 at 10:41:45AM +0100, Jan Beulich wrote:
On 01.12.2023 09:50, Roger Pau Monné wrote:
> On Fri, Dec 01, 2023 at 0
On Thu, Nov 30, 2023 at 06:02:55PM +0100, Jan Beulich wrote:
> On 28.11.2023 11:03, Roger Pau Monne wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/test-smc.c
> > @@ -0,0 +1,68 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> >
On Wed, Nov 29, 2023 at 06:58:38PM -0800, Stefano Stabellini wrote:
> On Tue, 28 Nov 2023, Roger Pau Monne wrote:
> > Introduce a helper to perform checks related to self modifying code, and
> > start
> > by creating a simple test to check that alternatives have been applied.
> >
> > Such test is
On 01/12/2023 11:20, Juergen Gross wrote:
Flexible arrays in public headers can be problematic with some
compilers.
With XEN_FLEX_ARRAY_DIM there is a mechanism available to deal with
this issue, but care must be taken to not change the affected structs
in an incompatible way.
So bump __XEN_
Hi Simone,
On 01/12/2023 11:37, Simone Ballarin wrote:
From: Maria Celeste Cesario
Remove or amend casts to comply with Rule 11.8.
The violations are resolved either by adding missing const
qualifiers in casts or by removing unnecessary cast.
Change type of operands from char* to uintptr_t:
From: Maria Celeste Cesario
Remove or amend casts to comply with Rule 11.8.
The violations are resolved either by adding missing const
qualifiers in casts or by removing unnecessary cast.
Change type of operands from char* to uintptr_t: uintptr_t is
the appropriate type for memory address opera
On Fri, Dec 01, 2023 at 11:59:09AM +0100, Jan Beulich wrote:
> On 01.12.2023 11:21, Roger Pau Monné wrote:
> > On Fri, Dec 01, 2023 at 10:41:45AM +0100, Jan Beulich wrote:
> >> On 01.12.2023 09:50, Roger Pau Monné wrote:
> >>> On Fri, Dec 01, 2023 at 07:53:29AM +0100, Jan Beulich wrote:
> On 3
On 01.12.2023 12:20, Juergen Gross wrote:
> Flexible arrays in public headers can be problematic with some
> compilers.
>
> With XEN_FLEX_ARRAY_DIM there is a mechanism available to deal with
> this issue, but care must be taken to not change the affected structs
> in an incompatible way.
>
> So
Hi Juergen,
> On Dec 1, 2023, at 19:20, Juergen Gross wrote:
>
> Flexible arrays in public headers can be problematic with some
> compilers.
>
> With XEN_FLEX_ARRAY_DIM there is a mechanism available to deal with
> this issue, but care must be taken to not change the affected structs
> in an in
Flexible arrays in public headers can be problematic with some
compilers.
With XEN_FLEX_ARRAY_DIM there is a mechanism available to deal with
this issue, but care must be taken to not change the affected structs
in an incompatible way.
So bump __XEN_LATEST_INTERFACE_VERSION__ and introduce a new
On 01.12.2023 11:21, Roger Pau Monné wrote:
> On Fri, Dec 01, 2023 at 10:41:45AM +0100, Jan Beulich wrote:
>> On 01.12.2023 09:50, Roger Pau Monné wrote:
>>> On Fri, Dec 01, 2023 at 07:53:29AM +0100, Jan Beulich wrote:
On 30.11.2023 18:37, Roger Pau Monné wrote:
> On Thu, Nov 30, 2023 at 0
On Thu, Nov 30, 2023 at 10:28 PM Stefano Stabellini
wrote:
>
> Hi all,
>
> This vote is in the context of this thread:
> https://marc.info/?l=xen-devel&m=169213351810075
To add slightly more context.
The issue here is more than a simple "should we use the word broken or
not". We already have a
On Fri, Dec 01, 2023 at 10:41:45AM +0100, Jan Beulich wrote:
> On 01.12.2023 09:50, Roger Pau Monné wrote:
> > On Fri, Dec 01, 2023 at 07:53:29AM +0100, Jan Beulich wrote:
> >> On 30.11.2023 18:37, Roger Pau Monné wrote:
> >>> On Thu, Nov 30, 2023 at 05:55:07PM +0100, Jan Beulich wrote:
> On 2
This matches the flags of the .livepatch.funcs section when generated using
livepatch-build-tools, which only sets the SHT_ALLOC flag.
Also constify the definitions of the livepatch_func variables in the tests
themselves, in order to better match the resulting output. Note that just
making those
On 28.11.23 21:42, Jason Andryuk wrote:
On Wed, Nov 15, 2023 at 1:14 AM Juergen Gross wrote:
On 14.11.23 21:53, Julien Grall wrote:
Hi Juergen,
On 14/11/2023 09:26, Juergen Gross wrote:
On 14.11.23 10:10, Julien Grall wrote:
Hi Juergen,
On 14/11/2023 06:45, Juergen Gross wrote:
On 13.11.
On 01.12.2023 09:50, Roger Pau Monné wrote:
> On Fri, Dec 01, 2023 at 07:53:29AM +0100, Jan Beulich wrote:
>> On 30.11.2023 18:37, Roger Pau Monné wrote:
>>> On Thu, Nov 30, 2023 at 05:55:07PM +0100, Jan Beulich wrote:
On 28.11.2023 11:03, Roger Pau Monne wrote:
> The minimal function size
Hi Stefano,
On 30/11/2023 22:27, Stefano Stabellini wrote:
Hi all,
This vote is in the context of this thread:
https://marc.info/?l=xen-devel&m=169213351810075
Thanks for providing the context + CCing committers.
First I will echo what Jan said and mention that providing context to
the vote
On Mon, Nov 13, 2023 at 05:21:13PM -0500, Stewart Hildebrand wrote:
> @@ -1618,6 +1630,14 @@ int iommu_do_pci_domctl(
> bus = PCI_BUS(machine_sbdf);
> devfn = PCI_DEVFN(machine_sbdf);
>
> +if ( needs_vpci(d) && !has_vpci(d) )
> +{
> +printk(XENLOG_G_W
On Nov 6, 2023, at 13:53, Kelly Choi wrote:
>
> Hi all,
>
> As an open-source community, there will always be differences of opinion in
> approaches and the way we think. It is imperative, however, that we view this
> diversity as a source of strength rather than a hindrance.
>
> Recent deli
On Fri, Dec 01, 2023 at 02:05:54AM +, Volodymyr Babchuk wrote:
>
> Hi Roger, Stewart,
>
> Roger Pau Monné writes:
>
> > On Thu, Oct 12, 2023 at 10:09:18PM +, Volodymyr Babchuk wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> Xen and/or Dom0 may have put values in PCI_COMMAND which
1 - 100 of 107 matches
Mail list logo
