On 13/11/23 18:11, David Woodhouse wrote:
On Mon, 2023-11-13 at 17:09 +0100, Philippe Mathieu-Daudé wrote:
On 13/11/23 16:58, Woodhouse, David wrote:
On 13 Nov 2023 10:22, Philippe Mathieu-Daudé
wrote:
Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move
common
function to x
On 13/11/23 21:03, David Woodhouse wrote:
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
"hw/xen/xen.h" contains declarations for Xen hardware. There is
no point including it when Xen is not available.
... if even when Xen *is* available, AFAICT. Can you just remove the
inclu
On 13/11/23 19:16, Richard Henderson wrote:
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index c028c1b541..03f9417e7e 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -426,10 +426,7 @@ static void handle_iore
On 13.11.2023 22:40, Jimmy Lee wrote:
> Hi Jan, thanks for the response! Adding more details and log files here:
>
> 1. I installed Xen 4.14 on CentOS 7 with yum:
>
> [root@test-xen ~]# yum list xen kernel
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile
> * base: dow
On 14.11.2023 00:58, Stefano Stabellini wrote:
> On Mon, 13 Nov 2023, Jan Beulich wrote:
>> On 19.10.2023 09:55, Nicola Vetrini wrote:
>>> The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
>>> compile-time check to detect non-scalar types; its usage for this
>>> purpose is deviated.
>>
flight 183746 linux-linus real [real]
flight 183749 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183746/
http://logs.test-lab.xenproject.org/osstest/logs/183749/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 13.11.23 23:40, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
With 9pfs being fully available in Xenstore-stubdom now, there is no
reason to not fully support all logging capabilities in stubdom.
Open the logfile on stubdom only after the 9pfs file system has bee
On 13.11.23 23:25, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
jus
On 13.11.23 23:09, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 162b87b460..4263c1360f 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -1236,6 +1236,8 @@ void stubdom_init
On 13.11.23 23:04, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
When running as stubdom, map the stubdom's Xenstore ring page in order
to support using the 9pfs frontend.
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 2 ++
tools/xenstored/domain.
On 13.11.23 18:36, Jason Andryuk wrote:
On Fri, Nov 10, 2023 at 11:08 AM Juergen Gross wrote:
Add "xen-9pfsd", a new logging daemon meant to support infrastructure
domains (e.g. xenstore-stubdom) to access files in dom0.
For now only add the code needed for starting the daemon and
registering
On 13.11.23 22:59, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:07, Juergen Gross wrote:
Obtain the own domid from the Xenstore special grant entry when running
as stubdom.
Signed-off-by: Juergen Gross
---
V2:
- replacement of V1 patch (ANdrew Cooper)
---
tools/xenstored/core.c | 1 +
> and if you had to be precise, the code should do:
>
> if (cpu_feature_enabled(X86_FEATURE_FRED)) {
> if (cpu_feature_enabled(X86_FEATURE_WRMSRNS))
> wrmsrns(MSR_IA32_FRED_RSP0, (unsigned
> long)task_stack_page(task) + THREAD_SIZE);
> else
>
On Thu, Sep 21, 2023 at 3:16 PM Akihiko Odaki wrote:
>
> On 2023/06/01 12:18, Akihiko Odaki wrote:
> > Recently MemReentrancyGuard was added to DeviceState to record that the
> > device is engaging in I/O. The network device backend needs to update it
> > when delivering a packet to a device.
> >
On Tue, Nov 14, 2023 at 12:43:38AM +, Li, Xin3 wrote:
> No. tglx asked for it:
> https://lkml.kernel.org/kvm/87y1h81ht4.ffs@tglx/
Aha
"According to the CPU folks FRED systems are guaranteed to have WRMSRNS -
I asked for that :). It's just not yet documented."
so I'm going to expect that to
flight 183745 xen-unstable real [real]
flight 183747 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183745/
http://logs.test-lab.xenproject.org/osstest/logs/183747/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
> Then, further down in the patchset, it says:
>
> + if (cpu_feature_enabled(X86_FEATURE_FRED)) {
> + /* WRMSRNS is a baseline feature for FRED. */
>
> but WRMSRNS is not mentioned in the FRED spec "Document Number:
> 346446-005US, Revision: 5.0" which, according to
>
> https://w
On Mon, 13 Nov 2023, Anthony PERARD wrote:
> On Thu, Nov 09, 2023 at 04:52:36PM +, Andrew Cooper wrote:
> > On 09/11/2023 3:49 pm, Anthony PERARD wrote:
> > > Currently, the test rely on QEMU and Xen finishing the boot in under
> > > two seconds. That's both very long and very short. Xen usuall
+Artem, Oleksandr
On Mon, 13 Nov 2023, Anthony PERARD wrote:
> On Thu, Nov 09, 2023 at 05:02:08PM -0800, Stefano Stabellini wrote:
> > ### qemu_key.sh is using "expect", see below. I think we should be able
> > ### to achieve the same by using expect to close on the expected string
> > ### (instea
On Mon, 13 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 Mon, 13 Nov 2023, Jan Beulich wrote:
> On 19.10.2023 09:55, Nicola Vetrini wrote:
> > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
> > compile-time check to detect non-scalar types; its usage for this
> > purpose is deviated.
> >
> > Furthermore, the 'typeof_field' macro is in
Add MISRA C Rules 11.1, 11.2, 11.3, 11.6 as discussed.
Explicitly add in the notes that conversions to integer types are
permitted if the destination type has enough bits to hold the entire
value. GCC gives enough guarantees in terms of preserving the bit
content in such situations.
Also allow fo
flight 183744 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183744/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183704
test-amd64-amd64-xl-qemuu-win7-a
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
With 9pfs being fully available in Xenstore-stubdom now, there is no
reason to not fully support all logging capabilities in stubdom.
Open the logfile on stubdom only after the 9pfs file system has been
mounted.
Signed-off-by: Juergen Gross
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
just expand them to be relative to /var/lib
On Mon, 13 Nov 2023, Jan Beulich wrote:
> On 06.11.2023 17:40, Kelly Choi wrote:
> > Hi all,
> >
> > As an open-source community, there will always be differences of opinion in
> > approaches and the way we think. It is imperative, however, that we view
> > this diversity as a source of strength r
Set the vPCI flag in xen_domctl_createdomain to enable vPCI if a pci
device has been specified in the xl domain config file.
Signed-off-by: Stewart Hildebrand
---
Same story as the patch before this regarding the [FUTURE] tag.
v5->v6:
* no change
v4->v5:
* no change
v3->v4:
* split from ("xen/
Select HAS_VPCI_GUEST_SUPPORT in Kconfig for enabling vPCI support for
domUs.
Add checks to fail guest creation if the configuration is invalid.
Signed-off-by: Stewart Hildebrand
---
As the tag implies, this patch is not intended to be merged (yet).
Note that CONFIG_HAS_VPCI_GUEST_SUPPORT is no
Set the vPCI flag in xen_domctl_createdomain to enable vPCI for dom0 if
iommu and PCI passthrough are enabled and there exists a PCI host bridge
in the system.
Adjust pci_host_iterate_bridges_and_count() to count the number of host
bridges if no callback is provided.
Signed-off-by: Stewart Hildeb
Both x86 and ARM need a way at domain creation time to specify whether
the domain needs vPCI emulation. Move the vPCI flag from x86
xen_domctl_createdomain.arch.emulation_flags to the common
xen_domctl_createdomain.flags.
Move has_vpci() macro to common header.
Bump XEN_DOMCTL_INTERFACE_VERSION s
From: Rahul Singh
Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM, even though
the feature is not yet complete in the current upstream codebase. The purpose of
this is to make it easier to enable the necessary configs (HAS_PCI, HAS_VPCI)
for
testing and development of PCI pas
There are multiple series in development/review [1], [2] that will benefit from
having a Kconfig option for PCI passthrough on ARM. Hence I have sent this
series independent from any other series.
v5->v6:
* address feedback in individual patches
v4->v5:
* add [FUTURE] tag to ("xen/arm: enable vPC
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 162b87b460..4263c1360f 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -1236,6 +1236,8 @@ void stubdom_init(void)
barf_perror("Fail
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
When running as stubdom, map the stubdom's Xenstore ring page in order
to support using the 9pfs frontend.
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 2 ++
tools/xenstored/domain.c | 27 ++-
too
Hi Juergen,
On 10/11/2023 16:07, Juergen Gross wrote:
Obtain the own domid from the Xenstore special grant entry when running
as stubdom.
Signed-off-by: Juergen Gross
---
V2:
- replacement of V1 patch (ANdrew Cooper)
---
tools/xenstored/core.c | 1 +
tools/xenstored/core.h | 1 +
tools
Hi Jan, thanks for the response! Adding more details and log files here:
1. I installed Xen 4.14 on CentOS 7 with yum:
[root@test-xen ~]# yum list xen kernel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: download.cf.centos.org
* centos-virt-xen-epel: d2lzkl7pf
On 11/6/23 04:26, Jan Beulich wrote:
> On 02.11.2023 20:59, Stewart Hildebrand wrote:
>> --- a/xen/arch/x86/include/asm/domain.h
>> +++ b/xen/arch/x86/include/asm/domain.h
>> @@ -503,6 +503,15 @@ struct arch_domain
>> #define has_vpit(d)(!!((d)->arch.emulation_flags & X86_EMU_PIT))
>> #de
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> Xen is a system specific accelerator, it makes no sense
> to include its headers in user emulation.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2023-11-13 at 16:21 +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.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhouse
smime.p7s
Descrip
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> "hw/xen/xen_pt.h" requires "hw/xen/xen_native.h" which is target
> specific. It also declares IGD methods, which are not target
> specific.
>
> Target-agnostic code can use IGD methods. To allow that, extract
> these methos into a
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> "hw/xen/xen.h" contains declarations for Xen hardware. There is
> no point including it when Xen is not available.
... if even when Xen *is* available, AFAICT. Can you just remove the
inclusion of hw/xen/xen.h entirely? I think tha
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> "sysemu/xen.h" defines CONFIG_XEN_IS_POSSIBLE as a target-agnostic
> version of CONFIG_XEN. Use it in order to use "sysemu/xen-mapcache.h"
> in target-agnostic files.
>
> Signed-off-by: Philippe Mathieu-Daudé
Noting that CONFIG_X
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> We rarely need to include "cpu.h" in headers. Including it
> 'taint' headers to be target-specific. Here only the i386/arm
> implementations requires "cpu.h", so include it there and
> remove from the "hw/xen/xen-hvm-common.h" *comm
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> Instead of the target-specific TARGET_PAGE_BITS definition,
> use qemu_target_page_bits() which is target agnostic.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptogra
On 11/13/23 08:26, Jan Beulich wrote:
> On 02.11.2023 20:59, Stewart Hildebrand wrote:
>> --- a/tools/libs/light/libxl_x86.c
>> +++ b/tools/libs/light/libxl_x86.c
>> @@ -8,13 +8,16 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>> {
>> switch(d_config->c_info.type) {
>> case LIB
On November 13, 2023 1:29:47 PM EST, Borislav Petkov wrote:
>On Mon, Nov 13, 2023 at 12:36:04PM -0500, H. Peter Anvin wrote:
>> A resource cannot be consumed after the value has been written; this
>> is the only necessary level of serialization, equivalent to, say, RAX.
>
>Lemme see if I understan
On Mon, 2023-11-13 at 18:01 +0100, Jan Beulich wrote:
> On 11.11.2023 11:24, Oleksii wrote:
> > This patch should be reworked as it fails Arm builds:
> > https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1068867920
>
> Took me a while to actually find the error. Would have been nice if
>
On Mon, Nov 13, 2023 at 12:36:04PM -0500, H. Peter Anvin wrote:
> A resource cannot be consumed after the value has been written; this
> is the only necessary level of serialization, equivalent to, say, RAX.
Lemme see if I understand this correctly using this context as an
example: after this MSR_
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
We rarely need to include "cpu.h" in headers. Including it
'taint' headers to be target-specific. Here only the i386/arm
implementations requires "cpu.h", so include it there and
remove from the "hw/xen/xen-hvm-common.h" *common* header.
Signed-of
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
Instead of the target-specific TARGET_PAGE_BITS definition,
use qemu_target_page_bits() which is target agnostic.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/xen/xen-hvm-common.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
R
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index c028c1b541..03f9417e7e 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -426,10 +426,7 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req)
trac
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
We don't need a target-specific header for common target-specific
prototypes. Declare xen_arch_handle_ioreq() and xen_arch_set_memory()
in "hw/xen/xen-hvm-common.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/xen_arch_hvm.h | 9
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
Use a common 'xen_arch_' prefix for architecture-specific functions.
Rename xen_arch_set_memory() and xen_arch_handle_ioreq().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/xen_arch_hvm.h | 4 ++--
include/hw/i386/xen_arch_hvm.h |
On 11/13/23 07:21, Philippe Mathieu-Daudé wrote:
Xen is a system specific accelerator, it makes no sense
to include its headers in user emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/sysemu/xen.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Richa
Pipeline #1070443312 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging-4.18 (
https://gitlab.com/xen-project/xen/-/commits/staging-4.18 )
Commit: 509f737d (
https://gitlab.com/xen-project/xen/-/commit/509f737d3e80c75f948eb896a08c324287b00adc
)
Commit Message: do
On Mon, Nov 13, 2023 at 04:50:23PM +, 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 th
On November 13, 2023 4:37:42 AM EST, Borislav Petkov wrote:
>On Mon, Oct 02, 2023 at 11:24:40PM -0700, Xin Li wrote:
>> From: "H. Peter Anvin (Intel)"
>>
>> MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to
>> be updated to point to the top of next task stack during task swit
On Fri, Nov 10, 2023 at 11:08 AM Juergen Gross wrote:
>
> Add "xen-9pfsd", a new logging daemon meant to support infrastructure
> domains (e.g. xenstore-stubdom) to access files in dom0.
>
> For now only add the code needed for starting the daemon and
> registering it with Xenstore via a new "libx
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common
> function to xen-hvm-common"), handle_ioreq() is expected to be
> target-agnostic. However it uses 'target_ulong', which is a target
> specific definition.
>
> In
On 16.10.23 09:28, Juergen Gross wrote:
Hello Juergen.
> The helper functions type_from_irq() and cpu_from_irq() are just one
> line functions used only internally.
>
> Open code them where needed. At the same time modify and rename
> get_evtchn_to_irq() to return a struct irq_info instead o
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> We don't need a target-specific header for common target-specific
> prototypes. Declare xen_arch_handle_ioreq() and xen_arch_set_memory()
> in "hw/xen/xen-hvm-common.h".
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Davi
On Mon, 2023-11-13 at 16:21 +0100, Philippe Mathieu-Daudé wrote:
> Use a common 'xen_arch_' prefix for architecture-specific functions.
> Rename xen_arch_set_memory() and xen_arch_handle_ioreq().
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhouse
smime.p7s
Description: S/M
flight 183743 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183743/
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 Fri, Nov 10, 2023 at 1:18 PM Juergen Gross wrote:
>
> Add some optional additional backend paths for 9pfs PV devices. Those
> paths will be supported by the new xenlogd 9pfs backend.
xen-9pfsd
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On Mon, 2023-11-13 at 17:09 +0100, Philippe Mathieu-Daudé wrote:
> On 13/11/23 16:58, Woodhouse, David wrote:
> > On 13 Nov 2023 10:22, Philippe Mathieu-Daudé
> > wrote:
> >
> > Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move
> > common
> > function to xen-hvm-common"), handl
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 11.11.2023 11:24, Oleksii wrote:
> This patch should be reworked as it fails Arm builds:
> https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1068867920
Took me a while to actually find the error. Would have been nice if you
had explained what's going wrong, supplying the link only as
On 13.11.2023 17:45, Jan Beulich wrote:
> On 10.11.2023 17:30, Oleksii Kurochko wrote:
>> Introduce an empty generic hypercall.h for archs which don't
>> implement it.
>>
>> Signed-off-by: Oleksii Kurochko
>
> Since - judging from Arm's present header - it looks technically possible
> for an arch
On 10.11.2023 17:30, Oleksii Kurochko wrote:
> iocap.h is common for Arm, PPC and RISC-V architectures thereby
> it was moved to asm-generic.
>
> Signed-off-by: Oleksii Kurochko
> ---
> The same question as with device.h. Should it be in asm-generic?
I think it's okay(ish) here, considering that
On 10.11.2023 17:30, Oleksii Kurochko wrote:
> Introduce an empty generic hypercall.h for archs which don't
> implement it.
>
> Signed-off-by: Oleksii Kurochko
Since - judging from Arm's present header - it looks technically possible
for an arch to get away with this:
Acked-by: Jan Beulich
Jan
On 10.11.2023 17:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/device.h
> @@ -0,0 +1,140 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_DEVICE_H__
> +#define __ASM_GENERIC_DEVICE_H__
> +
> +enum device_type
> +{
> +DEV_DT,
> +#ifdef HAS_
On 10.11.2023 17:30, Oleksii Kurochko wrote:
> The patch introduces generic paging.h header for Arm, PPC and
> RISC-V.
>
> All mentioned above architectures use hardware virt extensions
> and hardware pagetable extensions thereby it makes sense to set
> paging_mode_translate and paging_mode_extern
Pipeline #1070425841 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: fb41228e (
https://gitlab.com/xen-project/xen/-/commit/fb41228ececea948c7953c8c16fe28fd65c6536b
)
Commit Message: docs/sphinx:
On 13.11.2023 16:20, Luca Fancellu wrote:
>> On 13 Nov 2023, at 11:31, Jan Beulich wrote:
>> On 08.11.2023 10:53, Luca Fancellu wrote:
>> --
>
On Mon, Nov 13, 2023 at 03:20:53PM +, Luca Fancellu wrote:
>
>
> > On 13 Nov 2023, at 11:31, Jan Beulich wrote:
> >
> > On 08.11.2023 10:53, Luca Fancellu wrote:
> > -
isnumber() is already defined for some libcs [0] but the interface is not the
same, the isnumber() helper just checks if a single character is a digit.
Rename isnumber() to is_number() in order to avoid the clash.
[0] https://man.freebsd.org/cgi/man.cgi?query=isnumber&sektion=3
Signed-off-by: Ro
Hello,
A couple of fixes to allow building the tools on non-glibc systems (BSD
and musl tested).
No functional changes intended for either of the two fixes.
Thanks, Roger.
Roger Pau Monne (2):
livepatch-tools: add -largp option when required
livepatch-tools: fix isnumber() function clash
On 13/11/23 16:58, Woodhouse, David wrote:
On 13 Nov 2023 10:22, Philippe Mathieu-Daudé wrote:
Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common
function to xen-hvm-common"), handle_ioreq() is expected to be
target-agnostic. However it uses 'target_ulong', which is
crate-diff-object makes use of argp library, and depending on the libc
used by the system (ie: musl or BSD libc) argp is a separate library
and requires the addition of -largp to the build rune.
Introduce some shell logic to detect whether -largp is required for
linking create-diff-object.
I have
On 13 Nov 2023 10:22, Philippe Mathieu-Daudé wrote:
Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common
function to xen-hvm-common"), handle_ioreq() is expected to be
target-agnostic. However it uses 'target_ulong', which is a target
specific definition.
In order to compile this
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 s
On 16.10.23 09:28, Juergen Gross wrote:
Hello Juergen
> get_evtchn_to_irq() has only one external user while irq_from_evtchn()
> provides the same functionality and is exported for a wider user base.
> Modify the only external user of get_evtchn_to_irq() to use
> irq_from_evtchn() instead and
Hi Luca,
On 13/11/2023 15:17, Luca Fancellu wrote:
>
>
>> On 13 Nov 2023, at 11:58, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> Apart from pending question on static event channels code movement, a few
>> NITs.
>
> Related to that, it seems to me that this part can be handled by a separate
> pa
Previous commits re-organized the target-specific bits
from Xen files. We can now build the common files once
instead of per-target.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/xen/meson.build | 2 +-
hw/block/dataplane/meson.build | 2 +-
hw/xen/meson.build | 13 -
"hw/xen/xen_pt.h" requires "hw/xen/xen_native.h" which is target
specific. It also declares IGD methods, which are not target
specific.
Target-agnostic code can use IGD methods. To allow that, extract
these methos into a new "hw/xen/xen_igd.h" header.
Signed-off-by: Philippe Mathieu-Daudé
---
Wh
Hi George,
Thanks a lot for taking the time to have a look on that.
>
> Luca,
>
> Thank you so much for the work that you've done here.
>
> The approach in your v2 series looks plausible, as does a brief
> overview of the items in this list.
>
> One problem I have is how to really evaluate th
"hw/xen/xen.h" contains declarations for Xen hardware. There is
no point including it when Xen is not available. When Xen is not
available, we have enough with declarations of "sysemu/xen.h".
Signed-off-by: Philippe Mathieu-Daudé
---
system/physmem.c | 5 -
1 file changed, 4 insertions(+), 1
"sysemu/xen.h" defines CONFIG_XEN_IS_POSSIBLE as a target-agnostic
version of CONFIG_XEN. Use it in order to use "sysemu/xen-mapcache.h"
in target-agnostic files.
Signed-off-by: Philippe Mathieu-Daudé
---
include/sysemu/xen-mapcache.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Instead of the target-specific TARGET_PAGE_BITS definition,
use qemu_target_page_bits() which is target agnostic.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/xen/xen-hvm-common.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-c
We rarely need to include "cpu.h" in headers. Including it
'taint' headers to be target-specific. Here only the i386/arm
implementations requires "cpu.h", so include it there and
remove from the "hw/xen/xen-hvm-common.h" *common* header.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/x
We don't need a target-specific header for common target-specific
prototypes. Declare xen_arch_handle_ioreq() and xen_arch_set_memory()
in "hw/xen/xen-hvm-common.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/xen_arch_hvm.h | 9 -
include/hw/i386/xen_arch_hvm.h | 11 ---
Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common
function to xen-hvm-common"), handle_ioreq() is expected to be
target-agnostic. However it uses 'target_ulong', which is a target
specific definition.
In order to compile this file once for all targets, factor the
target-specific
Hi,
After discussing with Alex Bennée I realized most Xen code
should be target-agnostic. David Woodhouse confirmed that
last week, so I had a quick look and here is the result.
More work is required to be able to instanciate Xen HW in
an heterogeneous machine, but this doesn't make sense yet
unt
Use a common 'xen_arch_' prefix for architecture-specific functions.
Rename xen_arch_set_memory() and xen_arch_handle_ioreq().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/xen_arch_hvm.h | 4 ++--
include/hw/i386/xen_arch_hvm.h | 4 ++--
hw/arm/xen_arm.c | 4 ++--
hw/i
Xen is a system specific accelerator, it makes no sense
to include its headers in user emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/sysemu/xen.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/sysemu/xen.h b/include/sysemu/xen.h
index bc13ad569
> On 13 Nov 2023, at 11:31, Jan Beulich wrote:
>
> On 08.11.2023 10:53, Luca Fancellu wrote:
> --
>>
>> Standard: C++03
>>
>> ---
>> From
On Thu, Nov 09, 2023 at 04:52:36PM +, Andrew Cooper wrote:
> On 09/11/2023 3:49 pm, Anthony PERARD wrote:
> > Currently, the test rely on QEMU and Xen finishing the boot in under
> > two seconds. That's both very long and very short. Xen usually managed
> > to print "All set up" under a second.
Pipeline #1070357357 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 162a1589 (
https://gitlab.com/xen-project/xen/-/commit/162a1589e362ec47671b69a05464048360df5002
)
Commit Message: xen/set_{c,p}
On Mon, 2023-11-13 at 14:29 +0100, Jan Beulich wrote:
> On 13.11.2023 14:13, Oleksii wrote:
> > On Sat, 2023-11-11 at 12:25 +0200, Oleksii wrote:
> > > I missed to check the patch properly.
> > >
> > > The patch fails for Arm randconfigs:
> > > https://gitlab.com/xen-project/people/olkur/xen/-/pip
On Thu, Nov 09, 2023 at 05:02:08PM -0800, Stefano Stabellini wrote:
> ### qemu_key.sh is using "expect", see below. I think we should be able
> ### to achieve the same by using expect to close on the expected string
> ### (instead of waiting for eof)
So, `expect` is just a different kind of langua
1 - 100 of 158 matches
Mail list logo
