flight 187480 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187480/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187465
test-amd64-amd64-xl-qemut-win7-amd64
On 14.08.2024 09:44, Jan Beulich wrote:
> XSM is a generic framework, which in particular is also used by SILO.
> With this it can't really be experimental: Arm mandates SILO for having
> a security supported configuration.
>
> Signed-off-by: Jan Beulich
> ---
> v3: Add explanations. Another term
On 19.08.2024 17:10, Jan Beulich wrote:
> As was basically decided already a while ago, remove - in the simplest
> possible way - the archiving of both qemu-s and mini-os from tarball
> generation.
>
> With this the subtree-force-update-all prereq isn't needed anymore in
> the top level Makefile.
On 04/09/2024 7:54 am, Jan Beulich wrote:
> On 03.09.2024 13:53, Andrew Cooper wrote:
>> Most of Xen is build using -nostdinc and a fully specified include path.
>> However, the makefile line:
>>
>> $(head-bin-objs): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
>>
>> discards XEN_CFLAGS and replaces them
On Tue, Sep 03, 2024 at 04:36:37PM +0200, Jan Beulich wrote:
> On 03.09.2024 16:19, Roger Pau Monne wrote:
> > Current blkif implementations (both backends and frontends) have all slight
> > differences about how they handle the 'sector-size' xenstore node, and how
> > other fields are derived from
> On 3 Sep 2024, at 17:40, Andrew Cooper wrote:
>
> On 03/09/2024 12:44 pm, Andrii Sultanov wrote:
>> Dynamic libraries in OCaml require an additional compilation step on top
>> of the already specified steps for static libraries. Add an appropriate
>> template to Makefile.rules.
>>
>> Signed
On 04/09/2024 09:21, Roger Pau Monné wrote:
In the absence of that I'm afraid it is a little harder to
judge whether the proposal here is the best we can do at this point.
While I don't mind looking at what we can do to better handle 4K
sector disks, we need IMO to revert to the specification b
On Wed, Sep 04, 2024 at 09:39:17AM +0100, Paul Durrant wrote:
> On 04/09/2024 09:21, Roger Pau Monné wrote:
> > > In the absence of that I'm afraid it is a little harder to
> > > judge whether the proposal here is the best we can do at this point.
> >
> > While I don't mind looking at what we can
On Wed, Aug 14, 2024 at 09:44:11AM +0200, Jan Beulich wrote:
> XSM is a generic framework, which in particular is also used by SILO.
> With this it can't really be experimental: Arm mandates SILO for having
> a security supported configuration.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger P
On Tue, Sep 03, 2024 at 04:48:41PM +0200, Jan Beulich wrote:
> On 03.09.2024 15:02, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -785,6 +785,31 @@ static struct platform_timesource
> > __initdata_cf_clobber plt_xen_timer =
> > .resume = resume_xen_
On 04.09.2024 10:21, Roger Pau Monné wrote:
> On Tue, Sep 03, 2024 at 04:36:37PM +0200, Jan Beulich wrote:
>> On 03.09.2024 16:19, Roger Pau Monne wrote:
>>> Current blkif implementations (both backends and frontends) have all slight
>>> differences about how they handle the 'sector-size' xenstore
On 2024/9/4 01:16, Anthony PERARD wrote:
> On Tue, Sep 03, 2024 at 03:04:24PM +0800, Jiqian Chen wrote:
>> When dom0 is PVH, and passthrough a device to dumU, xl will
>> use the gsi number of device to do a pirq mapping, see
>> pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is
>> got from
On Wed, Sep 04, 2024 at 11:11:51AM +0200, Roger Pau Monné wrote:
> On Wed, Sep 04, 2024 at 09:39:17AM +0100, Paul Durrant wrote:
> > On 04/09/2024 09:21, Roger Pau Monné wrote:
> > > > In the absence of that I'm afraid it is a little harder to
> > > > judge whether the proposal here is the best we
On 04.09.2024 11:21, Roger Pau Monné wrote:
> On Wed, Aug 14, 2024 at 09:44:11AM +0200, Jan Beulich wrote:
>> XSM is a generic framework, which in particular is also used by SILO.
>> With this it can't really be experimental: Arm mandates SILO for having
>> a security supported configuration.
>>
>>
On Tue, Sep 03, 2024 at 05:02:21PM +0200, Jan Beulich wrote:
> On 03.09.2024 15:02, Roger Pau Monne wrote:
> > Move the logic that ensures the CMOS RTC data is read just after it's been
> > updated into the __get_cmos_time() function that does the register reads.
> > This
> > requires returning a
On 8/14/24 03:44, Jan Beulich wrote:
XSM is a generic framework, which in particular is also used by SILO.
With this it can't really be experimental: Arm mandates SILO for having
a security supported configuration.
Signed-off-by: Jan Beulich
Reviewed-by: Daniel P. Smith
On 19/08/2024 4:10 pm, Jan Beulich wrote:
> As was basically decided already a while ago, remove - in the simplest
> possible way - the archiving of both qemu-s and mini-os from tarball
> generation.
>
> With this the subtree-force-update-all prereq isn't needed anymore in
> the top level Makefile.
On Wed, Sep 04, 2024 at 11:31:08AM +0200, Jan Beulich wrote:
> On 04.09.2024 10:21, Roger Pau Monné wrote:
> > On Tue, Sep 03, 2024 at 04:36:37PM +0200, Jan Beulich wrote:
> >> On 03.09.2024 16:19, Roger Pau Monne wrote:
> >>> Current blkif implementations (both backends and frontends) have all
>
The complaint is:
In file included from ././include/xen/config.h:17,
from :
arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
./include/asm-generic/percpu.h:16:51: error: array subscript [0, 0] is outside
array bounds of ‘long unsigned int[1]’ [-Werror=array-bound
On Tue, 2024-09-03 at 15:19 +0100, Andrew Cooper wrote:
> SBI has an API for shutdown so wire it up. However, the spec does
> allow the
> call not to be implemented, so we have to cope with the call return
> returning.
>
> There is a reboot-capable SBI extention, but in the short term route
> rou
On 04/09/2024 11:15 am, Jan Beulich wrote:
> The complaint is:
>
> In file included from ././include/xen/config.h:17,
> from :
> arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
> ./include/asm-generic/percpu.h:16:51: error: array subscript [0, 0] is
> outside arr
On 04.09.2024 11:59, Andrew Cooper wrote:
> On 19/08/2024 4:10 pm, Jan Beulich wrote:
>> As was basically decided already a while ago, remove - in the simplest
>> possible way - the archiving of both qemu-s and mini-os from tarball
>> generation.
>>
>> With this the subtree-force-update-all prereq
On Tue, 2024-09-03 at 15:21 +0100, Andrew Cooper wrote:
> On 02/09/2024 6:01 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/include/asm/atomic.h
> > b/xen/arch/riscv/include/asm/atomic.h
> > index 31b91a79c8..3c6bd86406 100644
> > --- a/xen/arch/riscv/include/asm/atomic.h
> > +++ b/xen
On 04.09.2024 12:24, Andrew Cooper wrote:
> On 04/09/2024 11:15 am, Jan Beulich wrote:
>> The complaint is:
>>
>> In file included from ././include/xen/config.h:17,
>> from :
>> arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
>> ./include/asm-generic/percpu.h:16:5
On 03.09.2024 09:41, Sergiy Kibrik wrote:
> Make the Intel-specific Trusted Boot implementation dependant on general
> Intel CPU support.
>
> Signed-off-by: Sergiy Kibrik
Acked-by: Jan Beulich
On Wed, Sep 04, 2024 at 09:35:40AM +, Anthony PERARD wrote:
> On Wed, Sep 04, 2024 at 11:11:51AM +0200, Roger Pau Monné wrote:
> > On Wed, Sep 04, 2024 at 09:39:17AM +0100, Paul Durrant wrote:
> > > On 04/09/2024 09:21, Roger Pau Monné wrote:
> > > > > In the absence of that I'm afraid it is a
On 04/09/2024 11:27 am, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-09-03 at 15:21 +0100, Andrew Cooper wrote:
>> On 02/09/2024 6:01 pm, Oleksii Kurochko wrote:
>>> diff --git a/xen/arch/riscv/include/asm/atomic.h
>>> b/xen/arch/riscv/include/asm/atomic.h
>>> index 31b91a79c8..3c6bd86406 10064
On 04/09/2024 11:26 am, Jan Beulich wrote:
> On 04.09.2024 11:59, Andrew Cooper wrote:
>> On 19/08/2024 4:10 pm, Jan Beulich wrote:
>>> As was basically decided already a while ago, remove - in the simplest
>>> possible way - the archiving of both qemu-s and mini-os from tarball
>>> generation.
>>>
Hi All,
Gentle ping, I would appreciate some reviews here. Especially because in v2
the whole domain liefcylce with the fixed ASID works. So, I would love to
know if it's going in the right direction or not.
Thanks!
On 8/13/24 8:58 PM, Vaishali Thakkar wrote:
Motivation:
---
This is pa
On 04/09/2024 7:40 am, Jan Beulich wrote:
> On 30.08.2024 23:46, Daniel P. Smith wrote:
>> @@ -1447,7 +1447,7 @@ void asmlinkage __init noreturn __start_xen(unsigned
>> long mbi_p)
>> {
>> /* Don't overlap with modules. */
>> end = consider_modules(s, e, reloc_si
On 04/09/2024 7:49 am, Jan Beulich wrote:
> On 30.08.2024 23:46, Daniel P. Smith wrote:
>> From: Andrew Cooper
>>
>> Using an interface based on addresses directly, not modules.
>>
>> No functional change.
> Okay, a mechanical transformation. But what's the goal?
Its used by patch 12 which adds b
On Tue, Sep 03, 2024 at 05:16:44PM +0200, Jan Beulich wrote:
> On 03.09.2024 15:02, Roger Pau Monne wrote:
> > The current logic to probe for the CMOS RTC is open-coded in
> > get_cmos_time(),
> > move it to a separate function that both serves the purpose of testing for
> > the
> > CMOS RTC exis
On Tue, Sep 03, 2024 at 05:32:27PM +0200, Jan Beulich wrote:
> On 03.09.2024 15:03, Roger Pau Monne wrote:
> > Adding such probing allows to clearly separate init vs runtime code, and to
> > place the probing logic into the init section for the CMOS case. Note both
> > the Xen shared_info page wal
On 04.09.2024 12:58, Roger Pau Monné wrote:
> On Tue, Sep 03, 2024 at 05:32:27PM +0200, Jan Beulich wrote:
>> On 03.09.2024 15:03, Roger Pau Monne wrote:
>>> @@ -1329,28 +1338,13 @@ static bool cmos_probe(struct rtc_time *rtc_p, bool
>>> cmos_rtc_probe)
>>> return false;
>>> }
>>>
>>> -sta
On 28/08/2024 16:01, Julien Grall wrote:
Hi,
Hi Julien,
I need some clarifications.
On 23/08/2024 17:31, Ayan Kumar Halder wrote:
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot-time page table in MMU system, we need a boot-time MPU
protection region configuration in M
1: x86emul: support LKGS
2: x86emul: support CMPccXADD
3: x86emul+VMX: support {RD,WR}MSRLIST
4: x86: introduce x86_seg_sys
5: x86emul: support USER_MSR instructions
6: x86/cpu-policy: re-arrange no-VMX logic
7: VMX: support USER_MSR
Jan
Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its and FRED's bit at this occasion, thus allowing to
also express the dependency right away.
While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests, install write
Unconditionally wire this through the ->rmw() hook. Since x86_emul_rmw()
now wants to construct and invoke a stub, make stub_exn available to it
via a new field in the emulator state structure.
Signed-off-by: Jan Beulich
---
v5: Re-base.
v3: Add dependency on LM. Re-base.
v2: Use X86_EXC_*. Move
These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by
To represent the USER-MSR bitmap access, a new segment type needs
introducing, behaving like x86_seg_none in terms of address treatment,
but behaving like a system segment for page walk purposes (implicit
supervisor-mode access).
Signed-off-by: Jan Beulich
---
This feels a little fragile: Of cour
Move the PKS check into an "else" for the corresponding "if()", such
that further adjustments (like for USER_MSR) can easily be put there as
well.
Signed-off-by: Jan Beulich
---
v5: Re-base.
v4: New.
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -741,19 +741,20 @@ static voi
While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).
Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 2
On Wed, Sep 04, 2024 at 01:49:36PM +0200, Jan Beulich wrote:
> On 04.09.2024 12:58, Roger Pau Monné wrote:
> > I had it that way originally, but then it seemed the extra
> > indentation made it less readable. Will see how can I adjust it, my
> > preference would be for:
> >
> > panic("No usab
When booting guests, compressed first executables (the kernel itself for
direct-boot, or firmware binaries) need decompressing in order to inspect the
ELF notes or other relevant headers.
However for unclear reasons, libxenguest will also gunzip() all modules which
happen to be compressed (typical
Hook up the new VM exit codes and handle guest accesses, context switch,
and save/restore. At least for now don't allow the guest direct access
to the control MSR; this may need changing if guests were to frequently
access it (e.g. on their own context switch path).
While there also correct a one-
On 04.09.2024 14:31, Andrew Cooper wrote:
> When booting guests, compressed first executables (the kernel itself for
> direct-boot, or firmware binaries) need decompressing in order to inspect the
> ELF notes or other relevant headers.
>
> However for unclear reasons, libxenguest will also gunzip(
On 04.09.2024 14:30, Roger Pau Monné wrote:
> On Wed, Sep 04, 2024 at 01:49:36PM +0200, Jan Beulich wrote:
>> On 04.09.2024 12:58, Roger Pau Monné wrote:
>>> I had it that way originally, but then it seemed the extra
>>> indentation made it less readable. Will see how can I adjust it, my
>>> prefe
SMR masking support allows deriving a mask either using a 2-cell iommu
specifier (per master) or stream-match-mask SMMU dt property (global
config). Even though the mask is stored in the fwid when adding a
device (in arm_smmu_dt_xlate_generic()), we still set it to 0 when
allocating SMEs (in arm_sm
On Tue, Sep 03, 2024 at 05:48:09PM +0200, Jan Beulich wrote:
> On 03.09.2024 15:03, Roger Pau Monne wrote:
> > Probing for the CMOS RTC registers consist in reading IO ports, and we
> > expect
> > those reads to have no side effects even when the CMOS RTC is not present.
>
> But what do we gain f
On 04/09/2024 1:43 pm, Michal Orzel wrote:
> diff --git a/xen/drivers/passthrough/arm/smmu.c
> b/xen/drivers/passthrough/arm/smmu.c
> index f2cee82f553a..4c8a446754cc 100644
> --- a/xen/drivers/passthrough/arm/smmu.c
> +++ b/xen/drivers/passthrough/arm/smmu.c
> @@ -1619,19 +1619,21 @@ static int a
flight 187481 qemu-mainline real [real]
flight 187494 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187481/
http://logs.test-lab.xenproject.org/osstest/logs/187494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 187491 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187491/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 99d60cbd3990fe8f5b86eaab40876fbbf9d99084
baseline version:
ovmf 1240a722f8466930cced7
flight 187490 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187490/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 186806
test-amd64-amd64-qemuu-nested-amd 20 debi
On 04.09.2024 14:45, Roger Pau Monné wrote:
> On Tue, Sep 03, 2024 at 05:48:09PM +0200, Jan Beulich wrote:
>> On 03.09.2024 15:03, Roger Pau Monne wrote:
>>> Probing for the CMOS RTC registers consist in reading IO ports, and we
>>> expect
>>> those reads to have no side effects even when the CMOS
The main fix is patch 3, with the earlier patches setting the stage
and the latter ones simplifying other things at least a little in
exchange.
1: reduce recursion in linear_{read,write}()
2: allocate emulation cache entries dynamically
3: correct read/write split at page boundaries
4: slightly im
On Tue, Sep 03, 2024 at 04:19:23PM +0200, Roger Pau Monne wrote:
> Current blkif implementations (both backends and frontends) have all slight
> differences about how they handle the 'sector-size' xenstore node, and how
> other fields are derived from this value or hardcoded to be expressed in unit
Let's make explicit what the compiler may or may not do on our behalf:
The 2nd of the recursive invocations each can fall through rather than
re-invoking the function. This will save us from adding yet another
parameter (or more) to the function, just for the recursive invocations.
Signed-off-by:
Both caches may need higher capacity, and the upper bound will need to
be determined dynamically based on CPUID policy (for AMX at least).
While touching the check in hvmemul_phys_mmio_access() anyway, also
tighten it: To avoid overrunning the internal buffer we need to take the
offset into the bu
The MMIO cache is intended to have one entry used per independent memory
access that an insn does. This, in particular, is supposed to be
ignoring any page boundary crossing. Therefore when looking up a cache
entry, the access'es starting (linear) address is relevant, not the one
possibly advanced
Using hvmemul_linear_mmio_write() directly (as fallback when mapping the
memory operand isn't possible) won't work properly when the access
crosses a RAM/MMIO boundary. Use linear_write() instead, which splits at
such boundaries as necessary.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emu
With all paths into hvmemul_linear_mmio_access() coming through
linear_{read,write}(), there's no need anymore to split accesses at
page boundaries there. Leave an assertion, though.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1084,7 +1084,7 @
flight 187492 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187492/
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 04/09/2024 1:28 pm, Jan Beulich wrote:
> ---
> Instead of ->read_segment() we could of course also use ->read_msr() to
> fetch the original GS base. I don't think I can see a clear advantage of
> either approach; the way it's done it matches how we handle SWAPGS.
It turns out this is littered w
This RFC series attempt to:
- use more C code, that is replace some assembly code with C;
- avoid some code duplication between C and assembly;
- prevent some issues having relocations in C code.
The idea is extending the current C to binary code conversion
done for 32 bit C code called from head.
---
xen/arch/x86/boot/Makefile | 6 +++---
xen/arch/x86/boot/build32.lds.S| 4
xen/arch/x86/boot/head.S | 24 ++
xen/arch/x86/boot/reloc-trampoline.c | 28 ++
xen/arch/x86/boot/reloc-trampoline64.c | 1 +
xen/a
Pretty hacky, headers are not that compatible 32/64 bits
---
xen/arch/x86/boot/Makefile| 6 +-
xen/arch/x86/boot/build32.lds.S | 8 +++
xen/arch/x86/boot/head.S | 43 +---
xen/arch/x86/boot/setup-pages.c | 105 ++
xen/arch/x86/boot/setu
The current method to include 32 bit C boot code is:
- compile each function we want to use into a separate object file;
- each function is compiled with -fpic option;
- convert these object files to binary files. This operation removes GOP
which we don't want in the executable;
- a small assembl
All code and dat from this file will go into a text section
which we want to not be writeable.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/reloc.c | 62 ---
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/xen/arch/x86/boot/reloc.c b/xe
Reduce assembly code, make boot page mappings more similar between
multiple paths (direct EFI and not).
---
xen/arch/x86/boot/build32.lds.S | 2 ++
xen/arch/x86/boot/head.S| 10 --
xen/arch/x86/boot/setup-pages.c | 25 ++---
xen/arch/x86/boot/x86_64.S |
On 04/09/2024 1:28 pm, Jan Beulich wrote:
> Unconditionally wire this through the ->rmw() hook. Since x86_emul_rmw()
> now wants to construct and invoke a stub, make stub_exn available to it
> via a new field in the emulator state structure.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Adding such probing allows to clearly separate init vs runtime code, and to
place the probing logic into the init section for the CMOS case. Note both
the Xen shared_info page wallclock, and the EFI wallclock don't really have any
probing-specific logic. The shared_info wallclock will always be t
Allow setting the used wallclock from the command line. When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).
The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported bu
The EFI_GET_TIME implementation is well known to be broken for many firmware
implementations, for Xen the result on such implementations are:
[ Xen-4.19-unstable x86_64 debug=y Tainted: C]
CPU:0
RIP:e008:[<62ccfa70>] 62ccfa70
[...]
Xen call trace:
[<
Move the current code in get_wallclock_time() to fetch the Xen wallclock
information from the shared page when running as a guest into a separate
helper.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Place ifdef blocks inside the function.
Changes since
Hello,
This series started as an attempt to change the default wallclock
preference from EFI_GET_TIME to CMOS RTC, but has grown quite a lot.
First 3 patches should be non-functional changes, mostly chopping the
current logic into smaller functions so that in patch 4 the probing vs
runtime wallclo
Move the logic that ensures the CMOS RTC data is read just after it's been
updated into the __get_cmos_time() function that does the register reads. This
requires returning a boolean from __get_cmos_time() to signal whether the read
has been successfully performed after an update.
Note that while
The current logic to probe for the CMOS RTC is open-coded in get_cmos_time(),
move it to a separate function that both serves the purpose of testing for the
CMOS RTC existence and returning its value.
The goal is to be able to split the probing and the reading logic into separate
helpers, and putt
On Wed, Jun 19, 2024 at 08:10:57PM +0100, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information.
>
> There's a new SRSO_U/S_NO enumeration saying that SRSO attacks can't cross the
> user/supervisor boundary. i.e. Xen don't need to use IBPB-on-entry for PV.
>
> T
From: "Edgar E. Iglesias"
Break out a common Xen PVH machine in preparation for
adding a x86 Xen PVH machine.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/arm/trace-events | 5 -
hw/arm/xen_arm.c| 198 +++
hw/xen/mes
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/arm/xen_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
index fda65d0d8d..16b3f00992 100644
--- a/hw/arm/xen_arm.c
+++ b/hw/arm/xen_ar
From: "Edgar E. Iglesias"
We've been creating the virtio-mmio devices in forwards order
but since the qbus lists prepend (rather than append) entries,
the virtio busses end up with decreasing base address order.
Xen enables virtio-mmio nodes in forwards order so there's been
a missmatch. So far,
From: "Edgar E. Iglesias"
Update file header to use SPDX and remove stray empty
comment line.
No functional changes.
Signed-off-by: Edgar E. Iglesias
Acked-by: Stefano Stabellini
---
hw/arm/xen_arm.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/hw/a
From: "Edgar E. Iglesias"
Add a Xen PVH x86 machine based on the abstract PVH Machine.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/i386/xen/meson.build | 1 +
hw/i386/xen/xen-pvh.c | 121
2 files changed, 122 insertions(
From: "Edgar E. Iglesias"
Add support for optionally creating a PCIe/GPEX controller.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/xen/xen-pvh-common.c | 76 +
include/hw/xen/xen-pvh-common.h | 29 +
2 files change
From: "Edgar E. Iglesias"
The following changes since commit e638d685ec2a0700fb9529cbd1b2823ac4120c53:
Open 9.2 development tree (2024-09-03 09:18:43 -0700)
are available in the Git repository at:
https://gitlab.com/edgar.iglesias/qemu.git
tags/edgar/xen-queue-2024-09-04.for-upstream
for
From: "Edgar E. Iglesias"
Rename xen_arm.c -> xen-pvh.c to better express that this
is a PVH machine and to align with x86 HVM and future PVH
machine filenames:
hw/i386/xen/xen-hvm.c
hw/i386/xen/xen-pvh.c (in preparation)
No functional changes.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Ste
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
Acked-by: Stefano Stabellini
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3584d6a6c6..c2fb0c2f42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -559,6 +559,7 @@ F: include/hw/xen/
From: "Edgar E. Iglesias"
Add SMP support for Xen PVH ARM guests.
Create ms->smp.max_cpus ioreq servers to handle hotplug.
Note that ms->smp.max_cpus will be passed to us by the
user (Xen tools) set to the guests maxvcpus.
The value in mc->max_cpus is an absolute maximum for the
-smp option and
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/arm/meson.build | 5 -
hw/arm/xen-stubs.c | 32
hw/arm/xen_arm.c | 20
3 files changed, 36 insertions(+), 21 deletions(-)
create mode
From: "Edgar E. Iglesias"
Tweak machine description to better express that this is
a Xen PVH machine for ARM.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/arm/xen_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/xen_arm.c b/hw/arm/xen
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
MAINTAINERS | 1 +
docs/system/i386/xenpvh.rst | 49 +
docs/system/target-i386.rst | 1 +
3 files changed, 51 insertions(+)
create mode 100644 d
On 04/09/2024 1:29 pm, Jan Beulich wrote:
> To represent the USER-MSR bitmap access, a new segment type needs
> introducing, behaving like x86_seg_none in terms of address treatment,
> but behaving like a system segment for page walk purposes (implicit
> supervisor-mode access).
>
> Signed-off-by:
Hi Ayan,
Apologies but I can’t do a full review yet,
>>> +
>>> +/* MPU normal memory attributes. */
>>> +#define PRBAR_NORMAL_MEM0x30/* SH=11 AP=00 XN=00 */
>>> +#define PRLAR_NORMAL_MEM0x0f/* NS=0 ATTR=111 EN=1 */
>>> +
>>> +.macro write_pr, sel, prbar, prlar
>>> +ms
On 04/09/2024 19:14, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
Apologies but I can’t do a full review yet,
No worries. :)
+
+/* MPU normal memory attributes. */
+#define PRBAR_NORMAL_MEM0x30/* SH=11 AP=00 XN=00 */
+#define PRLAR_NORMAL_MEM0x0f/* NS=0 ATTR=111 EN=1 *
flight 187488 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187488/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-freebsd11-amd64 17 guest-localmigrate fail REGR. vs.
187476
Tests which did not su
flight 187489 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187489/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187414
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 02/09/2024 9:06 am, Jan Beulich wrote:
> On 30.08.2024 22:03, Andrew Cooper wrote:
>> On 29/08/2024 3:36 pm, Jan Beulich wrote:
>>> On 29.08.2024 00:03, Andrew Cooper wrote:
It has existed in x86 CPUs since 2008, so we're only 16 years late adding
support. With all the other scafoldin
On 29/08/2024 3:36 pm, Jan Beulich wrote:
> On 29.08.2024 00:03, Andrew Cooper wrote:
>> +asm (
>> +".type arch_generic_hweightl, STT_FUNC\n\t"
>> +".globl arch_generic_hweightl\n\t"
>> +".hidden arch_generic_hweightl\n\t"
>> +".balign " STR(CONFIG_FUNCTION_ALIGNMENT) ", 0x90\n\t"
>
Recent additions have undone prior tidying at the top of the file.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen/in
... and drop generic_hweight32().
As noted previously, the only two users of hweight32() are in __init paths.
The int-optimised form of generic_hweight() is only two instructions shorter
than the long-optimised form, and even then only on architectures which lack
fast multiplication, so there's n
1 - 100 of 110 matches
Mail list logo
