flight 185198 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185198/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7fde22823d64cb7b9f2a65bb87ffb7581f5ff84e
baseline version:
ovmf
Hi Jan,
On 3/12/2024 1:07 AM, Jan Beulich wrote:
+/*
+ * Flag to force populate physmap to use pages from domheap instead of 1:1
+ * or static allocation.
+ */
+#define XENMEMF_force_heap_alloc (1<<19)
#endif
If this is for populate_physmap only, then other sub-ops need to reject
its use.
On 2024/3/29 01:32, Anthony PERARD wrote:
> On Thu, Mar 28, 2024 at 02:34:01PM +0800, Jiqian Chen wrote:
>> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
>> index 96cb4da0794e..2cec83e0b734 100644
>> --- a/tools/libs/light/libxl_pci.c
>> +++
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski :
On Wed, 27 Mar 2024 13:14:56 +0100 you wrote:
> Notice that skb_mark_for_recycle() is introduced later than fixes tag in
> 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
>
> It is believed that fixes
On Thu, Mar 28, 2024 at 9:00 AM Jürgen Groß wrote:
>
> Hi Jason,
>
> On 28.03.24 02:24, Jason Andryuk wrote:
> > On Wed, Mar 27, 2024 at 7:46 AM Jürgen Groß wrote:
> >>
> >> On 24.01.24 17:54, Jason Andryuk wrote:
> >>> +
> >>> + return new;
> >>> + }
> >>> +
I encountered platform, namely Qualcomm SA8155P where SMMU-compatible
IO-MMU advertises more context IQRs than there are context banks. This
should not be an issue, we need to relax the check in the SMMU driver
to allow such configuration.
Signed-off-by: Volodymyr Babchuk
---
Generic Interface (GENI) is a newer interface for low speed interfaces
like UART, I2C or SPI. This patch adds the simple driver for the UART
instance of GENI. Code is based on similar drivers in U-Boot and Linux
kernel.
This driver implements only simple synchronous mode, because although
GENI
Hello,
This three patches are all what is needed to run Xen on Qualcomm
SA8155P. At the time of writing, I have a working setup with
(almost) mainline Linux kernel in Dom0, where basic features like UFS
and networking are working fine, but more advanced things like GPU are
not supported yet.
Qualcomm SA8155P is the automotive variant of SM8150 aka Snapdragon
855.
This patch adds very basic support for the platform. We need to handle
Qualcomm-specific SMC to workaround quirk in the QCOM SCM driver in
the Linux kernel. Basically the driver tries multiple different SMCs
to determine
flight 185196 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185196/
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 Wed, Mar 27, 2024 at 01:14:56PM +0100, Jesper Dangaard Brouer wrote:
> Notice that skb_mark_for_recycle() is introduced later than fixes tag in
> 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
>
> It is believed that fixes tag were missing a call to
flight 185180 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185180/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185171
On 28/03/2024 3:35 pm, Roger Pau Monne wrote:
> There's no reason to assume VGA text mode 3 to be unconditionally available.
> With the addition of booting Xen itself in PVH mode there's a boot path that
> explicitly short-circuits all the real-mode logic, including the VGA
> detection.
>
> Leave
On 28/03/2024 3:35 pm, Roger Pau Monne wrote:
> Currently the offsets into the boot_video_info struct are manually encoded in
> video.S, which is fragile. Generate them in asm-offsets.c and switch the
> current code to use those instead.
>
> No functional change intended.
>
> Signed-off-by: Roger
On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
pc_system_flash_create() is only useful for PCI-based machines.
Move the call to the PCI-based init() handler.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 2 +-
hw/i386/pc_sysfw.c | 10 --
2 files changed, 5
On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
x86_bios_rom_init() is the single non-PCI-machine call
from pc_system_firmware_init(). Extract it to the caller.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 6 +-
hw/i386/pc_sysfw.c | 5 +
2 files changed, 6
On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
acpi_setup() caller knows about the machine state, so pass
it as argument to avoid a qdev_get_machine() call.
We already resolved X86_MACHINE(pcms) as 'x86ms' so use the
latter.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.h |
Hi,
Replying to myself.
On 27/03/2024 13:48, Julien Grall wrote:
On 27/03/2024 13:38, Jan Beulich wrote:
On 27.03.2024 14:28, Julien Grall wrote:
Hi Carlo,
On 27/03/2024 11:10, Carlo Nonato wrote:
Hi guys,
Question is: How would you justify such a change? IOW I'm not
convinced
(yet)
Hi Jason,
On Wed, Mar 20, 2024 at 01:42:27PM -0400, Jason Andryuk wrote:
> Hi Dmitry,
>
> Do you have any feedback, or can you pick up this patch? It solves a
> real issue affecting udev, which crashes the Debian installer and
> breaks the mouse for Gnome.
>
> Or would you be okay if this
Hi Bertrand,
On 27/03/2024 13:40, Bertrand Marquis wrote:
Hi Jens,
On 25 Mar 2024, at 10:39, Jens Wiklander wrote:
Move memory sharing routines into a separate file for easier navigation
in the source code.
Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
On Mon, Mar 18, 2024 at 04:55:09PM +, Anthony PERARD wrote:
> I intend to push this series in two waves.
>
> First, push up to commit "Temporally switch "qemu-mainline" branch to
> Bookworm". This is to test that osstest still works fine if we need to use
> "buster" for a branch. Also
On Thu, Mar 28, 2024 at 02:34:01PM +0800, Jiqian Chen wrote:
> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
> index 96cb4da0794e..2cec83e0b734 100644
> --- a/tools/libs/light/libxl_pci.c
> +++ b/tools/libs/light/libxl_pci.c
> @@ -1478,8 +1478,14 @@ static void
On 27.03.2024 22:51, Jason Andryuk wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -468,6 +468,7 @@ void elf_parse_binary(struct elf_binary *elf)
> {
> ELF_HANDLE_DECL(elf_phdr) phdr;
> uint64_t low = -1, high = 0, paddr, memsz;
> +
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.
Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.
Thus we
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.
When it
I have experience with the IMX8QXP, and the supported parts of the IMX8QM
are identical.
Help review patches touching these areas.
---
v3:
- New patch (Bertrand Marquis)
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
The format of these calls are as follows:
- reg 0: function ID
-
On Thu, Mar 28, 2024 at 08:22:31AM -0700, Elliott Mitchell wrote:
> On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> > On 27.03.2024 18:27, Elliott Mitchell wrote:
> > > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> > >> On Mon, Mar 25, 2024 at 08:55:56AM +0100,
Extract the ISA-only PC machine code from pc_piix.c
to a new file, pc_isa.c.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 1 +
hw/i386/pc_isa.c| 33 +
hw/i386/pc_piix.c | 23 ---
hw/i386/meson.build | 1 +
4 files
acpi_setup() caller knows about the machine state, so pass
it as argument to avoid a qdev_get_machine() call.
We already resolved X86_MACHINE(pcms) as 'x86ms' so use the
latter.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.h | 3 ++-
hw/i386/acpi-build.c | 5 ++---
hw/i386/pc.c
South bridge type is only relevant for the i440fx/piix
machine, which is PCI-based.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 8
hw/i386/pc.c | 3 ++-
hw/i386/pc_piix.c| 12 ++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git
All PCI-based machines have the smbios_defaults field
set to %true. Simplify by using an inlined helper
checking whether the machine is PCI-based or not.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
hw/i386/fw_cfg.c | 7 ++-
hw/i386/pc.c | 1 -
We are going to refactor fw_cfg_build_smbios() in the
next patches. In order to avoid too much #ifdef'ry in
it, define a stub.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/fw_cfg-smbios-stub.c | 15 +++
hw/i386/fw_cfg.c | 4 ++--
hw/i386/meson.build | 1 +
Only PCI-based machines use the set of parallel flash devices.
Move the fields from PCMachineState to PcPciMachineState.
Directly pass a PcPciMachineState argument to the
pc_system_flash/fw methods.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 10
hw/i386/pc.c
All PCI-based machines have the smbios_legacy_mode
field set to %false. Simplify by using an inlined
helper checking whether the machine is PCI-based or
not.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
hw/i386/fw_cfg.c | 8 ++--
hw/i386/pc_piix.c| 2 --
3
All PCI-based machines have the gigabyte_align field
set to %true. Simplify by using an inlined helper
checking whether the machine is PCI-based or not.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 9 -
hw/i386/pc.c | 1 -
hw/i386/pc_piix.c| 16
Keep fw_cfg_build_smbios() for PCI-based machines, call
fw_cfg_build_smbios_legacy() directly from pc_machine_done().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/fw_cfg.c | 10 --
hw/i386/pc.c | 12 +++-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git
pc_system_flash_create() is only useful for PCI-based machines.
Move the call to the PCI-based init() handler.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 2 +-
hw/i386/pc_sysfw.c | 10 --
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/hw/i386/pc.c
flight 185172 xen-4.18-testing real [real]
flight 185182 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185172/
http://logs.test-lab.xenproject.org/osstest/logs/185182/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Since CXL helpers expect a PCI-based machine, we
can directly pass them a PcPciMachineState argument.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index
Factor fw_cfg_build_smbios_legacy() out of
fw_cfg_build_smbios().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/fw_cfg.h | 1 +
hw/i386/fw_cfg-smbios-stub.c | 4
hw/i386/fw_cfg.c | 33 ++---
3 files changed, 27 insertions(+), 11
pc_init1() is specific to the isapc and i440fx/piix machines,
rename it as pc_piix_init(). Expose it in "hw/i386/pc.h" to
be able to call it externally (see next patch).
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 +
hw/i386/pc_piix.c| 8
hw/isa/piix.c
"fw_cfg.h" declares fw_cfg_build_smbios() which use
SmbiosEntryPointType, itself declared in "qapi-types-machine.h".
void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
SmbiosEntryPointType ep_type);
All PCI-based machines have the has_reserved_memory
field set to %true. Simplify by using an inlined helper
checking whether the machine is PCI-based or not.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
hw/i386/pc.c | 17 ++---
hw/i386/pc_piix.c
pc_pci_hole64_start() is only used by PCI-based
machines. Pass it a PcPciMachineState argument,
removing a qdev_get_machine() call.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 2 +-
hw/i386/pc.c | 8
hw/pci-host/i440fx.c | 2 +-
hw/pci-host/q35.c| 2 +-
smbios_defaults() and smbios_legacy_mode() are logical
opposite. Simplify using the latter.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/fw_cfg.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index ffa60a4a33..df05fe060c
x86_bios_rom_init() is the single non-PCI-machine call
from pc_system_firmware_init(). Extract it to the caller.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 6 +-
hw/i386/pc_sysfw.c | 5 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/i386/pc.c
acpi_setup() returns early if acpi_build_enabled is not set:
2752 void acpi_setup(PCMachineState *pcms)
2753 {
...
2768 if (!pcms->acpi_build_enabled) {
2769 ACPI_BUILD_DPRINTF("ACPI build disabled. Bailing out.\n");
2770 return;
2771 }
acpi_build_enabled
Since only PCI-based machines use the 'acpi_build_enabled',
move it to PcPciMachineState.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.h | 2 +-
include/hw/i386/pc.h | 3 ++-
hw/i386/acpi-build.c | 8
hw/i386/pc.c | 5 ++---
hw/i386/xen/xen-hvm.c | 3 ++-
5
CXL depends on PCIe, which isn't available on non-PCI
machines such the ISA-only PC one.
Move CXLState to PcPciMachineState, and move the CXL
specific calls to pc_pci_machine_initfn() and
pc_pci_machine_done().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 3 ++-
PCMachineClass::has_acpi_build is always %true for PCI
based machines. Remove it, setting the 'acpi_build_enabled'
field once in pc_pci_machine_initfn().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 3 ---
hw/i386/pc.c | 6 +++---
hw/i386/pc_piix.c| 1 -
3 files
The 'pci_root_uid' field is irrelevant for non-PCI
machines, restrict it to the PcPciMachineClass.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 4 +++-
hw/i386/acpi-build.c | 9 +++--
hw/i386/pc_piix.c| 7 +--
hw/i386/pc_q35.c | 7 +--
4 files changed, 20
Introduce TYPE_PC_PCI_MACHINE for machines where PCI
is expected (as opposition to the ISA-only PC machine).
This type inherits from the well known TYPE_PC_MACHINE.
Convert I440FX/PIIX and Q35 machines to use it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 25
fw_cfg_add_extra_pci_roots() expects a PCI bus, which only
PCI-based machines have. No need to call it on the ISA-only
machine. Move it to the PCI-specific machine_done handler.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
All TYPE_PC_PCI_MACHINE-based machines have pci_enabled
set to %true. By checking a TYPE_PC_MACHINE inherits the
TYPE_PC_PCI_MACHINE base class, we don't need this field
anymore.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
hw/i386/pc.c | 3 +--
Introduce the pc_machine_is_pci_enabled() helper to be
able to alter PCMachineClass fields later.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 2 ++
hw/i386/pc.c | 11 +--
hw/i386/pc_piix.c| 11 ++-
hw/i386/pc_q35.c | 2 +-
Currently PC machines are based on TYPE_PC_MACHINE.
In preparation of being based on different types,
pass the current type as argument.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 4 ++--
hw/i386/pc_piix.c| 9 +
hw/i386/pc_q35.c | 3 ++-
3 files changed, 9
Hi Igor,
This is the first steps to decouple the isapc VS q35/i440fx
machines. A new TYPE_PC_PCI_MACHINE is introduced to help
differentiating. Fields unrelated to the legacy isapc are
moved to the new PcPciMachineState structure.
More work remain in hw/i386/pc_piix.c so we can build a
binary
When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.
In few commits we are going to add more types, so replace
the type_register_static() to ease further reviews.
flight 185181 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185181/
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, Mar 28, 2024 at 03:05:47PM +, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 10:07 AM Roger Pau Monné wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:43PM +, Ross Lagerwall wrote:
> > > Binaries may be built with entry points above 4G. While bootloaders may
> > > relocate them below
Currently the offsets into the boot_video_info struct are manually encoded in
video.S, which is fragile. Generate them in asm-offsets.c and switch the
current code to use those instead.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/boot/video.S | 83
There's no reason to assume VGA text mode 3 to be unconditionally available.
With the addition of booting Xen itself in PVH mode there's a boot path that
explicitly short-circuits all the real-mode logic, including the VGA detection.
Leave the default user selected mode as text mode 3 in
Hello,
The current video logic reports wrong values when booted in PVH mode, as
that boot path explicitly skips real-mode logic, and thus avoids any VGA
video detection.
First patch is cleanup of the offset declarations in boot_video_info.
Second patch attempts to fix Xen in PVH mode reporting
On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> On 27.03.2024 18:27, Elliott Mitchell wrote:
> > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> >> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> >>> On 22.03.2024 20:22, Elliott Mitchell wrote:
>
On Tue, Nov 14, 2023 at 03:38:15PM +0100, Philippe Mathieu-Daudé wrote:
> Previous commits re-organized the target-specific bits
> from Xen files. We can now build the common files once
> instead of per-target.
>
> Only 4 files call libxen API (thus its CPPFLAGS):
> - xen-hvm-common.c,
> -
This patch series implements support for loading and verifying a signed
xen binary. This would allow the same xen binary to be used for BIOS
boot, UEFI boot, and UEFI boot with Secure Boot verification.
There is an accompanying Xen patch series.
The first patch updates the multiboot2
Add the ability to load multiboot binaries in PE format. This allows the
binaries to be signed and verified.
Signed-off-by: Ross Lagerwall
---
grub-core/Makefile.core.def | 1 +
grub-core/loader/multiboot.c | 7 +
grub-core/loader/multiboot_mbi2.c | 11 +-
GRUB doesn't do anything with multiboot modules except loading them and
passing a pointer to the multiboot kernel. Therefore GRUB itself doesn't
need to verify the module. Multiboot modules may contain code that needs
to be verified. If this is the case, the expectation is that the
multiboot
Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).
In addition to the existing address and ELF load types, specify
In addition to building xen.efi and xen.gz, build xen-mbi.exe. The
latter is a PE binary that can be used with a multiboot2 loader that
supports loading PE binaries.
Using this option allows the binary to be signed and verified by Shim.
This means the same xen-mbi.exe binary can then be used for
Now that the multiboot2 binary can be verified by Shim, ensure that the
dom0 kernel is verified when using the multiboot2 path. If the Shim
protocol is not available and the SecureBoot variable is not set to 0
(or the state cannot be determined), abort the boot.
Signed-off-by: Ross Lagerwall
---
Hi,
This patches series implements support for building a multiboot-capable
PE binary in addition to the existing xen.efi and xen.gz. The purpose of
this is to allow the same binary to be booted using BIOS, UEFI, and UEFI
with Secure Boot verification just like it can be done with a Linux
kernel.
On Tue, Mar 19, 2024 at 10:07 AM Roger Pau Monné wrote:
>
> On Wed, Mar 13, 2024 at 03:07:43PM +, Ross Lagerwall wrote:
> > Binaries may be built with entry points above 4G. While bootloaders may
> > relocate them below 4G, it should be possible for the binary to specify
> > those entry
On Fri, Mar 15, 2024 at 7:31 AM Vladimir 'phcoder' Serbinenko
wrote:
>
> Not a full review. Just one blocking problem
>
>>
>>
>> }
>> + case MULTIBOOT_LOAD_TYPE_PE:
>> + grub_fatal ("Unsupported load type: %u\n", mld.load_type);
>> + default:
>> +/* should be impossible */
>> +
On 28.03.2024 14:14, Andrew Cooper wrote:
> These variables predate the introduction of __ro_after_init, but all qualify.
> Update them to be consistent with the rest of the file.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
These variables predate the introduction of __ro_after_init, but all qualify.
Update them to be consistent with the rest of the file.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/spec_ctrl.c | 20 ++--
1 file
Hi Jason,
On 28.03.24 02:24, Jason Andryuk wrote:
On Wed, Mar 27, 2024 at 7:46 AM Jürgen Groß wrote:
On 24.01.24 17:54, Jason Andryuk wrote:
+
+ return new;
+ }
+ }
+
end = start + npg * PAGE_SIZE - 1;
WARN_ONCE(1, "CPA detected W^X
On 28.03.2024 11:57, George Dunlap wrote:
> On Thu, Mar 28, 2024 at 6:44 AM Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
> __clear_bit(0x80,
On Thu, Mar 28, 2024 at 6:44 AM Jan Beulich wrote:
> > As to why to have each vendor independent code check for HAP -- there
> > are in fact two implementations of the code; it's nice to be able to
> > look in one place for each implementation to determine the
> > requirements. Additionally, it
On 28/03/24 11:31, Jan Beulich wrote:
On 28.03.2024 11:29, Simone Ballarin wrote:
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
In the title, s/20.7/17.1/ I suppose?
Jan
Functions
flight 185171 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185171/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185012
On 28.03.2024 11:29, Simone Ballarin wrote:
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
In the title, s/20.7/17.1/ I suppose?
Jan
> Functions hypercall_create_continuation and
MISRA C Rule 20.7 states: "The features of `' shall not be used".
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal helper functions made to break long running hypercalls into
multiple
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
Add deviation for printf()-like functions.
Signed-off-by: Simone Ballarin
---
Changes in v3:
- use regex to exempt all .*printk and .*printf functions,
On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
>
>If the value being stored in an object is read from
Ping?
On Wed, Feb 07, 2024 at 03:55:46PM +0100, Roger Pau Monne wrote:
> Introduce a new Kconfig check for whether the compiler supports
> -falign-functions and if supported use it to align functions to the per-arch
> selected value, just like it's done for assembly ENTRY() and FUNC() symbols.
>
On 28.03.2024 10:31, Jan Beulich wrote:
> On 27.03.2024 19:13, le...@solinno.co.uk wrote:
>> From: Leigh Brown
>>
>> Rework xenwatchdogd signal handling to do the minimum in the signal
>> handler. This is a very minor enhancement.
>> ---
>> tools/misc/xenwatchdogd.c | 20
>>
On 27.03.2024 19:13, le...@solinno.co.uk wrote:
> From: Leigh Brown
>
> Make all functions except main() static in xenwatchdogd.c.
And once at it data then too, please.
Jan
On 27.03.2024 19:13, le...@solinno.co.uk wrote:
> From: Leigh Brown
>
> Rework xenwatchdogd signal handling to do the minimum in the signal
> handler. This is a very minor enhancement.
> ---
> tools/misc/xenwatchdogd.c | 20
> 1 file changed, 12 insertions(+), 8
When device on dom0 side has been reset, the vpci on Xen side
won't get notification, so that the cached state in vpci is
all out of date with the real device state.
To solve that problem, add a new function to clear all vpci
device state when device is reset on dom0 side.
And call that function
There is a need for some scenarios to use gsi sysfs.
For example, when xen passthrough a device to dumU, it will
use gsi to map pirq, but currently userspace can't get gsi
number.
So, add gsi sysfs for that and for other potential scenarios.
Co-developed-by: Huang Rui
Signed-off-by: Jiqian Chen
In PVH dom0, the gsis don't get registered, but the gsi of
a passthrough device must be configured for it to be able to be
mapped into a domU.
When assign a device to passthrough, proactively setup the gsi
of the device during that process.
Co-developed-by: Huang Rui
Signed-off-by: Jiqian Chen
Hi All,
This is v5 series to support passthrough on Xen when dom0 is PVH.
patch#2 change function acpi_pci_irq_lookup from a static function to
non-static, need ACPI Maintainer to give some comments.
patch#3 linux internal changes, need PCI and ACPI Maintainer to give more
comments.
v4->v5
On 27.03.2024 18:01, George Dunlap wrote:
> On Mon, Mar 18, 2024 at 2:17 PM Jan Beulich wrote:
>> On 13.03.2024 13:24, George Dunlap wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -673,6 +673,12 @@ int arch_sanitise_domain_config(struct
>>> xen_domctl_createdomain
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
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes
Some type of domain don't have PIRQ, like PVH, when
passthrough a device to guest on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will failed
at domain_pirq_to_irq.
So, add a new hypercall to grant/revoke gsi permission
when dom0 is not PV or dom0 has not PIRQ flag.
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see
xen_pt_realize->xc_physdev_map_pirq and
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 allowed because currd is
Hi All,
This is v6 series to support passthrough when dom0 is PVH
v5->v6 changes:
* patch#1: Add Reviewed-by Stefano and Stewart. Rebase code and change old
function vpci_remove_device, vpci_add_handlers to vpci_deassign_device,
vpci_assign_device
* patch#2: Add Reviewed-by Stefano
* patch#3:
1 - 100 of 105 matches
Mail list logo
