Hi,
On 21/11/2023 19:31, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/11/2023 17:18, Michal Orzel wrote:
>>
>>
>> On 21/11/2023 18:04, Julien Grall wrote:
>>>
>>>
>>> On 21/11/2023 17:00, Michal Orzel wrote:
Hi Julien,
>>>
>>> Hi,
>>>
On 21/11/2023 17:09, Julien Grall wrote:
>
On 21.11.2023 18:31, Andrew Cooper wrote:
> On 21/11/2023 5:27 pm, Jan Beulich wrote:
>> On 21.11.2023 17:24, Roger Pau Monné wrote:
>>> On Thu, Nov 16, 2023 at 02:31:05PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -2163,6
There's nothing else that should need doing in order for guests to be
able to use these insns, as the encodings are in what's otherwise NOP
space.
Signed-off-by: Jan Beulich
---
v2: gen-cpuid adjustment.
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -220,6 +220,8 @@ static const
Don't let this end in SEGV, due to the subsequent NULL deref.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -2189,6 +2189,13 @@ void do_test(uint8_t *instr, unsigned in
{
s = x86_decode_insn(ctxt, fetch);
+
Hi Juergen,
> On Nov 22, 2023, at 15:21, Juergen Gross wrote:
>
> In order to build caml-stubdom, it must be explicitly enabled via
> "configure --enable-caml-stubdom". The build process is failing due to
> stubdom/ocaml.patch failing to apply. Since the patched file has been
> modified in 2014
In order to build caml-stubdom, it must be explicitly enabled via
"configure --enable-caml-stubdom". The build process is failing due to
stubdom/ocaml.patch failing to apply. Since the patched file has been
modified in 2014 the last time, it seems nobody cares for caml-stubdom
since at least then.
On 21.11.23 22:14, Andrew Cooper wrote:
On 20/11/2023 10:36 am, Juergen Gross wrote:
On 01.11.23 17:08, Juergen Gross wrote:
In order to build caml-stubdom, it must be explicitly enabled via
"configure --enable-caml-stubdom". The build process is failing due to
stubdom/ocaml.patch failing to
flight 183817 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183817/
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
Pipeline #1080914423 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 820ee3ec (
https://gitlab.com/xen-project/xen/-/commit/820ee3ec4dd5679715bd49a1d12b81cb1502260c
)
Commit Message: x86: add
On Mon, 20 Nov 2023, Stefano Stabellini wrote:
> On Mon, 20 Nov 2023, Juergen Gross wrote:
> > On 20.11.23 03:21, osstest service owner wrote:
> > > flight 183794 linux-linus real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/183794/
> > >
> > > Regressions :-(
> > >
> > > Tests
On Tue, 21 Nov 2023, Jan Beulich wrote:
> On 01.11.2023 10:30, Nicola Vetrini wrote:
> > The patches in this series aim to fix or deviate various instances where a
> > function or variable do not have a declaration visible when such entity is
> > defined (in violation of MISRA C:2012 Rule 8.4).
>
On Mon, 20 Nov 2023, Julien Grall wrote:
> On 18/11/2023 02:46, Stefano Stabellini wrote:
> > On Fri, 17 Nov 2023, Andrew Cooper wrote:
> > > On 17/11/2023 10:17 am, Nicola Vetrini wrote:
> > > > Hi all,
> > > >
> > > > As discussed in this thread [1], which is about complying with MISRA C
> > >
On Mon, 20 Nov 2023, Simone Ballarin wrote:
> The scheduled analyses are intended to maintain an overall vision
> of the MISRA complaince of the entire project. For this reason,
> the file exclusions in "out_of_scope.ecl" should not be applied.
>
> This patch amends ECLAIR settings to prevent
Hi Both,
> On Nov 22, 2023, at 04:41, Andrew Cooper wrote:
>
> On 21/11/2023 8:33 pm, Luca Fancellu wrote:
>> + CC henry
>>
>>> On 21 Nov 2023, at 20:15, Andrew Cooper wrote:
>>>
>>> -Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but
>>> this
>>> logic looks
On Tue, 21 Nov 2023, Roger Pau Monne wrote:
> Instead of using specific architecture image, switch to using multi-arch ones
> and specify the desired architecture using the --platform option.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
> ---
> I haven't touched the
On Tue, 21 Nov 2023, Roger Pau Monne wrote:
> Pass the desired architecture of the image in the FROM instruction if the
> image is possibly multi-platform.
>
> This allows using the x86 Dockerfiles on OS X on arm64 hardware.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
On 16/11/2023 1:48 pm, Jan Beulich wrote:
> Loading is_master from the state save record can lead to out-of-bounds
> accesses via at least the two container_of() uses by vpic_domain() and
> __vpic_lock(). Make sure the value is consistent with the instance being
> loaded.
>
> For ->int_output
On Tue, 21 Nov 2023, Roger Pau Monne wrote:
> The serial is already setup by the firmware, be consistent with the rest of
> the
> QEMU tests and don't specify a com1 setup.
>
> Note it's also bogus, as the extra ',' will make the intended DPS argument to
> be parsed as the io-base.
>
>
On Tue, 21 Nov 2023, Jan Beulich wrote:
> On 21.11.2023 01:04, Stefano Stabellini wrote:
> > On Mon, 20 Nov 2023, Jan Beulich wrote:
> >> On 20.11.2023 14:13, Federico Serafini wrote:
> >>> On 20/11/23 10:02, Jan Beulich wrote:
> On 17.11.2023 09:40, Federico Serafini wrote:
> > ---
On Tue, 21 Nov 2023, Stewart Hildebrand wrote:
> On 11/17/23 03:11, Oleksandr Tyshchenko wrote:
> >
> >
> > On 17.11.23 05:31, Stewart Hildebrand wrote:
> >
> > Hello Stewart
> >
> > [answering only for virtio-pci bits as for vPCI I am only familiar with
> > code responsible for trapping
On Tue, 20 Nov 2023, Volodymyr Babchuk wrote:
> Stefano Stabellini writes:
> > On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
> >> > On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
> >> >> Hi Julien,
> >> >>
> >> >> Julien Grall writes:
> >> >>
> >> >> > Hi Volodymyr,
> >> >> >
> >> >> > On
On Sat, Nov 18, 2023 at 11:33:55AM +, Andrew Cooper wrote:
> On 18/11/2023 3:04 am, Elliott Mitchell wrote:
> > On Fri, Nov 17, 2023 at 11:12:37AM +0100, Neowutran wrote:
> >> On 2023-11-07 11:11, Elliott Mitchell wrote:
> >>> On Mon, Oct 30, 2023 at 04:27:22PM +01
> On Mon, Oct 30, 2023
On 16/11/2023 1:47 pm, Jan Beulich wrote:
> In particular pit_latch_status() and speaker_ioport_read() perform
> calculations which assume in-bounds values. Several of the state save
> record fields can hold wider ranges, though. Refuse to load values which
> cannot result from normal operation,
flight 183808 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183808/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183779
test-armhf-armhf-libvirt-raw 15
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 brige resources
with xenstore. We made this for several reasons:
- We don't want to
was created by 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
Add option to preserve owner when creating an entry in Xen Store. This
may be needed in cases when Qemu is working as device model in a
domain that is Domain-0, e.g. in driver domain.
"owner" parameter for qemu_xen_xs_create() function can have special
value XS_PRESERVE_OWNER, which will make
From: Oleksandr Tyshchenko
Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to
inherit the owner of the directory.
Note that for other than Dom0 domain (non toolstack domain) the
"driver_domain" property should be set in domain config file for the
toolstack to create required
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
On 16/11/2023 1:47 pm, Jan Beulich wrote:
> Register NULL uniformly as a first step.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 16/11/2023 1:46 pm, Jan Beulich wrote:
> ..., at least as reasonably feasible without making a check hook
> mandatory (in particular strict vs relaxed/zero-extend length checking
> can't be done early this way).
>
> Note that only one of the two uses of hvm_load() is accompanied with
>
flight 183807 xen-unstable real [real]
flight 183815 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183807/
http://logs.test-lab.xenproject.org/osstest/logs/183815/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 16/11/2023 1:46 pm, Jan Beulich wrote:
> ... to accompany hvm_read_entry() when actual copying isn't desirable.
> This allows to remove open-coded stream accesses from hpet_load(),
> along with using the helper in hvm_load() itself.
>
> Since arch_hvm_load()'s declaration would need changing,
flight 183814 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183814/
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 20/11/2023 10:36 am, Juergen Gross wrote:
> On 01.11.23 17:08, Juergen Gross wrote:
>> In order to build caml-stubdom, it must be explicitly enabled via
>> "configure --enable-caml-stubdom". The build process is failing due to
>> stubdom/ocaml.patch failing to apply. Since the patched file has
On 21/11/2023 9:49 am, Juergen Gross wrote:
> This small patch series is doing some preparations for being able to
> use 9pfs in Xenstore-stubdom.
>
> Changes in V2:
> - added patches 2 and 5
>
> Changes in V3:
> - rename function to get own domid (patch 2)
>
> Juergen Gross (5):
> Mini-OS: make
On 21/11/2023 8:33 pm, Luca Fancellu wrote:
> + CC henry
>
>> On 21 Nov 2023, at 20:15, Andrew Cooper wrote:
>>
>> -Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but
>> this
>> logic looks incorrect. It was inherited from the x86 side, where the logic
>> was redundant and
+ CC henry
> On 21 Nov 2023, at 20:15, Andrew Cooper wrote:
>
> -Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but this
> logic looks incorrect. It was inherited from the x86 side, where the logic
> was redundant and has now been removed.
>
> In the ARM case it inserts
The codebase is now -Wwrite-strings clean. Activate the option to cause
string literals to have a const type, and prevent any violations of MISRA Rule
7.4 being reintroduced.
Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC:
-Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but this
logic looks incorrect. It was inherited from the x86 side, where the logic
was redundant and has now been removed.
In the ARM case it inserts the image name into "xen,xen-bootargs" and there is
no logic at all to
Some patches from v1 committed. This is the rest, and they're mostly
rewritten from scratch.
CI:
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1080695374
https://cirrus-ci.com/build/5494986230202368
Andrew Cooper (5):
x86/setup: Clean up cmdline handling in create_dom0()
Rework the logic in __start_xen() to not potentially pass NULL into
cmdline_cook(). This makes the logic easier to follow too, and the rest of
__start_xen() is safe when initialising cmdline to the empty string.
Update cmdline_cook() to take and return const pointers, and write a
description of
-Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but all
this work is useless; it's making a memory allocation just to prepend the
image name which cmdline_cook() intentionally strips back out.
Simply forgo the work and identify EFI_LOADER as one of the loaders which
doesn't
There's a confusing mix of variables; a static dom0_cmdline[], and a cmdline
pointer which points to image->string before being pointed at the static
buffer in order to be passed into construct_dom0(). cmdline being a mutable
pointer falls over -Wwrite-strings builds.
Delete the cmdline pointer,
Pipeline #1080516886 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 10081c2d (
https://gitlab.com/xen-project/xen/-/commit/10081c2dc571775b538bb00982606a39832ad7e3
)
Commit Message:
Juergen Gross, le mar. 21 nov. 2023 10:49:53 +0100, a ecrit:
> When copying a 9pfs response chunk from the ring buffer across the
> ring end, the local ring pointer and length field are not updated
> correctly. Fix that.
>
> Fixes: 0924fec1de58 ("Mini-OS: add 9pfs transport layer")
>
Juergen Gross, le mar. 21 nov. 2023 10:49:50 +0100, a ecrit:
> Get the own domid via creation of a temporary event channel. There is
> no "official" way to read the own domid in PV guests, so use the event
> channel interface to get it:
>
> - allocate an unbound event channel specifying
On 21/11/2023 6:03 pm, Andrew Cooper wrote:
> On 21/11/2023 8:40 am, Jan Beulich wrote:
>> On 20.11.2023 23:49, Andrew Cooper wrote:
>>> GCC complains:
>>>
>>> In file included from arch/arm/efi/boot.c:700:
>>> arch/arm/efi/efi-boot.h: In function 'efi_arch_handle_cmdline':
>>>
On 11/17/23 03:11, Oleksandr Tyshchenko wrote:
>
>
> On 17.11.23 05:31, Stewart Hildebrand wrote:
>
> Hello Stewart
>
> [answering only for virtio-pci bits as for vPCI I am only familiar with
> code responsible for trapping config space accesses]
>
> [snip]
>
>>>
>>>
>>> Let me start by
Hi,
On 21/11/2023 18:13, Michal Orzel wrote:
On 21/11/2023 17:30, Julien Grall wrote:
Hi Michal,
On 21/11/2023 09:45, Michal Orzel wrote:
Macros load_paddr and adr_l are equivalent when used before the MMU is
enabled, resulting in obtaining physical address of a symbol. The former
requires
Hi Michal,
On 21/11/2023 17:18, Michal Orzel wrote:
On 21/11/2023 18:04, Julien Grall wrote:
On 21/11/2023 17:00, Michal Orzel wrote:
Hi Julien,
Hi,
On 21/11/2023 17:09, Julien Grall wrote:
Hi Michal,
On 21/11/2023 09:45, Michal Orzel wrote:
At the moment, the 'hex' string is
Hi Julien,
On 21/11/2023 17:30, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/11/2023 09:45, Michal Orzel wrote:
>> Macros load_paddr and adr_l are equivalent when used before the MMU is
>> enabled, resulting in obtaining physical address of a symbol. The former
>> requires to know the
On 21/11/2023 8:40 am, Jan Beulich wrote:
> On 20.11.2023 23:49, Andrew Cooper wrote:
>> GCC complains:
>>
>> In file included from arch/arm/efi/boot.c:700:
>> arch/arm/efi/efi-boot.h: In function 'efi_arch_handle_cmdline':
>> arch/arm/efi/efi-boot.h:482:16: error: assignment discards
On Tue, Nov 21, 2023 at 06:22:37PM +0100, Jan Beulich wrote:
> On 21.11.2023 16:48, Roger Pau Monné wrote:
> > On Thu, Nov 16, 2023 at 02:30:41PM +0100, Jan Beulich wrote:
> >> The variable was introduced by 69b830e5ffb4 ("VMX: VMFUNC and #VE
> >> definitions and detection") without any use and -
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
Another patch I've found hidden away in my pile of unfinished branches...
This one collided with the bool_t cleanup.
---
xen/arch/x86/hvm/vlapic.c | 27 +--
1 file changed, 13
On 21/11/2023 5:27 pm, Jan Beulich wrote:
> On 21.11.2023 17:24, Roger Pau Monné wrote:
>> On Thu, Nov 16, 2023 at 02:31:05PM +0100, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>> @@ -2163,6 +2163,23 @@ int __init vmx_vmcs_init(void)
>>>
>>>
On Thu, Nov 16, 2023 at 02:32:07PM +0100, Jan Beulich wrote:
> While generally benign, doing so is still at best misleading.
>
> Signed-off-by: Jan Beulich
> ---
> Using set_in_cr4() seems favorable over updating mmu_cr4_features
> despite the resulting redundant CR4 update. But I certainly
On 21.11.2023 17:24, Roger Pau Monné wrote:
> On Thu, Nov 16, 2023 at 02:31:05PM +0100, Jan Beulich wrote:
>> ... or we fail to enable the functionality on the BSP for other reasons.
>> The only place where hardware announcing the feature is recorded is the
>> raw CPU policy/featureset.
>>
>>
On 21/11/2023 8:21 am, Jan Beulich wrote:
> On 20.11.2023 23:49, Andrew Cooper wrote:
>> Constify both cmdline variables in create_dom0() and __start_xen().
>> Initialise Xen's variable to the empty string to simplify the parsing logic.
>>
>> Update cmdline_cook() to take and return const
On 21.11.2023 16:48, Roger Pau Monné wrote:
> On Thu, Nov 16, 2023 at 02:30:41PM +0100, Jan Beulich wrote:
>> The variable was introduced by 69b830e5ffb4 ("VMX: VMFUNC and #VE
>> definitions and detection") without any use and - violating Misra C:2012
>> rule 8.4 - without a declaration. Since no
On 21/11/2023 18:04, Julien Grall wrote:
>
>
> On 21/11/2023 17:00, Michal Orzel wrote:
>> Hi Julien,
>
> Hi,
>
>> On 21/11/2023 17:09, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 21/11/2023 09:45, Michal Orzel wrote:
At the moment, the 'hex' string is placed right after the
On 21/11/2023 17:00, Michal Orzel wrote:
Hi Julien,
Hi,
On 21/11/2023 17:09, Julien Grall wrote:
Hi Michal,
On 21/11/2023 09:45, Michal Orzel wrote:
At the moment, the 'hex' string is placed right after the 'putn'
function in the .text section. This is because of the limited range
Hi Julien,
On 21/11/2023 17:16, Julien Grall wrote:
>
>
> On 21/11/2023 09:45, Michal Orzel wrote:
>> Macro print_reg is used to print a value of a register passed as an
>> argument. While today it is only used from within the common head.S,
>> in the future we might want to make use of it from
Hi Julien,
On 21/11/2023 17:09, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/11/2023 09:45, Michal Orzel wrote:
>> At the moment, the 'hex' string is placed right after the 'putn'
>> function in the .text section. This is because of the limited range
>> (+/- 1MB) of PC relative 'adr'
On 11/21/23 11:27, Stewart Hildebrand wrote:
> On 11/21/23 10:18, Roger Pau Monné wrote:
>> On Tue, Nov 21, 2023 at 10:03:01AM -0500, Stewart Hildebrand wrote:
>>> On 11/21/23 09:45, Roger Pau Monné wrote:
On Wed, Sep 13, 2023 at 10:35:46AM -0400, Stewart Hildebrand wrote:
> @@ -407,26
flight 183810 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183810/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 23dbb8a07d108a7b8589e31639b6302b70445b9f
baseline version:
ovmf
> On 21 Nov 2023, at 09:45, Michal Orzel wrote:
>
> Macros load_paddr and adr_l are equivalent when used before the MMU is
> enabled, resulting in obtaining physical address of a symbol. The former
> requires to know the physical offset (PA - VA) and can be used both before
> and after the MMU
On Tue, 2023-11-21 at 16:56 +0100, Jan Beulich wrote:
> On 17.11.2023 13:24, Oleksii Kurochko wrote:
> > --- a/xen/arch/ppc/include/asm/current.h
> > +++ b/xen/arch/ppc/include/asm/current.h
> > @@ -4,6 +4,8 @@
> >
> > #include
> >
> > +#include
> > +
> > #ifndef __ASSEMBLY__
> >
> >
Hi Michal,
On 21/11/2023 09:45, Michal Orzel wrote:
Macros load_paddr and adr_l are equivalent when used before the MMU is
enabled, resulting in obtaining physical address of a symbol. The former
requires to know the physical offset (PA - VA) and can be used both before
and after the MMU is
On Tue, Nov 21, 2023 at 04:26:04PM +, Alejandro Vallejo wrote:
> Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> registers are derivable from each other through a fixed formula.
>
> Xen uses that formula, but applies it to vCPU IDs (which are sequential)
> rather
On 11/21/23 10:18, Roger Pau Monné wrote:
> On Tue, Nov 21, 2023 at 10:03:01AM -0500, Stewart Hildebrand wrote:
>> On 11/21/23 09:45, Roger Pau Monné wrote:
>>> On Wed, Sep 13, 2023 at 10:35:46AM -0400, Stewart Hildebrand wrote:
@@ -407,26 +439,25 @@ uint32_t vpci_read(pci_sbdf_t sbdf,
Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
registers are derivable from each other through a fixed formula.
Xen uses that formula, but applies it to vCPU IDs (which are sequential)
rather than x2APIC_IDs (which are not, at the moment). As I understand it,
this is an
On Tue, 2023-11-21 at 16:43 +0100, Jan Beulich wrote:
> On 17.11.2023 13:24, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/device.h
> > @@ -0,0 +1,147 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_DEVICE_H__
> > +#define
On Thu, Nov 16, 2023 at 02:31:05PM +0100, Jan Beulich wrote:
> ... or we fail to enable the functionality on the BSP for other reasons.
> The only place where hardware announcing the feature is recorded is the
> raw CPU policy/featureset.
>
> Inspired by
>
On 2023-11-21 16:36, Jan Beulich wrote:
On 25.10.2023 15:22, Nicola Vetrini wrote:
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1034,10 +1034,10 @@ int guest_wrmsr_x2apic(struct vcpu *v,
uint32_t msr, uint64_t val)
case APIC_EOI:
case APIC_ESR:
if (
On 21/11/2023 09:45, Michal Orzel wrote:
Macro print_reg is used to print a value of a register passed as an
argument. While today it is only used from within the common head.S,
in the future we might want to make use of it from other files, just
like PRINT(). It also serves as a great aid
Hi Michal,
On 21/11/2023 09:45, Michal Orzel wrote:
At the moment, the 'hex' string is placed right after the 'putn'
function in the .text section. This is because of the limited range
(+/- 1MB) of PC relative 'adr' instruction 'putn' uses. Modify it to use
'adr_l' instead (range extended to
Instead of using specific architecture image, switch to using multi-arch ones
and specify the desired architecture using the --platform option.
Signed-off-by: Roger Pau Monné
---
I haven't touched the Yocto dockerfile because I'm not sure how it's used.
---
Switch tests using Stretch to Bookworm, as Stretch is EOL.
Note the packages are not removed from the Stretch dockerfile, because the
tests in stable branches will run using the old containers.
Signed-off-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
The Bookworm container needs to
Signed-off-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Changes since v1:
- Expand to all tests.
---
automation/scripts/qemu-alpine-x86_64.sh | 2 +-
automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +-
automation/scripts/qemu-smoke-dom0-arm64.sh | 2 +-
Otherwise it's impossible to build the images.
Signed-off-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
automation/build/debian/jessie-i386.dockerfile | 7 +++
automation/build/debian/jessie.dockerfile | 7 +++
automation/build/debian/stretch-i386.dockerfile | 7
Pass the desired architecture of the image in the FROM instruction if the
image is possibly multi-platform.
This allows using the x86 Dockerfiles on OS X on arm64 hardware.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
I haven't touched the Yocto dockerfile because I'm not
Hello,
Some assorted minor fixes and improvements, as a result of work I'm
doing to expand the tests.
I've done a full run with the updated containers, and found no issues:
https://gitlab.com/xen-project/people/royger/xen/-/pipelines/1080250168
Thanks, Roger.
Roger Pau Monne (7):
The serial is already setup by the firmware, be consistent with the rest of the
QEMU tests and don't specify a com1 setup.
Note it's also bogus, as the extra ',' will make the intended DPS argument to
be parsed as the io-base.
Signed-off-by: Roger Pau Monné
---
Changes in v2:
- New in this
The gitlab CI webpage seems to have issues displaying the \CR\CR\LF "\r\r\n"
sequence on the web interface used as line returns by the Linux kernel serial
output. This leads to the QEMU tests output looking like:
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial
> On 21 Nov 2023, at 09:45, Michal Orzel wrote:
>
> Macro print_reg is used to print a value of a register passed as an
> argument. While today it is only used from within the common head.S,
> in the future we might want to make use of it from other files, just
> like PRINT(). It also serves
On 17.11.2023 13:24, Oleksii Kurochko wrote:
> 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.
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
On 17.11.2023 13:24, Oleksii Kurochko wrote:
> is common through archs thereby it is moved
> to asm-generic.
>
> Arm and PPC were switched to asm generic verstion of hardirq.h.
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
On 17.11.2023 13:24, Oleksii Kurochko wrote:
> --- a/xen/arch/ppc/include/asm/current.h
> +++ b/xen/arch/ppc/include/asm/current.h
> @@ -4,6 +4,8 @@
>
> #include
>
> +#include
> +
> #ifndef __ASSEMBLY__
>
> struct vcpu;
> @@ -38,6 +40,10 @@ static inline struct cpu_info
> On 21 Nov 2023, at 09:45, Michal Orzel wrote:
>
> At the moment, the 'hex' string is placed right after the 'putn'
> function in the .text section. This is because of the limited range
> (+/- 1MB) of PC relative 'adr' instruction 'putn' uses. Modify it to use
> 'adr_l' instead (range
On Thu, Nov 16, 2023 at 02:30:41PM +0100, Jan Beulich wrote:
> The variable was introduced by 69b830e5ffb4 ("VMX: VMFUNC and #VE
> definitions and detection") without any use and - violating Misra C:2012
> rule 8.4 - without a declaration. Since no use has appeared, drop it.
>
> For vmx_vmfunc
On 17.11.2023 13:24, Oleksii Kurochko wrote:
> is common for Arm, PPC and RISC-V thereby it
> is moved to asm-generic.
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
with ...
> --- /dev/null
> +++ b/xen/include/asm-generic/random.h
> @@ -0,0 +1,20 @@
> +/*
On 17.11.2023 13:24, Oleksii Kurochko wrote:
> iocap.h is common for Arm, PPC and RISC-V architectures thereby
> it was moved to asm-generic.
>
> Also Arm and PPC were switched to asm-generic version of iocap.h.
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
On 17.11.2023 13:24, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/device.h
> @@ -0,0 +1,147 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_DEVICE_H__
> +#define __ASM_GENERIC_DEVICE_H__
> +
> +enum device_type
> +{
> +#ifdef
On 25.10.2023 15:22, Nicola Vetrini wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1034,10 +1034,10 @@ int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr,
> uint64_t val)
> case APIC_EOI:
> case APIC_ESR:
> if ( val )
> -{
> -
On Tue, Nov 21, 2023 at 10:03:01AM -0500, Stewart Hildebrand wrote:
> On 11/21/23 09:45, Roger Pau Monné wrote:
> > On Wed, Sep 13, 2023 at 10:35:46AM -0400, Stewart Hildebrand wrote:
> >> @@ -407,26 +439,25 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int
> >> reg, unsigned int size)
> >>
>
On Thu, Oct 12, 2023 at 10:09:18PM +, Volodymyr Babchuk wrote:
> 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
On 11/21/23 09:45, Roger Pau Monné wrote:
> On Wed, Sep 13, 2023 at 10:35:46AM -0400, Stewart Hildebrand wrote:
>> @@ -407,26 +439,25 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg,
>> unsigned int size)
>>
>> /*
>> * Perform a maybe partial write to a register.
>> - *
>> - * Note
On 2023-10-25 15:22, Nicola Vetrini wrote:
The clauses of a switch should be enclosed directly by a switch
statement to make the code more easily understandable and less
prone to errors.
Signed-off-by: Nicola Vetrini
---
This patch is mainly indended to probe how the community, especially
the
On Wed, Sep 13, 2023 at 10:35:46AM -0400, Stewart Hildebrand wrote:
> @@ -407,26 +439,25 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg,
> unsigned int size)
>
> /*
> * Perform a maybe partial write to a register.
> - *
> - * Note that this will only work for simple registers, if
1 - 100 of 146 matches
Mail list logo
