On 07.03.2024 22:40, Vaishali Thakkar wrote:
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct
> cpu_user_regs *regs)
> if ( nestedhvm_paging_mode_hap(v) )
> {
> /*
On 07.03.2024 21:54, Oleksii wrote:
> On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote:
>> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
>>> For plain writes it should at least be "=Qo" then, yes.
>> Constraints Q is a machine specific constraint, and I am not sure
>> that
>> it makes
flight 184931 linux-linus real [real]
flight 184941 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184931/
http://logs.test-lab.xenproject.org/osstest/logs/184941/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 07.03.2024 21:49, Oleksii wrote:
> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
>> For plain writes it should at least be "=Qo" then, yes.
> Constraints Q is a machine specific constraint, and I am not sure that
> it makes sense to use "=o" only and probably it is a reason why it is
>
On 07.03.2024 18:33, Jason Andryuk wrote:
> On 2024-03-07 05:20, Roger Pau Monné wrote:
>> On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote:
>>> On 07.03.2024 11:00, Roger Pau Monné wrote:
On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
> Xen tries to load a PVH
On 3/8/24 00:34, Andrew Cooper wrote:
On 07/03/2024 9:40 pm, Vaishali Thakkar wrote:
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 24358c6eea..f54b426fb3 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -53,6 +53,8 @@
On 3/8/24 00:22, Andrew Cooper wrote:
On 07/03/2024 9:40 pm, Vaishali Thakkar wrote:
The suffix is redundant for np/sev/sev-es bits. Drop it
to avoid adding extra code volume.
Suggested-by: Andrew Cooper
Signed-off-by: Vaishali Thakkar i
Typo on the end of your email address?
Oops, thanks
Hi everyone,
On 2/26/2024 6:43 PM, Michal Orzel wrote:
xen/arch/arm/smpboot.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
+/* PE not implemented using a multithreading type approach. */
+if ( system_cpuinfo.mpidr.mt == 0 )
Do we need this check? It mt was true,
For 1:1 direct-mapped dom0less DomUs, the magic pages should not clash
with any RAM region. To find a proper region for guest magic pages,
we can reuse the logic of finding domain extended regions.
Extract the logic of finding domain extended regions to a helper
function named
An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```
This is because populate_physmap() automatically assumes gfn == mfn
for direct mapped domains.
Previous commits enable the toolstack to get the domain memory map,
therefore instead of hardcoding the guest magic pages region, use
the XEN_DOMCTL_get_mem_map domctl to get the start address of the
guest magic pages region. Add the (XEN)MEMF_force_heap_alloc memory
flags to force
There are some use cases where the toolstack needs to know the guest
memory map. For example, the toolstack helper application
"init-dom0less" needs to know the guest magic page regions for 1:1
direct-mapped dom0less DomUs to allocate magic pages.
To address such needs, add XEN_DOMCTL_get_mem_map
Currently direct mapped domain is only supported by the Arm
architecture at the domain creation time by setting the CDF_directmap
flag. There is not a need for every non-Arm architecture, i.e. x86,
RISC-V and PPC, to define a stub is_domain_direct_mapped() in arch
header.
Move
Currently on Arm there are 4 functions to allocate memory as domain
RAM at boot time for different types of domains:
(1) allocate_memory(): To allocate memory for Dom0less DomUs that
do not use static memory.
(2) allocate_static_memory(): To allocate memory for Dom0less DomUs
that use
On 07/03/2024 9:40 pm, Vaishali Thakkar wrote:
> diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
> index 24358c6eea..f54b426fb3 100644
> --- a/xen/arch/x86/hvm/svm/svmdebug.c
> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
> @@ -53,6 +53,8 @@ void svm_vmcb_dump(const char
On 07/03/2024 9:40 pm, Vaishali Thakkar wrote:
> The suffix is redundant for np/sev/sev-es bits. Drop it
> to avoid adding extra code volume.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Vaishali Thakkar i
Typo on the end of your email address?
> diff --git
On Thu, 29 Feb 2024, Roger Pau Monne wrote:
> The generated code between the debug and release builds can be quite
> different, as a note 2ce562b2a413 only manifested in non-debug builds due to
> the usage of -O2.
>
> Duplicate the clang based test in order to test with both debug and non-debug
>
Hi,
In this patchset, first patch removes the unnecessary suffix
from a bunch of vmcb bits and the second patch is about
printing the status of sev and sev-es bits while dumping VMCB.
Vaishali Thakkar (2):
x86/svm: Drop the _enabled suffix from vmcb bits
x86/svmdebug: Print sev and sev_es
While sev and sev_es bits are not yet enabled in xen,
including their status in the VMCB dump could be
informational.Therefore, print it via svmdebug.
Signed-off-by: Vaishali Thakkar
---
JFYI, we'll send the follow-up patches with the enablement
of sev and ASP driver.
---
The suffix is redundant for np/sev/sev-es bits. Drop it
to avoid adding extra code volume.
Suggested-by: Andrew Cooper
Signed-off-by: Vaishali Thakkar i
---
xen/arch/x86/hvm/svm/nestedsvm.c| 14 +++---
xen/arch/x86/hvm/svm/svm.c | 2 +-
xen/arch/x86/hvm/svm/vmcb.c
On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote:
> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
> > For plain writes it should at least be "=Qo" then, yes.
> Constraints Q is a machine specific constraint, and I am not sure
> that
> it makes sense to use "=o" only and probably it is a
On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
> For plain writes it should at least be "=Qo" then, yes.
Constraints Q is a machine specific constraint, and I am not sure that
it makes sense to use "=o" only and probably it is a reason why it is
enough only "r". Does it make sense?
> To
On Thu, 7 Mar 2024, Oleksii wrote:
> Hello Doug and Stefano,
>
> While Michal has reviewed this patch, I understand that I still need
> your Acked-by.
>
> Could you please take a moment to review the patch?
>
> Thanks in advance.
Acked-by: Stefano Stabellini
> ~ Oleksii
>
> On Fri,
flight 184927 xen-unstable real [real]
flight 184939 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184927/
http://logs.test-lab.xenproject.org/osstest/logs/184939/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
flight 184932 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184932/
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
Hi Oleksii,
On 2/16/24 6:39 AM, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Shawn Anastasio
Thanks,
Shawn
Hi Oleksii,
On 2/16/24 6:39 AM, Oleksii Kurochko wrote:
> 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
>
On 2024-03-07 05:20, Roger Pau Monné wrote:
On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote:
On 07.03.2024 11:00, Roger Pau Monné wrote:
On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the
Hi Oleksii,
On 2/16/24 6:39 AM, Oleksii Kurochko wrote:
> 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
On 07.03.2024 17:21, Oleksii wrote:
> On Thu, 2024-03-07 at 16:32 +0100, Jan Beulich wrote:
>> On 07.03.2024 14:44, Oleksii wrote:
>>> On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote:
On 07.03.2024 14:01, Oleksii wrote:
> On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote:
>>>
Hello Doug and Stefano,
While Michal has reviewed this patch, I understand that I still need
your Acked-by.
Could you please take a moment to review the patch?
Thanks in advance.
~ Oleksii
On Fri, 2024-02-16 at 13:39 +0100, Oleksii Kurochko wrote:
> This patch introduces the anchor
On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote:
> On 22.12.2023 10:39, Oleksii wrote:
> > On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote:
> > > On 08.08.2023 12:18, Andrew Cooper wrote:
> > > > On 08/08/2023 10:46 am, Jan Beulich wrote:
> > > > > There's no need for every arch to
On 2024-03-07 04:30, Roger Pau Monné wrote:
On Wed, Mar 06, 2024 at 01:50:32PM -0500, Jason Andryuk wrote:
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there
On Thu, 2024-03-07 at 16:32 +0100, Jan Beulich wrote:
> On 07.03.2024 14:44, Oleksii wrote:
> > On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote:
> > > On 07.03.2024 14:01, Oleksii wrote:
> > > > On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote:
> > > > > > +/* Generic IO read/write.
On 2024-03-06 21:09, Stefano Stabellini wrote:
On Wed, 6 Mar 2024, Jason Andryuk wrote:
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares
On 07.03.2024 14:30, Oleksii wrote:
> On Wed, 2024-03-06 at 16:31 +0100, Jan Beulich wrote:
>> On 26.02.2024 18:38, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/atomic.h
>>> @@ -0,0 +1,296 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Taken
On 07.03.2024 14:44, Oleksii wrote:
> On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote:
>> On 07.03.2024 14:01, Oleksii wrote:
>>> On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote:
> +/* Generic IO read/write. These perform native-endian
> accesses.
> */
> +static inline
On 2024-03-07 03:26, Jan Beulich wrote:
On 07.03.2024 03:09, Stefano Stabellini wrote:
On Wed, 6 Mar 2024, Jason Andryuk wrote:
Expand bzimage_parse() to return kernel_alignment from the setup_header.
This will be needed if loading a PVH kernel at a physical offset to
compensate for a reserved
On 07.03.24 14:56, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err,
On 07.03.24 14:56, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err,
On Thu, Mar 07, 2024 at 09:56:16PM +0800, Henry Wang wrote:
> Below error can be seen when doing Yocto build of the toolstack:
>
> | io.c: In function 'p9_error':
> | io.c:684:5: error: ignoring return value of 'strerror_r' declared
> with attribute 'warn_unused_result' [-Werror=unused-result]
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err, ring->buffer, ring->ring_size);
|
On 2024-03-07 08:42, Jan Beulich wrote:
On 07.03.2024 02:39, Stefano Stabellini wrote:
On Tue, 5 Mar 2024, Jan Beulich wrote:
On 05.03.2024 03:03, Stefano Stabellini wrote:
On Mon, 4 Mar 2024, Jan Beulich wrote:
On 02.03.2024 02:37, Stefano Stabellini wrote:
On Fri, 1 Mar 2024, Jan Beulich
On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote:
> On 07.03.2024 14:01, Oleksii wrote:
> > On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote:
> > > > +/* Generic IO read/write. These perform native-endian
> > > > accesses.
> > > > */
> > > > +static inline void __raw_writeb(uint8_t val,
On Wed, 2024-03-06 at 16:31 +0100, Jan Beulich wrote:
> On 26.02.2024 18:38, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/atomic.h
> > @@ -0,0 +1,296 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Taken and modified from Linux.
> > + *
> > + *
On 07.03.2024 14:01, Oleksii wrote:
> On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote:
>>> +/* Generic IO read/write. These perform native-endian accesses.
>>> */
>>> +static inline void __raw_writeb(uint8_t val, volatile void __iomem
>>> *addr)
>>> +{
>>> + asm volatile ( "sb %0, 0(%1)"
On 07/03/2024 1:03 pm, Ross Lagerwall wrote:
> On Thu, Mar 7, 2024 at 12:16 PM Andrew Cooper
> wrote:
>> On 07/03/2024 11:58 am, Jan Beulich wrote:
>>> On 07.03.2024 12:31, Andrew Cooper wrote:
The thing called virtual_region already describes 6 ranges, and I'm
adding a 7th.
>>> Hmm,
On Tue, Mar 5, 2024 at 12:11 PM Andrew Cooper wrote:
>
> ... to text_{start,end}. We're about to introduce another start/end pair.
>
> As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more consice
> PAGE_ALIGN() ahead of duplicating the example.
>
> No functional change.
>
>
On Tue, Mar 5, 2024 at 1:02 PM Andrew Cooper wrote:
>
> On 05/03/2024 12:11 pm, Andrew Cooper wrote:
> > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
> > index d2efe9e11492..f45812483b8e 100644
> > --- a/xen/common/virtual_region.c
> > +++ b/xen/common/virtual_region.c
>
On Thu, Mar 7, 2024 at 12:16 PM Andrew Cooper wrote:
>
> On 07/03/2024 11:58 am, Jan Beulich wrote:
> > On 07.03.2024 12:31, Andrew Cooper wrote:
> >>
> >> The thing called virtual_region already describes 6 ranges, and I'm
> >> adding a 7th.
> > Hmm, yes, in a way you're right.
> >
> >> It has
On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote:
> > +/* Generic IO read/write. These perform native-endian accesses.
> > */
> > +static inline void __raw_writeb(uint8_t val, volatile void __iomem
> > *addr)
> > +{
> > + asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r" (addr) );
> > +}
>
On 3/7/2024 8:19 PM, Henry Wang wrote:
len = min(strlen(str), ring->ring_size - 1);
This actually will fire below errors on my build env, hence I
separated them with a different variable.
tools/include/xen-tools/common-macros.h:38:21: error: comparison of
distinct pointer types
When user enables HVC_DCC config option in Linux, it invokes access to debug
transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
injects an undefined exception to the guest and Linux crashes.
To prevent this crash, introduce a partial emulation of DBGDTR[TR]XINT (these
There can be situations when the registers cannot be emulated to their full
functionality. This can be due to the complexity involved. In such cases, one
can emulate those registers as RAZ/WI for example. We call them as partial
emulation.
Some registers are non-optional and as such there is
From: Michal Orzel
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an undefined
exception to the guest and Linux crashes.
To prevent
Hi,
Refer
https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/
for the previous discussion on this issue.
Also, the linux earlycon hvc driver has been fixed.
See
On Thu, 2024-03-07 at 12:11 +0100, Jan Beulich wrote:
> On 07.03.2024 12:01, Oleksii wrote:
> > On Thu, 2024-03-07 at 11:46 +0100, Jan Beulich wrote:
> > > On 07.03.2024 11:35, Oleksii wrote:
> > > > On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote:
> > > > > On 26.02.2024 18:38, Oleksii
Hi Juergen,
On 3/7/2024 7:24 PM, Juergen Gross wrote:
On 07.03.24 11:38, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute
Hi Juergen,
On 3/7/2024 6:51 PM, Juergen Gross wrote:
On 07.03.24 11:38, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute
Hi Jan,
On 3/7/2024 7:04 PM, Jan Beulich wrote:
On 07.03.2024 11:38, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result'
On 07/03/2024 11:58 am, Jan Beulich wrote:
> On 07.03.2024 12:31, Andrew Cooper wrote:
>>
>> The thing called virtual_region already describes 6 ranges, and I'm
>> adding a 7th.
> Hmm, yes, in a way you're right.
>
>> It has been a module-ish description right from the very outset. I
>> don't
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
xen_arch_set_memory() is not arch-specific anymore. Being
called once, inline it in xen_set_memory().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/xen-hvm-common.h | 3 -
hw/xen/xen-hvm-common.c | 104
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
hw/i386/xen/xen-hvm-common.c content is target agnostic,
and should be common to all targets. Merge both files.
Remove the now unnecessary xen_register_framebuffer() stub.
ARM targets now inherit the common xen_memory_listener.
On 07.03.24 11:38, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err,
On 07.03.24 11:38, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err,
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
Extract non-x86 specific code out of xen-hvm.c,
to xen-hvm-common.c. For now this new file is
only build for x86 targets.
s/build/built
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm-common.c | 473
flight 184923 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-build fail in 184917 REGR. vs. 184912
Tests which are
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
xen_read_physmap() is the first function requiring
xen_physmap QLIST being initialized. Move the init
call there.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
On 07.03.2024 12:31, Andrew Cooper wrote:
> On 07/03/2024 7:39 am, Jan Beulich wrote:
>> On 06.03.2024 18:21, Andrew Cooper wrote:
>>> On 06/03/2024 5:09 pm, Ross Lagerwall wrote:
On Tue, Mar 5, 2024 at 2:17 PM Jan Beulich wrote:
> On 05.03.2024 13:11, Andrew Cooper wrote:
>> ---
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
In a pair of commit we are going to call xen_read_physmap()
out of hw/i386/xen/xen-hvm.c.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/xen-hvm-common.h | 1 +
hw/i386/xen/xen-hvm.c | 4 ++--
2 files changed, 3
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
There can only be a single xen_memory_listener definition
in a qemu-system binary.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/xen-hvm-common.h | 1 +
hw/arm/xen_arm.c| 2 +-
hw/i386/xen/xen-hvm.c |
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
In order to build this file once for all targets, replace:
TARGET_PAGE_BITS -> qemu_target_page_bits()
TARGET_PAGE_SIZE -> qemu_target_page_size()
TARGET_PAGE_MASK -> -qemu_target_page_size()
Signed-off-by: Philippe Mathieu-Daudé
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
We are going to replace TARGET_PAGE_MASK by a
runtime variable. In order to reduce code duplication,
propagate TARGET_PAGE_MASK to get_physmapping() and
xen_phys_offset_to_gaddr().
Signed-off-by: Philippe Mathieu-Daudé
---
On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote:
Use TARGET_PAGE_SIZE to calculate TARGET_PAGE_ALIGN.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index
On 07/03/2024 7:39 am, Jan Beulich wrote:
> On 06.03.2024 18:21, Andrew Cooper wrote:
>> On 06/03/2024 5:09 pm, Ross Lagerwall wrote:
>>> On Tue, Mar 5, 2024 at 2:17 PM Jan Beulich wrote:
On 05.03.2024 13:11, Andrew Cooper wrote:
> --- a/xen/include/xen/virtual_region.h
> +++
flight 184930 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184930/
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 07.03.2024 12:01, Oleksii wrote:
> On Thu, 2024-03-07 at 11:46 +0100, Jan Beulich wrote:
>> On 07.03.2024 11:35, Oleksii wrote:
>>> On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote:
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> The header was taken from Linux kernl 6.4.0-rc1.
On 07.03.2024 11:38, Henry Wang wrote:
> Below error can be seen when doing Yocto build of the toolstack:
>
> | io.c: In function 'p9_error':
> | io.c:684:5: error: ignoring return value of 'strerror_r' declared
> with attribute 'warn_unused_result' [-Werror=unused-result]
> | 684 |
On Thu, 07 Mar 2024 12:43, Michal Orzel wrote:
On 07/03/2024 11:02, Manos Pitsidianakis wrote:
Hi Michal, Alex,
I'm responding to Michel but also giving my own review comments here.
On Thu, 07 Mar 2024 10:40, Michal Orzel wrote:
Hi Alex,
NIT: RFC tag is no longer needed.
On
On Thu, 2024-03-07 at 11:46 +0100, Jan Beulich wrote:
> On 07.03.2024 11:35, Oleksii wrote:
> > On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote:
> > > On 26.02.2024 18:38, Oleksii Kurochko wrote:
> > > > The header was taken from Linux kernl 6.4.0-rc1.
> > > >
> > > > Addionally, were
On 07.03.2024 11:35, Oleksii wrote:
> On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote:
>> On 26.02.2024 18:38, Oleksii Kurochko wrote:
>>> The header was taken from Linux kernl 6.4.0-rc1.
>>>
>>> Addionally, were updated:
>>> * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
On 07/03/2024 11:02, Manos Pitsidianakis wrote:
>
>
> Hi Michal, Alex,
>
> I'm responding to Michel but also giving my own review comments here.
>
> On Thu, 07 Mar 2024 10:40, Michal Orzel wrote:
>> Hi Alex,
>>
>> NIT: RFC tag is no longer needed.
>>
>> On 06/03/2024 17:56, Alex Bennée
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err, ring->buffer, ring->ring_size);
|
On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote:
> On 26.02.2024 18:38, Oleksii Kurochko wrote:
> > The header was taken from Linux kernl 6.4.0-rc1.
> >
> > Addionally, were updated:
> > * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
> > access.
> > * replace tabs with
Hi Michal, Alex,
I'm responding to Michel but also giving my own review comments here.
On Thu, 07 Mar 2024 10:40, Michal Orzel wrote:
Hi Alex,
NIT: RFC tag is no longer needed.
On 06/03/2024 17:56, Alex Bennée wrote:
While debugging VirtIO on Arm we ran into a warning due to memory
On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote:
> On 07.03.2024 11:00, Roger Pau Monné wrote:
> > On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
> >> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> >> from the elf headers. For Linux, this
On 07.03.2024 11:00, Roger Pau Monné wrote:
> On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
>> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
>> from the elf headers. For Linux, this defaults to 0x100 (16MB), but
>> it can be configured.
>>
>>
On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> from the elf headers. For Linux, this defaults to 0x100 (16MB), but
> it can be configured.
>
> Unfortunately there exist firmwares that have reserved
On Wed, Mar 6, 2024 at 11:38 PM Christopher Clark
wrote:
>
> On Sun, Feb 18, 2024 at 10:01 AM Julien Grall wrote:
> >
> > Hi Jan,
> >
> > On 14/02/2024 10:12, Jan Beulich wrote:
> > > find_ring_mfn() already holds a page reference when trying to obtain a
> > > writable type reference. We
On Wed, Mar 06, 2024 at 01:50:32PM -0500, Jason Andryuk wrote:
> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> from the elf headers. For Linux, this defaults to 0x100 (16MB), but
> it can be configured.
>
> Unfortunately there exist firmwares that have reserved
flight 184922 linux-6.1 real [real]
flight 184929 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184922/
http://logs.test-lab.xenproject.org/osstest/logs/184929/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Alex,
NIT: RFC tag is no longer needed.
On 06/03/2024 17:56, Alex Bennée wrote:
>
>
> While debugging VirtIO on Arm we ran into a warning due to memory
> being memcpy'd across MMIO space. While the bug was in the mappings
> the warning was a little confusing:
>
> (XEN) d47v2 Rn should
On 06.03.2024 18:28, Sébastien Chaumat wrote:
> Reasoning backward (using a kernel without the pinctrl_amd driver to
>> ensure xen only is at stake) :
>> checking the diff in IOAPIC between bare metal and xen (IRQ7 is on
>> pin07 on APIC )
>>
>> using kernel argument : apic=debug
>>
>> bare
On 07.03.2024 03:09, Stefano Stabellini wrote:
> On Wed, 6 Mar 2024, Jason Andryuk wrote:
>> Expand bzimage_parse() to return kernel_alignment from the setup_header.
>> This will be needed if loading a PVH kernel at a physical offset to
>> compensate for a reserved E820 region.
>>
>>
95 matches
Mail list logo
