Re: preparations for 4.16.3
On 01.12.2022 14:20, Andrew Cooper wrote: > On 28/11/2022 10:50, Jan Beulich wrote: >> All, >> >> the release is due in a couple of weeks time; ideally we'd get it out >> before the year end break. >> >> Please point out backports you find missing from the respective staging >> branch, but which you consider relevant. > > I have a whole pile, all to do with (o)xenstored live update, but > they're sadly in my pending 4.18 branch. > > Hopefully there's time for those to get into staging before it's too > late to include for 4.16.3 too. I see you've pushed a bunch; I can't guess though which ones you would intend to be backported. Depending on the size of the set I may end up asking you to take care of cherry-picking. And of course I'll assume the oxenstored maintainers agree with whatever set is intended to be backported. Jan
Re: [XEN v2] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used to shift "unsigned long"
On 01.12.2022 19:11, Ayan Kumar Halder wrote:
> Machine frame number (mfn) is used to represent the hardware page address.
> This is an unsigned long variable. We need to check if it can hold the
> complete
> range of hardware page addresses. To ensure this we check that the count of
> bits
> represented by 'unsigned long' added to the bit index of page size, should be
> less than the count of bits required to represent the maximum physical
> address.
I'm afraid I can't connect the description with ...
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2245,7 +2245,7 @@ void __init xenheap_max_mfn(unsigned long mfn)
> {
> ASSERT(!first_node_initialised);
> ASSERT(!xenheap_bits);
> -BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG);
> +BUILD_BUG_ON((PADDR_BITS - PAGE_SHIFT) >= BITS_PER_LONG);
... the actual change made. Julien, when replying to v1, already gave
a clear hint what is relevant: The use of (xenheap_bits - PAGE_SHIFT)
in right hand operands of shift operators. As relevant is of course
the absence of uses directly as shift counts, which otherwise could
still be UB (and which iirc is why the adjustment by PAGE_SHIFT was
left out in the original check).
Jan
Re: [RFC PATCH 04/21] xen/arm: vIOMMU: add generic vIOMMU framework
On 01.12.2022 17:02, Rahul Singh wrote: > --- a/xen/drivers/passthrough/Kconfig > +++ b/xen/drivers/passthrough/Kconfig > @@ -35,6 +35,12 @@ config IPMMU_VMSA > (H3 ES3.0, M3-W+, etc) or Gen4 SoCs which IPMMU hardware supports > stage 2 > translation table format and is able to use CPU's P2M table as is. > > +config VIRTUAL_IOMMU > + bool "Virtual IOMMU Support (UNSUPPORTED)" if UNSUPPORTED > + default n > + help > + Support virtual IOMMU infrastructure to implement vIOMMU. I simply "virtual" specific enough in the name? Seeing that there are multiple IOMMU flavors for Arm, and judging from the titles of subsequent patches, you're implementing a virtualized form of only one variant. Also, nit: Please omit "default n" here - it leads to a needless line in the resulting .config, which in addition prevents the prompt from appearing for user selection when someone later enables UNSUPPORTED in their config and then runs e.g. "make oldconfig". But perhaps you anyway really mean config VIRTUAL_IOMMU bool "Virtual IOMMU Support (UNSUPPORTED)" depends on UNSUPPORTED help Support virtual IOMMU infrastructure to implement vIOMMU. ? Note (nit again) the slightly altered indentation I'm also using in the alternative suggestion. Jan
Re: [RFC PATCH 06/21] xen/domctl: Add XEN_DOMCTL_CONFIG_VIOMMU_* and viommu config param
On 01.12.2022 17:02, Rahul Singh wrote:
> Add new viommu_type field and field values XEN_DOMCTL_CONFIG_VIOMMU_NONE
> XEN_DOMCTL_CONFIG_VIOMMU_SMMUV3 in xen_arch_domainconfig to
> enable/disable vIOMMU support for domains.
>
> Also add viommu="N" parameter to xl domain configuration to enable the
> vIOMMU for the domains. Currently, only the "smmuv3" type is supported
> for ARM.
>
> Signed-off-by: Rahul Singh
> ---
> docs/man/xl.cfg.5.pod.in | 11 +++
> tools/golang/xenlight/helpers.gen.go | 2 ++
> tools/golang/xenlight/types.gen.go | 1 +
> tools/include/libxl.h| 5 +
> tools/libs/light/libxl_arm.c | 13 +
> tools/libs/light/libxl_types.idl | 6 ++
> tools/xl/xl_parse.c | 9 +
> 7 files changed, 47 insertions(+)
This diffstat taken together with the title makes me assume that e.g. ...
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -179,6 +179,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> return ERROR_FAIL;
> }
>
> +switch (d_config->b_info.arch_arm.viommu_type) {
> +case LIBXL_VIOMMU_TYPE_NONE:
> +config->arch.viommu_type = XEN_DOMCTL_CONFIG_VIOMMU_NONE;
... this constant doesn't exist yet, and hence this would fail to build
at this point in the series. I notice, however, that the constants are
introduced in earlier patches. Perhaps the title here wants re-wording?
Jan
Re: [RFC PATCH 07/21] xen/arm: vIOMMU: Add cmdline boot option "viommu = "
On 01.12.2022 17:02, Rahul Singh wrote: > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1896,6 +1896,13 @@ This option can be specified more than once (up to 8 > times at present). > > Flag to enable or disable support for PCI passthrough > > +### viommu (arm) > +> `= ` > + > +> Default: `false` > + > +Flag to enable or disable support for Virtual IOMMU for guests. > + > ### pcid (x86) > > `= | xpti=` I'm sorry for being blunt, but how did you select this particular slot for insertion, when the whole file clearly at least tries to have options sorted alphabetically. Apart from that I wonder whether this actually needs a command line control, when supposedly this is controlled on a per-domain basis anyway. Jan
Re: [RFC PATCH 11/21] xen/arm: vsmmuv3: Attach Stage-1 configuration to SMMUv3 hardware
On 01.12.2022 17:02, Rahul Singh wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -230,6 +230,15 @@ int iommu_do_dt_domctl(struct xen_domctl *, struct
> domain *,
>
> #endif /* HAS_DEVICE_TREE */
>
> +#ifdef CONFIG_ARM
> +struct iommu_guest_config {
> +paddr_t s1ctxptr;
> +uint8_t config;
> +uint8_t s1fmt;
> +uint8_t s1cdmax;
> +};
> +#endif /* CONFIG_ARM */
Perhaps rather CONFIG_VIRTUAL_IOMMU?
Jan
[PATCH net] xen-netfront: Fix NULL sring after live migration
A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: b4f041933900 CR2: 0008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time Signed-off-by: Lin Liu Fixes: 4ec2411980d0 ([NET]: Do not check netif_running() and carrier state in ->poll()) --- drivers/net/xen-netfront.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 9af2b027c19c..dc404e05970c 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1862,6 +1862,12 @@ static int netfront_resume(struct xenbus_device *dev) netif_tx_unlock_bh(info->netdev); xennet_disconnect_backend(info); + + rtnl_lock(); + if (info->queues) + xennet_destroy_queues(info); + rtnl_unlock(); + return 0; } -- 2.17.1
Re: [QEMU][PATCH v2 07/11] hw/xen/xen-hvm-common: Use g_new and error_setg_errno
Philippe Mathieu-Daudé writes:
> On 2/12/22 03:59, Vikram Garhwal wrote:
>> Replace g_malloc with g_new and perror with error_setg_errno.
>>
>> Signed-off-by: Vikram Garhwal
>> ---
>> hw/xen/xen-hvm-common.c | 15 ---
>> 1 file changed, 8 insertions(+), 7 deletions(-)
>
>
>> @@ -717,7 +717,7 @@ void destroy_hvm_domain(bool reboot)
>> xc_interface *xc_handle;
>> int sts;
>> int rc;
>> -
>> +Error *errp = NULL;
>> unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
>>
>> if (xen_dmod) {
>> @@ -726,7 +726,7 @@ void destroy_hvm_domain(bool reboot)
>> return;
>> }
>> if (errno != ENOTTY /* old Xen */) {
>> -perror("xendevicemodel_shutdown failed");
>> +error_setg_errno(&errp, errno, "xendevicemodel_shutdown
>> failed");
>
> See "qapi/error.h":
>
> * = Passing errors around =
> *
> * Errors get passed to the caller through the conventional @errp
> * parameter.
>
> Here you are not passing the error to the caller.
Instead, you're leaking its memory.
> Maybe you are looking for the "qemu/error-report.h" API?
Plausible.
Also, @errp is the conventional name for the Error ** parameter used to
pass errors to the caller. Local Error * variables are usually called
@err or @local_err (I prefer the former).
[...]
Re: [PATCH] xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource()
On 26.11.22 06:07, Harshit Mogalapalli wrote:
As 'kdata.num' is user-controlled data, if user tries to allocate
memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it
creates a stack trace and messes up dmesg with a warning.
Call trace:
-> privcmd_ioctl
--> privcmd_ioctl_mmap_resource
Add __GFP_NOWARN in order to avoid too large allocation warning.
This is detected by static analysis using smatch.
Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE")
Signed-off-by: Harshit Mogalapalli
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[xen-unstable-smoke test] 175019: tolerable all pass - PUSHED
flight 175019 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175019/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 1527066a7eaabcd18533135e81f9064e00b32428 baseline version: xen 8b3c06a3e545204515e50733669ad6f5c7bddfd8 Last test of basis 175016 2022-12-02 01:04:51 Z0 days Testing same since 175019 2022-12-02 05:01:57 Z0 days1 attempts People who touched revisions under test: Jan Beulich Michal Orzel Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 8b3c06a3e5..1527066a7e 1527066a7eaabcd18533135e81f9064e00b32428 -> smoke
Re: [PATCH v2 4/6] tools/oxenstored: Implement Domain.rebind_evtchn
> On 1 Dec 2022, at 12:10, Andrew Cooper wrote: > > On 01/12/2022 11:20, Christian Lindig wrote: >> >>> On 30 Nov 2022, at 16:54, Andrew Cooper wrote: >>> >>> Generally speaking, the event channel local/remote port is fixed for the >>> lifetime of the associated domain object. The exception to this is a >>> secondary XS_INTRODUCE (defined to re-bind to a new event channel) which >>> pokes >>> around at the domain object's internal state. >>> >>> We need to refactor the evtchn handling to support live update, so start by >>> moving the relevant manipulation into Domain. >>> >>> No practical change. >>> >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Christian Lindig >>> CC: David Scott >>> CC: Edwin Torok >>> CC: Rob Hoes >> Acked-by: Christian Lindig > > Thanks. > >> The code makes changes around if-expressions and it is easy to get mislead >> by indentation which parts are covered by an if and which are not in the >> presence of sequential code. I would be more confident about this with >> automatic formatting (but also believe this is correct). > > I can keep the being/end if you'd prefer. > > Looking at the end result, it would actually shrink the patch, so is > probably worth doing anyway for clarity. The net result is: > > diff --git a/tools/ocaml/xenstored/process.ml > b/tools/ocaml/xenstored/process.ml > index b2973aca2a82..1c80e7198dbe 100644 > --- a/tools/ocaml/xenstored/process.ml > +++ b/tools/ocaml/xenstored/process.ml > @@ -569,8 +569,7 @@ let do_introduce con t domains cons data = > let edom = Domains.find domains domid in > if (Domain.get_mfn edom) = mfn && > (Connections.find_domain cons domid) != con then begin > (* Use XS_INTRODUCE for recreating the > xenbus event-channel. *) > - edom.remote_port <- remote_port; > - Domain.bind_interdomain edom; > + Domain.rebind_evtchn edom remote_port; > end; > edom > else try > > I'm happy to adjust on commit. > > When I started this, I tried rearranging things to avoid the "if exists > then find" pattern, but quickly got into a mess, then realised that this > is (almost) a dead logic path... I've got no idea why this is supported; > looking through history, I can't find a case where a redundant > XS_INTRODUCE was ever used, but its a common behaviour between C and O > so there was clearly some reason... Currently the soft reset code in xenopsd uses it, but as you say there must've been another reason too (the soft reset code is a lot more recent than this). Best regards, --Edwin
Re: preparations for 4.16.3
On 02/12/2022 08:26, Jan Beulich wrote: > On 01.12.2022 14:20, Andrew Cooper wrote: >> On 28/11/2022 10:50, Jan Beulich wrote: >>> All, >>> >>> the release is due in a couple of weeks time; ideally we'd get it out >>> before the year end break. >>> >>> Please point out backports you find missing from the respective staging >>> branch, but which you consider relevant. >> I have a whole pile, all to do with (o)xenstored live update, but >> they're sadly in my pending 4.18 branch. >> >> Hopefully there's time for those to get into staging before it's too >> late to include for 4.16.3 too. > I see you've pushed a bunch; I can't guess though which ones you would > intend to be backported. Depending on the size of the set I may end up > asking you to take care of cherry-picking. And of course I'll assume > the oxenstored maintainers agree with whatever set is intended to be > backported. Yeah - very fortunate timing yesterday. The answer is all of them, plus some scattered earlier fixes which did manage to get into 4.17, and even some subsequent ones which are still pending for review. The major bugfix is keeping /dev/xen/evtchn open, and the preceding 8 patches are all part of that fix, but "not losing the critical information when things go wrong" is important too. Perhaps it would be easier for me to prepare the backports when the time comes? ~Andrew
Re: [PATCH] tools/oxenstored: Render backtraces more nicely in Syslog
> On 1 Dec 2022, at 21:19, Andrew Cooper wrote:
>
> fallback_exception_handler feeds a string with embedded newlines directly into
> syslog(). While this is an improvement on getting nothing, syslogd escapes
> all control characters it gets, and emits one (long) line into the log.
>
> Fix the problem generally in the syslog stub. As we already have a local copy
> of the string, split it in place and emit one syslog() call per line.
>
> Also tweak Logging.msg_of to avoid putting an extra newline on a string which
> already ends with one.
>
> Fixes: ee7815f49faf ("tools/oxenstored: Set uncaught exception handler")
> Signed-off-by: Andrew Cooper
> ---
> CC: Christian Lindig
> CC: David Scott
> CC: Edwin Torok
> CC: Rob Hoes
Acked-by: Christian Lindig
> ---
> tools/ocaml/xenstored/logging.ml | 2 +-
> tools/ocaml/xenstored/syslog_stubs.c | 26 +++---
> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/tools/ocaml/xenstored/logging.ml
> b/tools/ocaml/xenstored/logging.ml
> index 255051437d60..f233bc9a3956 100644
> --- a/tools/ocaml/xenstored/logging.ml
> +++ b/tools/ocaml/xenstored/logging.ml
> @@ -344,7 +344,7 @@ let watch_not_fired ~con perms path =
> access_logging ~tid:0 ~con ~data Watch_not_fired ~level:Info
>
> let msg_of exn bt =
> - Printf.sprintf "Fatal exception: %s\n%s\n" (Printexc.to_string exn)
> + Printf.sprintf "Fatal exception: %s\n%s" (Printexc.to_string exn)
> (Printexc.raw_backtrace_to_string bt)
>
> let fallback_exception_handler exn bt =
> diff --git a/tools/ocaml/xenstored/syslog_stubs.c
> b/tools/ocaml/xenstored/syslog_stubs.c
> index e16c3a9491d0..760e78ff73dc 100644
> --- a/tools/ocaml/xenstored/syslog_stubs.c
> +++ b/tools/ocaml/xenstored/syslog_stubs.c
> @@ -37,14 +37,34 @@ value stub_syslog(value facility, value level, value msg)
> {
> CAMLparam3(facility, level, msg);
> char *c_msg = strdup(String_val(msg));
Is this working as expected? An OCaml string may contain embedded null bytes.
> + char *s = c_msg, *ss;
> int c_facility = __syslog_facility_table[Int_val(facility)]
> | __syslog_level_table[Int_val(level)];
>
> if ( !c_msg )
> caml_raise_out_of_memory();
> - caml_enter_blocking_section();
> - syslog(c_facility, "%s", c_msg);
> - caml_leave_blocking_section();
> +
> + /*
> + * syslog() doesn't like embedded newlines, and c_msg generally
> + * contains them.
> + *
> + * Split the message in place by converting \n to \0, and issue one
> + * syslog() call per line, skipping the final iteration if c_msg ends
> + * with a newline anyway.
> + */
> + do {
> + ss = strchr(s, '\n');
> + if ( ss )
> + *ss = '\0';
> + else if ( *s == '\0' )
> + break;
> +
> + caml_enter_blocking_section();
> + syslog(c_facility, "%s", s);
> + caml_leave_blocking_section();
> +
> + s = ss + 1;
> + } while ( ss );
>
> free(c_msg);
> CAMLreturn(Val_unit);
> --
> 2.11.0
>
Re: preparations for 4.16.3
On 02.12.2022 10:11, Andrew Cooper wrote: > On 02/12/2022 08:26, Jan Beulich wrote: >> On 01.12.2022 14:20, Andrew Cooper wrote: >>> On 28/11/2022 10:50, Jan Beulich wrote: All, the release is due in a couple of weeks time; ideally we'd get it out before the year end break. Please point out backports you find missing from the respective staging branch, but which you consider relevant. >>> I have a whole pile, all to do with (o)xenstored live update, but >>> they're sadly in my pending 4.18 branch. >>> >>> Hopefully there's time for those to get into staging before it's too >>> late to include for 4.16.3 too. >> I see you've pushed a bunch; I can't guess though which ones you would >> intend to be backported. Depending on the size of the set I may end up >> asking you to take care of cherry-picking. And of course I'll assume >> the oxenstored maintainers agree with whatever set is intended to be >> backported. > > Yeah - very fortunate timing yesterday. The answer is all of them, plus > some scattered earlier fixes which did manage to get into 4.17, and even > some subsequent ones which are still pending for review. > > The major bugfix is keeping /dev/xen/evtchn open, and the preceding 8 > patches are all part of that fix, but "not losing the critical > information when things go wrong" is important too. > > Perhaps it would be easier for me to prepare the backports when the time > comes? Well, yes, "all of them" certainly was what I was fearing when saying "depending on the size of the set". So yes, please take care of the backporting once they've passed the push gate on staging. Jan
Re: [XEN v2] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used to shift "unsigned long"
Hi Jan,
On 02/12/2022 08:31, Jan Beulich wrote:
On 01.12.2022 19:11, Ayan Kumar Halder wrote:
Machine frame number (mfn) is used to represent the hardware page address.
This is an unsigned long variable. We need to check if it can hold the complete
range of hardware page addresses. To ensure this we check that the count of bits
represented by 'unsigned long' added to the bit index of page size, should be
less than the count of bits required to represent the maximum physical address.
I'm afraid I can't connect the description with ...
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2245,7 +2245,7 @@ void __init xenheap_max_mfn(unsigned long mfn)
{
ASSERT(!first_node_initialised);
ASSERT(!xenheap_bits);
-BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG);
+BUILD_BUG_ON((PADDR_BITS - PAGE_SHIFT) >= BITS_PER_LONG);
... the actual change made. Julien, when replying to v1, already gave
a clear hint what is relevant: The use of (xenheap_bits - PAGE_SHIFT)
in right hand operands of shift operators. As relevant is of course
the absence of uses directly as shift counts, which otherwise could
still be UB (and which iirc is why the adjustment by PAGE_SHIFT was
left out in the original check).
I could see the following uses of xenheap_bits in page_alloc.c
1. init_node_heap()
(!xenheap_bits ||
!((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
(!xenheap_bits ||
!((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
2. In alloc_xenheap_pages()
if ( xenheap_bits && (memflags >> _MEMF_bits) > xenheap_bits )
memflags &= ~MEMF_bits(~0U);
if ( !(memflags >> _MEMF_bits) )
memflags |= MEMF_bits(xenheap_bits);
From what I see, whenever "xenheap_bits" is used as a right hand
operand of shift operator, it is always used as "(xenheap_bits -
PAGE_SHIFT)".
So, is it correct to say this :-
Ensure (xenheap_bits - PAGE_SHIFT) can be used as a rhs operand of a
shift operator
We want to ensure that "xenheap_bits - PAGE_SHIFT" is strictly less than
the number of bits to represent unsigned long as it is used a rhs
operand to shift mfn.
- Ayan
Jan
Xen 4.17 rc4
Hi all, Xen 4.17 rc4 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.17.0-rc4 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.17.0-rc4/xen-4.17.0-rc4.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.17.0-rc4/xen-4.17.0-rc4.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (henry.w...@arm.com). Kind regards, Henry
[PATCH v2] gnttab: don't silently truncate GFNs in compat setup-table handling
Returning back truncated frame numbers is unhelpful: Quite likely
they're not owned by the domain (if it's PV), or we may misguide the
guest into writing grant entries into a page that it actually uses for
other purposes.
Signed-off-by: Jan Beulich
---
v2: Drop use of VALID_M2P(). Use "break". Move type change for "frame"
here (from earlier patch).
---
RFC: Arguably in the 32-bit PV case it may be necessary to instead put
in place an explicit address restriction when allocating
->shared_raw[N]. This is currently implicit by alloc_xenheap_page()
only returning memory covered by the direct-map.
--- unstable.orig/xen/common/compat/grant_table.c 2022-10-10
11:02:21.198223952 +0200
+++ unstable/xen/common/compat/grant_table.c2022-10-10 10:31:25.0
+0200
@@ -176,7 +176,12 @@ int compat_grant_table_op(
{ \
for ( i = 0; i < (_s_)->nr_frames; ++i ) \
{ \
-unsigned int frame = (_s_)->frame_list.p[i]; \
+compat_pfn_t frame = (_s_)->frame_list.p[i]; \
+if ( frame != (_s_)->frame_list.p[i] ) \
+{ \
+(_s_)->status = GNTST_address_too_big; \
+break; \
+} \
if ( __copy_to_compat_offset((_d_)->frame_list, \
i, &frame, 1) ) \
{ \
Re: [PATCH] tools/oxenstored: Render backtraces more nicely in Syslog
On 02/12/2022 09:14, Christian Lindig wrote:
>> On 1 Dec 2022, at 21:19, Andrew Cooper wrote:
>>
>> fallback_exception_handler feeds a string with embedded newlines directly
>> into
>> syslog(). While this is an improvement on getting nothing, syslogd escapes
>> all control characters it gets, and emits one (long) line into the log.
>>
>> Fix the problem generally in the syslog stub. As we already have a local
>> copy
>> of the string, split it in place and emit one syslog() call per line.
>>
>> Also tweak Logging.msg_of to avoid putting an extra newline on a string which
>> already ends with one.
>>
>> Fixes: ee7815f49faf ("tools/oxenstored: Set uncaught exception handler")
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Christian Lindig
>> CC: David Scott
>> CC: Edwin Torok
>> CC: Rob Hoes
> Acked-by: Christian Lindig
Thanks.
>
>> ---
>> tools/ocaml/xenstored/logging.ml | 2 +-
>> tools/ocaml/xenstored/syslog_stubs.c | 26 +++---
>> 2 files changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/ocaml/xenstored/logging.ml
>> b/tools/ocaml/xenstored/logging.ml
>> index 255051437d60..f233bc9a3956 100644
>> --- a/tools/ocaml/xenstored/logging.ml
>> +++ b/tools/ocaml/xenstored/logging.ml
>> @@ -344,7 +344,7 @@ let watch_not_fired ~con perms path =
>> access_logging ~tid:0 ~con ~data Watch_not_fired ~level:Info
>>
>> let msg_of exn bt =
>> -Printf.sprintf "Fatal exception: %s\n%s\n" (Printexc.to_string exn)
>> +Printf.sprintf "Fatal exception: %s\n%s" (Printexc.to_string exn)
>> (Printexc.raw_backtrace_to_string bt)
>>
>> let fallback_exception_handler exn bt =
>> diff --git a/tools/ocaml/xenstored/syslog_stubs.c
>> b/tools/ocaml/xenstored/syslog_stubs.c
>> index e16c3a9491d0..760e78ff73dc 100644
>> --- a/tools/ocaml/xenstored/syslog_stubs.c
>> +++ b/tools/ocaml/xenstored/syslog_stubs.c
>> @@ -37,14 +37,34 @@ value stub_syslog(value facility, value level, value msg)
>> {
>> CAMLparam3(facility, level, msg);
>> char *c_msg = strdup(String_val(msg));
> Is this working as expected? An OCaml string may contain embedded null bytes.
I wondered the same, but there's really nothing sane to be done.
This is for handling human readable strings, and attempting to force
NULs out via syslog() can't be done (because of syslog()'s API).
~Andrew
Re: [XEN v2] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used to shift "unsigned long"
On 02.12.2022 10:30, Ayan Kumar Halder wrote:
> Hi Jan,
>
> On 02/12/2022 08:31, Jan Beulich wrote:
>> On 01.12.2022 19:11, Ayan Kumar Halder wrote:
>>> Machine frame number (mfn) is used to represent the hardware page address.
>>> This is an unsigned long variable. We need to check if it can hold the
>>> complete
>>> range of hardware page addresses. To ensure this we check that the count of
>>> bits
>>> represented by 'unsigned long' added to the bit index of page size, should
>>> be
>>> less than the count of bits required to represent the maximum physical
>>> address.
>> I'm afraid I can't connect the description with ...
>>
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -2245,7 +2245,7 @@ void __init xenheap_max_mfn(unsigned long mfn)
>>> {
>>> ASSERT(!first_node_initialised);
>>> ASSERT(!xenheap_bits);
>>> -BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG);
>>> +BUILD_BUG_ON((PADDR_BITS - PAGE_SHIFT) >= BITS_PER_LONG);
>> ... the actual change made. Julien, when replying to v1, already gave
>> a clear hint what is relevant: The use of (xenheap_bits - PAGE_SHIFT)
>> in right hand operands of shift operators. As relevant is of course
>> the absence of uses directly as shift counts, which otherwise could
>> still be UB (and which iirc is why the adjustment by PAGE_SHIFT was
>> left out in the original check).
>
> I could see the following uses of xenheap_bits in page_alloc.c
>
> 1. init_node_heap()
>
> (!xenheap_bits ||
> !((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
>
> (!xenheap_bits ||
> !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
>
> 2. In alloc_xenheap_pages()
>
> if ( xenheap_bits && (memflags >> _MEMF_bits) > xenheap_bits )
> memflags &= ~MEMF_bits(~0U);
> if ( !(memflags >> _MEMF_bits) )
> memflags |= MEMF_bits(xenheap_bits);
>
> From what I see, whenever "xenheap_bits" is used as a right hand
> operand of shift operator, it is always used as "(xenheap_bits -
> PAGE_SHIFT)".
>
> So, is it correct to say this :-
>
> Ensure (xenheap_bits - PAGE_SHIFT) can be used as a rhs operand of a
> shift operator
>
> We want to ensure that "xenheap_bits - PAGE_SHIFT" is strictly less than
> the number of bits to represent unsigned long as it is used a rhs
> operand to shift mfn.
Yes. Plus, as said, it is also important to note that the value is never
used to shift an address (rather than a frame number), and going forward
then also shouldn't be (perhaps unless further precautions are taken).
Jan
Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
On 02/12/2022 03:24, Garhwal, Vikram wrote: Hi Julien, Hi Vikram, I am having trouble to differentiate your answers from my remark. For instance... From: Julien Grall Date: Sunday, October 16, 2022 at 10:48 AM To: Garhwal, Vikram , qemu-de...@nongnu.org Cc: Stabellini, Stefano , Peter Maydell , Stefano Stabellini , Anthony Perard , Paul Durrant , open list:ARM TCG CPUs , open list:X86 Xen CPUs Subject: Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine Hi, There seem to be some missing patches on xen-devel (including the cover letter). Is that expected? Not sure what went wrong there. I can see all of these on QEMU-devel. Perhaps xen-devel is not in maintainer’s list for all the xen files? On 15/10/2022 06:07, Vikram Garhwal wrote: Add a new machine xenpv which creates a IOREQ server to register/connect with Xen Hypervisor. I don't like the name 'xenpv' because it doesn't convey the fact that some of the HW may be emulated rather than para-virtualized. In fact one may only want to use for emulating devices. Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen' to select a Xen layout. Xen IOREQ connection expect the TARGET_PAGE_SIZE to 4096, and the xenpv machine on ARM will have no CPU definitions. We need to define TARGET_PAGE_SIZE appropriately ourselves. Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a TPM emulator and connects to swtpm running on host machine via chardev socket and support TPM functionalities for a guest domain. Extra command line for aarch64 xenpv QEMU to connect to swtpm: -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and provides access to TPM functionality over socket, chardev and CUSE interface. Github repo: https://github.com/stefanberger/swtpm Example for starting swtpm on host machine: mkdir /tmp/vtpm2 swtpm socket --tpmstate dir=/tmp/vtpm2 \ --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock & I see patches for QEMU but not Xen. How can this be tested with existing Xen? Will libxl ever create QEMU? Will send the patch for libxl Xen separately. ... the first two lines are my remarks and the 3rd is your answer. Can you configure your e-mail client to do proper quoting? [...] +dev = qdev_new(TYPE_TPM_TIS_SYSBUS); +object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp); +object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp); +busdev = SYS_BUS_DEVICE(dev); +sysbus_realize_and_unref(busdev, &error_fatal); +sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE); I can't find where GUEST_TPM_BASE is defined. But then the guest memory layout is not expected to be stable. With your current approach, it means QEMU would need to be rebuilt for every Xen version. Is it what we want? I cannot think of better way to do this. Either we add the the def here or rebuild it if GUEST_TPM_BASE changes for each xen version. The alternative would be to specify the address on the QEMU command line. The advantage is you could build a system where each guests have different layout. Cheers, -- Julien Grall
Re: [PATCH v2] gnttab: don't silently truncate GFNs in compat setup-table handling
On 02/12/2022 09:46, Jan Beulich wrote: > Returning back truncated frame numbers is unhelpful: Quite likely > they're not owned by the domain (if it's PV), or we may misguide the > guest into writing grant entries into a page that it actually uses for > other purposes. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper
Re: [QEMU][PATCH v2 05/11] include/hw/xen/xen_common: return error from xen_create_ioreq_server
On 2/12/22 08:19, Philippe Mathieu-Daudé wrote:
Hi Stefano and Vikram,
On 2/12/22 03:59, Vikram Garhwal wrote:
From: Stefano Stabellini
This is done to prepare for enabling xenpv support for ARM architecture.
On ARM it is possible to have a functioning xenpv machine with only the
PV backends and no IOREQ server. If the IOREQ server creation fails,
continue to the PV backends initialization.
Signed-off-by: Stefano Stabellini
Signed-off-by: Vikram Garhwal
---
include/hw/xen/xen_common.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 77ce17d8a4..6510ac15e0 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -467,9 +467,10 @@ static inline void xen_unmap_pcidev(domid_t dom,
{
}
-static inline void xen_create_ioreq_server(domid_t dom,
- ioservid_t *ioservid)
How long are we supposed to maintain this code? Per [*]:
In general XenProject.org supports stable branches for 18 months full
support plus 18 months security fixes. When a new X.Y.0 release is
made there is usually one more release on the to-be-retired stable
branch to mop up any loose patches sitting in the repository at which
point the branch is retired.
4.17 was just released. 4.5 was 7 years ago. IIUC EOL'ed 4 years ago.
[*]
https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases#Stable_Maintenance_Branches
+Paolo for commit 14efd8d3b5 ("meson, configure: move Xen detection to
meson"):
xen_libs = {
'4.11.0': [ 'xenstore', 'xenctrl', 'xendevicemodel',
'xenforeignmemory', 'xengnttab', 'xenevtchn', 'xentoolcore' ],
'4.10.0': [ 'xenstore', 'xenctrl', 'xendevicemodel',
'xenforeignmemory', 'xengnttab', 'xenevtchn', 'xentoolcore' ],
'4.9.0': [ 'xenstore', 'xenctrl', 'xendevicemodel',
'xenforeignmemory', 'xengnttab', 'xenevtchn' ],
'4.8.0': [ 'xenstore', 'xenctrl', 'xenforeignmemory',
'xengnttab', 'xenevtchn' ],
'4.7.1': [ 'xenstore', 'xenctrl', 'xenforeignmemory',
'xengnttab', 'xenevtchn' ],
'4.6.0': [ 'xenstore', 'xenctrl' ],
'4.5.0': [ 'xenstore', 'xenctrl' ],
'4.2.0': [ 'xenstore', 'xenctrl' ],
}
According to repology for the 'xen' package:
FreeBSD (ports):4.16
Debian 11: 4.14.5
Fedora 35: 4.16.2
Ubuntu 20.04: 4.11.3
OpenSUSE Leap 15.3: 4.14.1
RHEL 8: ?
[PATCH v2 0/4] OCaml bindings for hvm_param_get and xc_evtchn_status
Changes since v1: * dropped stdint.h patch, still being discussed on where to best fix it * addressed review comments (see individual patches' changes section) Edwin Török (4): CODING-STYLE: add .editorconfig to clarify indentation uses spaces tools/ocaml/libs/xc: add binding to xc_evtchn_status tools/ocaml/libs/xc: add hvm_param_get binding tools/ocaml: add .clang-format .editorconfig | 20 ++ tools/ocaml/.clang-format | 9 +++ tools/ocaml/libs/Makefile | 2 +- tools/ocaml/libs/xc/META.in | 2 +- tools/ocaml/libs/xc/Makefile| 2 +- tools/ocaml/libs/xc/xenctrl.ml | 62 ++ tools/ocaml/libs/xc/xenctrl.mli | 63 ++ tools/ocaml/libs/xc/xenctrl_stubs.c | 99 + 8 files changed, 256 insertions(+), 3 deletions(-) create mode 100644 .editorconfig create mode 100644 tools/ocaml/.clang-format -- 2.34.1
[PATCH v2 3/4] tools/ocaml/libs/xc: add hvm_param_get binding
Not to be confused which hvm_get_param, which also exists and has a different, more error-prone interface. This one always returns a 64-bit value, and that is retained in the OCaml binding as well, returning 'int64' (and not int, or nativeint which might have a different size). The integer here is unsigned in the C API, however OCaml only has signed integers. No bits are lost, it is just a matter of interpretation when printing and for certain arithmetic operations, however in the cases where the MSB is set it is very likely that the value is an address and no arithmetic should be performed on the OCaml side on it. (this is not a new problem with this binding, but worth mentioning given the difference in types) Signed-off-by: Edwin Török --- Changes since v1: * drop accidental extra numbers in variant names * use 'val' instead of 'result' for local var * add binding for hvm_param_set --- tools/ocaml/libs/xc/xenctrl.ml | 47 tools/ocaml/libs/xc/xenctrl.mli | 48 + tools/ocaml/libs/xc/xenctrl_stubs.c | 32 +++ 3 files changed, 127 insertions(+) diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml index 5dac47991e..370dac3fc8 100644 --- a/tools/ocaml/libs/xc/xenctrl.ml +++ b/tools/ocaml/libs/xc/xenctrl.ml @@ -299,6 +299,53 @@ external map_foreign_range: handle -> domid -> int -> nativeint -> Xenmmap.mmap_interface = "stub_map_foreign_range" +type hvm_param = + | HVM_PARAM_CALLBACK_IRQ + | HVM_PARAM_STORE_PFN + | HVM_PARAM_STORE_EVTCHN + | HVM_PARAM_UNDEF_3 + | HVM_PARAM_PAE_ENABLED + | HVM_PARAM_IOREQ_PFN + | HVM_PARAM_BUFIOREQ_PFN + | HVM_PARAM_UNDEF_7 + | HVM_PARAM_UNDEF_8 + | HVM_PARAM_VIRIDIAN + | HVM_PARAM_TIMER_MODE0 + | HVM_PARAM_HPET_ENABLED1 + | HVM_PARAM_IDENT_PT2 + | HVM_PARAM_UNDEF_13 + | HVM_PARAM_ACPI_S_STATE + | HVM_PARAM_VM86_TSS + | HVM_PARAM_VPT_ALIGN + | HVM_PARAM_CONSOLE_PFN + | HVM_PARAM_CONSOLE_EVTCHN + | HVM_PARAM_ACPI_IOPORTS_LOCATION + | HVM_PARAM_MEMORY_EVENT_CR0 + | HVM_PARAM_MEMORY_EVENT_CR3 + | HVM_PARAM_MEMORY_EVENT_CR4 + | HVM_PARAM_MEMORY_EVENT_INT3 + | HVM_PARAM_NESTEDHVM + | HVM_PARAM_MEMORY_EVENT_SINGLE_STEP + | HVM_PARAM_UNDEF_26 + | HVM_PARAM_PAGING_RING_PFN + | HVM_PARAM_MONITOR_RING_PFN + | HVM_PARAM_SHARING_RING_PFN + | HVM_PARAM_MEMORY_EVENT_MSR + | HVM_PARAM_TRIPLE_FAULT_REASON + | HVM_PARAM_IOREQ_SERVER_PFN + | HVM_PARAM_NR_IOREQ_SERVER_PAGES + | HVM_PARAM_VM_GENERATION_ID_ADDR + | HVM_PARAM_ALTP2M + | HVM_PARAM_X87_FIP_WIDTH6 + | HVM_PARAM_VM86_TSS_SIZED + | HVM_PARAM_MCA_CAP + +external hvm_param_get: handle -> domid -> hvm_param -> int64 + = "stub_xc_hvm_param_get" + +external hvm_param_set: handle -> domid -> hvm_param -> int64 -> unit + = "stub_xc_hvm_param_set" + external domain_assign_device: handle -> domid -> (int * int * int * int) -> unit = "stub_xc_domain_assign_device" external domain_deassign_device: handle -> domid -> (int * int * int * int) -> unit diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli index 6c9206bc74..e18d5cddb7 100644 --- a/tools/ocaml/libs/xc/xenctrl.mli +++ b/tools/ocaml/libs/xc/xenctrl.mli @@ -236,6 +236,54 @@ external map_foreign_range : handle -> domid -> int -> nativeint -> Xenmmap.mmap_interface = "stub_map_foreign_range" +(* needs to be sorted according to its numeric value, watch out for gaps! *) +type hvm_param = + | HVM_PARAM_CALLBACK_IRQ + | HVM_PARAM_STORE_PFN + | HVM_PARAM_STORE_EVTCHN + | HVM_PARAM_UNDEF_3 + | HVM_PARAM_PAE_ENABLED + | HVM_PARAM_IOREQ_PFN + | HVM_PARAM_BUFIOREQ_PFN + | HVM_PARAM_UNDEF_7 + | HVM_PARAM_UNDEF_8 + | HVM_PARAM_VIRIDIAN + | HVM_PARAM_TIMER_MODE0 + | HVM_PARAM_HPET_ENABLED1 + | HVM_PARAM_IDENT_PT2 + | HVM_PARAM_UNDEF_13 + | HVM_PARAM_ACPI_S_STATE + | HVM_PARAM_VM86_TSS + | HVM_PARAM_VPT_ALIGN + | HVM_PARAM_CONSOLE_PFN + | HVM_PARAM_CONSOLE_EVTCHN + | HVM_PARAM_ACPI_IOPORTS_LOCATION + | HVM_PARAM_MEMORY_EVENT_CR0 + | HVM_PARAM_MEMORY_EVENT_CR3 + | HVM_PARAM_MEMORY_EVENT_CR4 + | HVM_PARAM_MEMORY_EVENT_INT3 + | HVM_PARAM_NESTEDHVM + | HVM_PARAM_MEMORY_EVENT_SINGLE_STEP + | HVM_PARAM_UNDEF_26 + | HVM_PARAM_PAGING_RING_PFN + | HVM_PARAM_MONITOR_RING_PFN + | HVM_PARAM_SHARING_RING_PFN + | HVM_PARAM_MEMORY_EVENT_MSR + | HVM_PARAM_TRIPLE_FAULT_REASON + | HVM_PARAM_IOREQ_SERVER_PFN + | HVM_PARAM_NR_IOREQ_SERVER_PAGES + | HVM_PARAM_VM_GENERATION_ID_ADDR + | HVM_PARAM_ALTP2M + | HVM_PARAM_X87_FIP_WIDTH6 + | HVM_PARAM_VM86_TSS_SIZED + | HVM_PARAM_MCA_CAP + +external hvm_param_get: handle -> domid -> hvm_param -> int64 + = "stub_xc_hvm_param_get" + +external hvm_param_set: handle -> domid -> hvm_param -> int64 -> unit + = "stub_xc_hvm_param_set" + external domain_assign_device: handle -> domid -> (int * int * int * int) -> unit = "stub_xc_domain_assign_device" external domain_deassign_device: handle -> domid -> (int * int * int * int) -> unit diff --git a/to
[PATCH v2 1/4] CODING-STYLE: add .editorconfig to clarify indentation uses spaces
Add an .editorconfig to make it easier to keep patches compatible with
Xen's coding style, and to reemphasize what Xen's coding style is.
I thought that Xen demands tabs rather than spaces (which is more
difficult with OCaml because indentation tools use spaces,
and the use of tabs requires changing editor settings),
however CODING-STYLE says it is spaces.
Document this explicitly by adding a .editorconfig file (see editorconfig.org),
which is an editor agnostic format for specifying basic style properties like
indentation, either with native support in editors or via plugins.
It is safer than modelines because it only supports controlling a
restricted set of editor properties and not arbitrary commands as Vim
modelines would have, and works with editors other than Vim too.
(Vim has a deny list for modeline sandboxing, which is error-prone
because every time a new command gets added it needs to be added to the
deny list, which has been the source of a few CVEs in the past
and I disable Vim modelines everywhere as a precaution).
This file is added as a convenience for those who might have an editor
that supports it, and its presence should have no impact on those that
do not (want to) use it.
It also won't cause re-indentation of existing files when edited, only
newly added lines would follow the convention.
No functional change.
Signed-off-by: Edwin Török
---
.editorconfig | 20
1 file changed, 20 insertions(+)
create mode 100644 .editorconfig
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 00..cb2f27c581
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,20 @@
+# See ./CODING_STYLE
+root = true
+
+[*]
+end_of_line = lf
+indent_style = space
+charset = utf-8
+max_line_length = 79
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+# Makefiles must use tabs, otherwise they don't work
+[{Makefile,*.mk,Makefile.rules}]
+indent_style = tabs
+
+[*.{c,h}]
+indent_size = 4
+
+[*.{ml,mli}]
+indent_size = 2
--
2.34.1
[PATCH v2 2/4] tools/ocaml/libs/xc: add binding to xc_evtchn_status
There is no API or ioctl to query event channel status, it is only
present in xenctrl.h
The C union is mapped to an OCaml variant exposing just the value from the
correct union tag.
The information provided here is similar to 'lsevtchn', but rather than
parsing its output it queries the underlying API directly.
Signed-off-by: Edwin Török
---
Changes since v1:
* drop paragraph about where this is used
* add comment about max port
* use Xeneventchn.virq_t instead of int, add a dependency: xc -> eventchn
* initialize struct without memset-ing first
* use 2 CAMLreturn, I found an example in the OCaml stdlib that does that so
should be future-proof
https://github.com/ocaml/ocaml/blob/663e8d219f566095e3a9497c5bae07b6a95cae39/otherlibs/unix/dup_win32.c#L52-L77
* use Tag_some, defining it if needed
* fix typo on failwith
---
tools/ocaml/libs/Makefile | 2 +-
tools/ocaml/libs/xc/META.in | 2 +-
tools/ocaml/libs/xc/Makefile| 2 +-
tools/ocaml/libs/xc/xenctrl.ml | 15 +++
tools/ocaml/libs/xc/xenctrl.mli | 15 +++
tools/ocaml/libs/xc/xenctrl_stubs.c | 67 +
6 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/tools/ocaml/libs/Makefile b/tools/ocaml/libs/Makefile
index 7e7c27e2d5..15f45a6d66 100644
--- a/tools/ocaml/libs/Makefile
+++ b/tools/ocaml/libs/Makefile
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
SUBDIRS= \
mmap \
xentoollog \
- xc eventchn \
+ eventchn xc\
xb xs xl
.PHONY: all
diff --git a/tools/ocaml/libs/xc/META.in b/tools/ocaml/libs/xc/META.in
index 2ff4dcb6bf..6a273936a3 100644
--- a/tools/ocaml/libs/xc/META.in
+++ b/tools/ocaml/libs/xc/META.in
@@ -1,5 +1,5 @@
version = "@VERSION@"
description = "Xen Control Interface"
-requires = "unix,xenmmap"
+requires = "unix,xenmmap,xeneventchn"
archive(byte) = "xenctrl.cma"
archive(native) = "xenctrl.cmxa"
diff --git a/tools/ocaml/libs/xc/Makefile b/tools/ocaml/libs/xc/Makefile
index 3b76e9ad7b..1d9fecb06e 100644
--- a/tools/ocaml/libs/xc/Makefile
+++ b/tools/ocaml/libs/xc/Makefile
@@ -4,7 +4,7 @@ include $(OCAML_TOPLEVEL)/common.make
CFLAGS += -I../mmap $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
CFLAGS += $(APPEND_CFLAGS)
-OCAMLINCLUDE += -I ../mmap
+OCAMLINCLUDE += -I ../mmap -I ../eventchn
OBJS = xenctrl
INTF = xenctrl.cmi
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2ed7454b16..5dac47991e 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -267,6 +267,21 @@ external evtchn_alloc_unbound: handle -> domid -> domid ->
int
= "stub_xc_evtchn_alloc_unbound"
external evtchn_reset: handle -> domid -> unit = "stub_xc_evtchn_reset"
+(* FIFO has theoretical maximum of 2^28 ports, fits in an int *)
+type evtchn_interdomain = { dom: domid; port: int}
+
+type evtchn_stat =
+ | EVTCHNSTAT_unbound of domid
+ | EVTCHNSTAT_interdomain of evtchn_interdomain
+ | EVTCHNSTAT_pirq of int
+ | EVTCHNSTAT_virq of Xeneventchn.virq_t
+ | EVTCHNSTAT_ipi
+
+type evtchn_status = { vcpu: int; status: evtchn_stat }
+
+external evtchn_status: handle -> domid -> int -> evtchn_status option =
+ "stub_xc_evtchn_status"
+
external readconsolering: handle -> string = "stub_xc_readconsolering"
external send_debug_keys: handle -> string -> unit = "stub_xc_send_debug_keys"
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 0f80aafea0..6c9206bc74 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -206,6 +206,21 @@ external shadow_allocation_get : handle -> domid -> int
external evtchn_alloc_unbound : handle -> domid -> domid -> int
= "stub_xc_evtchn_alloc_unbound"
external evtchn_reset : handle -> domid -> unit = "stub_xc_evtchn_reset"
+
+type evtchn_interdomain = { dom: domid; port: int}
+
+type evtchn_stat =
+ | EVTCHNSTAT_unbound of domid
+ | EVTCHNSTAT_interdomain of evtchn_interdomain
+ | EVTCHNSTAT_pirq of int
+ | EVTCHNSTAT_virq of Xeneventchn.virq_t
+ | EVTCHNSTAT_ipi
+
+type evtchn_status = { vcpu: int; status: evtchn_stat }
+
+external evtchn_status: handle -> domid -> int -> evtchn_status option =
+ "stub_xc_evtchn_status"
+
external readconsolering : handle -> string = "stub_xc_readconsolering"
external send_debug_keys : handle -> string -> unit = "stub_xc_send_debug_keys"
external physinfo : handle -> physinfo = "stub_xc_physinfo"
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index d30585f21c..a492ea17fd 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -44,6 +44,10 @@
#define Val_none (Val_int(0))
#endif
+#ifndef Tag_some
+#define Tag_some 0
+#endif
+
#define string_of_option_array(array, index) \
((Field(array, index) == Val_none) ? NULL : String_val(Field(Field(array,
index), 0)))
@@ -641,6 +645,69 @@ CAMLprim value stub_xc_evtchn_reset(value xch, value domid)
CAMLreturn(
Re: [RFC PATCH 00/21] Add SMMUv3 Stage 1 Support for XEN guests
Hi Rahul, On 01/12/2022 17:02, Rahul Singh wrote: > > > The SMMUv3 supports two stages of translation. Each stage of translation can > be > independently enabled. An incoming address is logically translated from VA to > IPA in stage 1, then the IPA is input to stage 2 which translates the IPA to > the output PA. > > Stage 1 is intended to be used by a software entity to provide isolation or > translation to buffers within the entity, for example DMA isolation within an > OS. Stage 2 is intended to be available in systems supporting the > Virtualization Extensions and is intended to virtualize device DMA to guest VM > address spaces. When both stage 1 and stage 2 are enabled, the translation > configuration is called nested. > > Stage 1 translation support is required to provide isolation between different > devices within OS. XEN already supports Stage 2 translation but there is no > support for Stage 1 translation. The goal of this work is to support Stage 1 > translation for XEN guests. Stage 1 has to be configured within the guest to > provide isolation. > > We cannot trust the guest OS to control the SMMUv3 hardware directly as > compromised guest OS can corrupt the SMMUv3 configuration and make the system > vulnerable. The guest gets the ownership of the stage 1 page tables and also > owns stage 1 configuration structures. The XEN handles the root configuration > structure (for security reasons), including the stage 2 configuration. > > XEN will emulate the SMMUv3 hardware and exposes the virtual SMMUv3 to the > guest. Guest can use the native SMMUv3 driver to configure the stage 1 > translation. When the guest configures the SMMUv3 for Stage 1, XEN will trap > the access and configure hardware. > > SMMUv3 Driver(Guest OS) -> Configure the Stage-1 translation -> > XEN trap access -> XEN SMMUv3 driver configure the HW. > > SMMUv3 driver has to be updated to support the Stage-1 translation support > based on work done by the KVM team to support Nested Stage translation: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feauger%2Flinux%2Fcommits%2Fv5.11-stallv12-2stage-v14&data=05%7C01%7Cmichal.orzel%40amd.com%7Cecb9075a29974c8f5ad608dad3b5916f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638055074068482160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PdK4%2Bsps3%2FdXYJUDv3iCy%2Byaqbh1bOVb1AFzTtx1nts%3D&reserved=0 > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F852299%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7Cecb9075a29974c8f5ad608dad3b5916f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638055074068482160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5Kp7023HiA4Qbfi28wcPL20JyC2xLwwiyEUZcxTSCOA%3D&reserved=0 > > As the stage 1 translation is configured by XEN on behalf of the guest, > translation faults encountered during the translation process need to be > propagated up to the guest and re-injected into the guest. When the guest > invalidates stage 1 related caches, invalidations must be forwarded to the > SMMUv3 hardware. > > This patch series is sent as RFC to get the initial feedback from the > community. This patch series consists of 21 patches which is a big number for > the reviewer to review the patches but to understand the feature end-to-end we > thought of sending this as a big series. Once we will get initial feedback, we > will divide the series into a small number of patches for review. Due to the very limited availability of the board we have, that is equipped with DMA platform devices and SMMUv3 (I know that you tested PCI use case thoroughly), I managed for now to do the testing on dom0 only. By commenting out the code in Linux responsible for setting up Xen SWIOTLB DMA ops, I was able to successfully verify the nested SMMU working properly for DMA platform devices on the example of using ZDMA. Both the upstream dmatest client app as well as the VFIO user space driver that I wrote for ZDMA passed the test! I added some logs to verify the sync up between Linux and Xen during a VFIO test: LINUX: SMMUv3: Setting the STE S1 Config 0x1405c000 for SID=0x210 XEN: vSMMUv3: guest config=ARM_SMMU_DOMAIN_NESTED XEN: SMMUv3: Setting the STE S1 Config 0x1405c000 for SID=0x210 Before transfer example: src value: 0xdb71faf dst value: 0 Waiting for transfer completion... After transfer example: src value: 0xdb71faf dst value: 0xdb71faf TEST RESULT: PASS LINUX: SMMUv3: Setting the STE S1 Config 0x12502000 for SID=0x210 XEN: vSMMUv3: guest config=ARM_SMMU_DOMAIN_NESTED XEN: SMMUv3: Setting the STE S1 Config 0x12502000 for SID=0x210 ~Michal
Re: [PATCH v6 2/3] automation: Add a clean rule for containers
Hi Bertrand, On 01/12/2022 15:25, Bertrand Marquis wrote: > > > Add make clean support to remove the containers from the local docker > registry. > make clean- must be called to remove an image: > make clean-yocto/kirkstone-qemuarm: remove yocto kirkstone for qemuarm > image > > Signed-off-by: Bertrand Marquis Reviewed-by: Michal Orzel ~Michal
Re: [PATCH v6 1/3] automation: Create Yocto docker images
Hi Bertrand, On 01/12/2022 15:25, Bertrand Marquis wrote: > > > Add containers suitable to run yocto kirkstone build based on ubuntu > 22.04. It contains all packages required by Yocto and a checkout of the > layers required to build Xen with Yocto. > > Add a generic docker image template to be used to automatically generate > docker files for different configurations: > - specific yocto version > - different targets (qemu arm, arm64 and x86) > - different host platforms (x86 or arm64) > > During a call to 'make all', only the images for the host platform we > run it on in the CI is generated. > If needed, images for an other host platform can be generated manually > by calling the right make target (see make help). > > Add a build script to build and run xen on qemu using Yocto. > The script supports arm32, arm64 and x86_64 and checks that dom0 is > properly booting. At this stage this does not run any guest on top of > dom0. The script is to be executed in one of the docker images to build > and run a system using a Xen source tree. > > Add automation/build/yocto/*.dockerfile to gitignore as those files are > generated. > > Signed-off-by: Bertrand Marquis Reviewed-by: Michal Orzel I know that Stefano tested the build/run on arm64. I did the same locally on x86 successfully. ~Michal
[PATCH v2 4/4] tools/ocaml: add .clang-format
Add a .clang-format configuration that tries to match CODING_STYLE where possible. I was not able to express the special casing of braces after 'do' though, this can only be controlled generally for all control statements. It is imperfect, but should be better than the existing bindings, which do not follow Xen coding style. Add this to tools/ocaml first because: * there are relatively few C files here, and it is a good place to start with * it'd be useful to make these follow Xen's CODING_STYLE (which they currently do not because they use tabs for example) * they change relatively infrequently, so shouldn't cause issues with backporting security fixes (could either backport the reindentation patch too, or use git cherry-pick with `-Xignore-space-change`) Does not yet reformat any code. No functional change. Signed-off-by: Edwin Török Acked-by: Christian Lindig --- Changes since v1: * change commit title to reflect this is for OCaml subtree only * don't mention stdint.h here, that may be fixed in a different way elsewhere --- tools/ocaml/.clang-format | 9 + 1 file changed, 9 insertions(+) create mode 100644 tools/ocaml/.clang-format diff --git a/tools/ocaml/.clang-format b/tools/ocaml/.clang-format new file mode 100644 index 00..7ff88ee043 --- /dev/null +++ b/tools/ocaml/.clang-format @@ -0,0 +1,9 @@ +BasedOnStyle: GNU +IndentWidth: 4 + +# override GNU to match Xen ../../CODING_STYLE more closely +AlwaysBreakAfterDefinitionReturnType: None +AlwaysBreakAfterReturnType: None +SpacesInConditionalStatement: true +SpaceBeforeParens: ControlStatements +BreakBeforeBraces: Allman -- 2.34.1
[linux-linus test] 175011: regressions - FAIL
flight 175011 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175011/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-coresched-amd64-xl broken in 175004 test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-examine 8 reboot fail REGR. vs. 173462 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-raw 8 xen-boot fail REGR. vs. 173462 Tests which are failing intermittently (not blocking): test-amd64-coresched-amd64-xl 5 host-install(5) broken in 175004 pass in 175011 test-amd64-amd64-freebsd11-amd64 19 guest-localmigrate/x10 fail in 175004 pass in 175011 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 175004 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 173462 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173462 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173462 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: linuxef4d3ea40565a781c25847e9cb96c1bd9f462bc6 baseline version: linux9d84bb40bcb30a7fa16f33baa967aeb9953dda78 Last test of basis 173462 2022-10-07 18:41:45 Z 55 days Failing since173470 2022-10-08 06:21:34 Z 55 days 107 attempts Testing same since 174998 2022-11-30 19:12:42 Z1 days4 attempts 1925 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops
Re: [ANNOUNCE] Call for agenda items for 1 December Community Call @ 1600 UTC
> On 1 Dec 2022, at 21:56, Elliott Mitchell wrote: > > On Thu, Nov 24, 2022 at 05:11:36PM +, George Dunlap wrote: >> >> == Dial-in Information == >> ## Meeting time >> 16:00 - 17:00 UTC >> Further International meeting times: >> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=12&day=1&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179 >> Ellliot, Thanks for your feedback. Replies in-line. > I guess I have to ask, what is the goal of the Community Call? Neither > this message, nor the wiki page > (https://wiki.xenproject.org/wiki/Community_Call) say much about the > Community Call. The goal of the call in general is just to talk about things that need talking about. We obviously have the mailing list, but sometimes discussions here are easy to miss; and sometimes a discussion can get sorted out more quickly with a fast back-and-forth than with long email chains. The intent has always been that if we start getting one topic that consistently 1) takes up a large amount of time and 2) only requires a subset of the attendees, to split it off into a separate meeting. > Varies from place to place, but many places meeting times are more > aspirational than ridged. As such I felt rather disparaged by being > careful about time, but no (obvious) effort spent prioritizing items. It’s been quite a while since we’ve run so long. I don’t necessarily have an objection to the call going long if people have time, but in this particular case I personally had to leave. We have, in the past, continued a long-running part of the discussion past the end of the time; and once after I left and a handful of people stayed in the room for another hour and a half continuing the discussion they had started. In those cases, it was clear that the people key to the discussion were willing to stay on later. At yesterday’s meeting, I could have asked for a volunteer to run the meeting after I left, but as Andrew was also leaving, and a number of the subsequent discussions required either me or him, it wasn’t immediately clear that this would be fruitful. > This seemed to be being pointed out at the end of D.3, which was meant as > low-priority, but was dealt with first purely due to being added first. > Then most of the time was spent on D.4 when D.9 actually seemed a rather > timely issue (the idea to get a bit of consideration before 4.17). To be honest, part of my reluctance to move that one up in the agenda was because it was my own item. Even with the number of items ahead of it, I didn’t expect it to be a problem to get to — there were several items which took much longer to discuss than I was expecting. In the future I’ll be more pro-active about trying to prioritize things. > Problem with D.1 being at the start is it was unexpected half the agenda > would be thrown in the garbage due to time. Could I suggest the 10th as > better? The 10th of January instead of the 12th of January? Why is that better? I work as a stay-at-home dad on Tuesdays, so I wouldn’t be able to chair the meeting if it was on the 10th. Hope all that makes sense; feel free to come back with further questions / recommendations. Thanks, -George signature.asc Description: Message signed with OpenPGP
Re: [PATCH v2 3/4] tools/ocaml/libs/xc: add hvm_param_get binding
On 02/12/2022 10:55, Edwin Török wrote: > Not to be confused which hvm_get_param, which also exists and has a > different, more error-prone interface. > > This one always returns a 64-bit value, and that is retained in the > OCaml binding as well, returning 'int64' (and not int, or nativeint > which might have a different size). > > The integer here is unsigned in the C API, however OCaml only has signed > integers. > > No bits are lost, it is just a matter of interpretation when printing > and for certain arithmetic operations, however in the cases where the > MSB is set it is very likely that the value is an address and no > arithmetic should be performed on the OCaml side on it. > (this is not a new problem with this binding, but worth mentioning given > the difference in types) > > Signed-off-by: Edwin Török Reviewed-by: Andrew Cooper
Re: [PATCH v2] hvc/xen: prevent concurrent accesses to the shared ring
On Wed, Nov 30, 2022 at 05:08:06PM -0800, Stefano Stabellini wrote: > On Wed, 30 Nov 2022, Roger Pau Monne wrote: > > The hvc machinery registers both a console and a tty device based on > > the hv ops provided by the specific implementation. Those two > > interfaces however have different locks, and there's no single locks > > that's shared between the tty and the console implementations, hence > > the driver needs to protect itself against concurrent accesses. > > Otherwise concurrent calls using the split interfaces are likely to > > corrupt the ring indexes, leaving the console unusable. > > > > Introduce a lock to xencons_info to serialize accesses to the shared > > ring. This is only required when using the shared memory console, > > concurrent accesses to the hypercall based console implementation are > > not an issue. > > > > Note the conditional logic in domU_read_console() is slightly modified > > so the notify_daemon() call can be done outside of the locked region: > > it's an hypercall and there's no need for it to be done with the lock > > held. > > For domU_read_console: I don't mean to block this patch but we need to > be sure about the semantics of hv_ops.get_chars. Either it is expected > to be already locked, then we definitely shouldn't add another lock to > domU_read_console. Or it is not expected to be already locked, then we > should add the lock. > > My impression is that it is expected to be already locked, but I think > we need Greg or Jiri to confirm one way or the other. Let me move both to the 'To:' field then. My main concern is the usage of hv_ops.get_chars hook in hvc_poll_get_char(), as it's not obvious to me that callers of tty->poll_get_char hook as returned by tty_find_polling_driver() will always do so with the tty lock held (in fact the only user right now doesn't seem to hold the tty lock). > Aside from that the rest looks fine. Thanks for the review, Roger.
Re: [PATCH v2 2/4] tools/ocaml/libs/xc: add binding to xc_evtchn_status
On 02/12/2022 10:55, Edwin Török wrote:
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index d30585f21c..a492ea17fd 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -641,6 +645,69 @@ CAMLprim value stub_xc_evtchn_reset(value xch, value
> domid)
> CAMLreturn(Val_unit);
> }
>
> +CAMLprim value stub_xc_evtchn_status(value xch, value domid, value port)
> +{
> +CAMLparam3(xch, domid, port);
> +CAMLlocal4(result, result_status, stat, interdomain);
> +xc_evtchn_status_t status = {
> +.dom = _D(domid),
> +.port = Int_val(port),
> +};
> +int rc;
> +
> +caml_enter_blocking_section();
> +rc = xc_evtchn_status(_H(xch), &status);
> +caml_leave_blocking_section();
> +
> +if ( rc < 0 )
> +failwith_xc(_H(xch));
> +
> +if ( status.status == EVTCHNSTAT_closed )
> +CAMLreturn(Val_none);
> +
> +switch ( status.status )
> +{
The EVTCHNSTAT_closed wants to be a case here, otherwise it's really
weird to read from a C point of view.
It would be fine to have a comment like this:
case EVTCHNSTAT_closed:
CAMLreturn(Val_none); /* Early exit, no allocations needed. */
to help identify more clearly that this a bit of a special case.
> +case EVTCHNSTAT_unbound:
> +stat = caml_alloc(1, 0); /* 1st non-constant constructor */
> +Store_field(stat, 0, Val_int(status.u.unbound.dom));
> +break;
> +
> +case EVTCHNSTAT_interdomain:
> +interdomain = caml_alloc_tuple(2);
> +Store_field(interdomain, 0, Val_int(status.u.interdomain.dom));
> +Store_field(interdomain, 1, Val_int(status.u.interdomain.port));
> +stat = caml_alloc(1, 1); /* 2nd non-constant constructor */
> +Store_field(stat, 0, interdomain);
> +break;
Newline here.
> +case EVTCHNSTAT_pirq:
> +stat = caml_alloc(1, 2); /* 3rd non-constant constructor */
> +Store_field(stat, 0, Val_int(status.u.pirq));
> +break;
> +
> +case EVTCHNSTAT_virq:
> +stat = caml_alloc(1, 3); /* 4th non-constant constructor */
> +Store_field(stat, 0, Val_int(status.u.virq));
> +break;
> +
> +case EVTCHNSTAT_ipi:
> +stat = Val_int(0); /* 1st constant constructor */
> +break;
> +
> +default:
> +caml_failwith("Unknown evtchn status");
> +
> +}
> +result_status = caml_alloc_tuple(2);
> +Store_field(result_status, 0, Val_int(status.vcpu));
> +Store_field(result_status, 1, stat);
> +
> +/* caml_alloc_some is missing in older versions of OCaml
> + */
I'd just drop this comment. It's going to be many many years before
Ocaml 4.12 drops off the bottom of the support list, so this observation
is unactionable.
All 3 of these are trivial to fix on commit, so Reviewed-by: Andrew
Cooper otherwise.
~Andrew
Re: [PATCH v2 3/4] tools/ocaml/libs/xc: add hvm_param_get binding
> On 2 Dec 2022, at 10:55, Edwin Török wrote: > > Not to be confused which hvm_get_param, which also exists and has a > different, more error-prone interface. > > This one always returns a 64-bit value, and that is retained in the > OCaml binding as well, returning 'int64' (and not int, or nativeint > which might have a different size). > > The integer here is unsigned in the C API, however OCaml only has signed > integers. > > No bits are lost, it is just a matter of interpretation when printing > and for certain arithmetic operations, however in the cases where the > MSB is set it is very likely that the value is an address and no > arithmetic should be performed on the OCaml side on it. > (this is not a new problem with this binding, but worth mentioning given > the difference in types) > > Signed-off-by: Edwin Török Acked-by: Christian Lindig
Re: [PATCH 1/3] acpi/processor: fix evaluating _PDC method when running as Xen dom0
On Wed, Nov 30, 2022 at 08:48:14AM -0800, Dave Hansen wrote: > On 11/30/22 07:53, Roger Pau Monné wrote: > > On Tue, Nov 29, 2022 at 09:43:53AM -0800, Dave Hansen wrote: > >> On 11/21/22 02:21, Roger Pau Monne wrote: > >>> When running as a Xen dom0 the number of CPUs available to Linux can > >>> be different from the number of CPUs present on the system, but in > >>> order to properly fetch processor performance related data _PDC must > >>> be executed on all the physical CPUs online on the system. > >> > >> How is the number of CPUs available to Linux different? > >> > >> Is this a result of the ACPI tables that dom0 sees being "wrong"? > > > > Depends on the mode. This is all specific to Linux running as a Xen > > dom0. > > > > For PV dom0 the ACPI tables that dom0 sees are the native ones, > > however available CPUs are not detected based on the MADT, but using > > hypercalls, see xen_smp_ops struct and the > > x86_init.mpparse.get_smp_config hook used in smp_pv.c > > (_get_smp_config()). > > > > For a PVH dom0 Xen provides dom0 with a crafted MADT table that does > > only contain the CPUs available to dom0, and hence is likely different > > from the native one present on the hardware. > > > > In any case, the dynamic tables dom0 sees where the Processor > > objects/devices reside are not modified by Xen in any way, so the ACPI > > Processors are always exposed to dom0 as present on the native > > tables. > > > > Xen cannot parse the dynamic ACPI tables (neither should it, since > > then it would act as OSPM), so it relies on dom0 to provide same data > > present on those tables for Xen to properly manage the frequency and > > idle states of the CPUs on the system. > > > >>> The current checks in processor_physically_present() result in some > >>> processor objects not getting their _PDC methods evaluated when Linux > >>> is running as Xen dom0. Fix this by introducing a custom function to > >>> use when running as Xen dom0 in order to check whether a processor > >>> object matches a CPU that's online. > >> > >> What is the end user visible effect of this problem and of the solution? > > > > Without this fix _PDC is only evaluated for the CPUs online from dom0 > > point of view, which means that if dom0 is limited to 8 CPUs but the > > system has 24 CPUs, _PDC will only get evaluated for 8 CPUs, and that > > can have the side effect of the data then returned by _PSD method or > > other methods being different between CPUs where _PDC was evaluated vs > > CPUs where the method wasn't evaluated. Such mismatches can > > ultimately lead to for example the CPU frequency driver in Xen not > > initializing properly because the coordination methods between CPUs on > > the same domain don't match. > > > > Also not evaluating _PDC prevents the OS (or Xen in this case) > > from notifying ACPI of the features it supports. > > > > IOW this fix attempts to make sure all physically online CPUs get _PDC > > evaluated, and in order to to that we need to ask the hypervisor if a > > Processor ACPI ID matches an online CPU or not, because Linux doesn't > > have that information when running as dom0. > > > > Hope the above makes sense and allows to make some progress on the > > issue, sometimes it's hard to summarize without getting too > > specific, > > Yes, writing changelogs is hard. :) > > Let's try though. I was missing some key pieces of background here. > Believe it or not, I had no idea off the top of my head what _PDC was or > why it's important. > > the information about _PDC being required on all processors was missing, > as was the information about the dom0's incomplete concept of the > available physical processors. > > == Background == > > In ACPI systems, the OS can direct power management, as opposed to the > firmware. This OS-directed Power Management is called OSPM. Part of > telling the firmware that the OS going to direct power management is > making ACPI "_PDC" (Processor Driver Capabilities) calls. These _PDC > calls must be made on every processor. If these _PDC calls are not > completed on every processor it can lead to inconsistency and later > failures in things like the CPU frequency driver. I think the "on every processor" is not fully accurate. _PDC methods need to be evaluated for every Processor object. Whether that evaluation is executed on the physical processor that matches the ACPI UID of the object/device is not mandatory (iow: you can evaluate the _PDC methods of all Processor objects from the BSP). The usage of 'on' seems to me to note that the methods are executed on the matching physical processors. I would instead use: "... must be made for every processor. If these _PDC calls are not completed for every processor..." But I'm not a native English speaker, so this might all be irrelevant. > > In a Xen system, the dom0 kernel is responsible for system-wide power > management. The dom0 kernel is in charge of OSPM. However, the Xen > hypervisor hides so
[XEN v3] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used as a rhs operand of shift operator
We want to ensure that "xenheap_bits - PAGE_SHIFT" is strictly less than
the number of bits to represent unsigned long as it is used a rhs operand
to shift mfn.
It is also important to note that the "xenheap_bits - PAGE_SHIFT" is never
used to shift an address (rather than a frame number), and going forward
then also shouldn't be (perhaps unless further precautions are taken).
Signed-off-by: Ayan Kumar Halder
---
Currently this change will not have any impact on the existing architectures.
The following table illustrates PADDR_BITS vs BITS_PER_LONG of different archs
| Arch | PADDR_BITS| BITS_PER_LONG |
| Arm_64| 48| 64|
| Arm_32| 40| 32|
| RISCV_64 | Don't know| 64|
| x86 | 52| 64|
-
However, this will change when we introduce a platform (For eg Cortex-R52) which
supports 32 bit physical address and BITS_PER_LONG. This platform does not
follow
the same code path as Arm_32.
Thus, I have introduced this change as I don't see it causing a regression on
any of the supported platforms.
Changes from v1:-
1. Changed the check from "(PADDR_BITS > BITS_PER_LONG)" to "((PADDR_BITS -
PAGE_SHIFT) >= BITS_PER_LONG)"
2. Updated the commit message to explain the reason for this.
v2 :-
1. Updated the commit message.
xen/common/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 62afb07bc6..c5b8c7444f 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2245,7 +2245,7 @@ void __init xenheap_max_mfn(unsigned long mfn)
{
ASSERT(!first_node_initialised);
ASSERT(!xenheap_bits);
-BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG);
+BUILD_BUG_ON((PADDR_BITS - PAGE_SHIFT) >= BITS_PER_LONG);
xenheap_bits = min(flsl(mfn + 1) - 1 + PAGE_SHIFT, PADDR_BITS);
printk(XENLOG_INFO "Xen heap: %u bits\n", xenheap_bits);
}
--
2.17.1
[xen-unstable-smoke test] 175022: tolerable all pass - PUSHED
flight 175022 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175022/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 133f35f0f0cd0a415e599c201565598356c0 baseline version: xen 1527066a7eaabcd18533135e81f9064e00b32428 Last test of basis 175019 2022-12-02 05:01:57 Z0 days Testing same since 175022 2022-12-02 10:00:30 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1527066a7e..133f35f0f0 133f35f0f0cd0a415e599c201565598356c0 -> smoke
Re: [XEN v3] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used as a rhs operand of shift operator
On 02/12/2022 12:35, Ayan Kumar Halder wrote: > Currently this change will not have any impact on the existing architectures. > The following table illustrates PADDR_BITS vs BITS_PER_LONG of different archs > > > | Arch | PADDR_BITS| BITS_PER_LONG | > > | Arm_64| 48| 64| > | Arm_32| 40| 32| > | RISCV_64 | Don't know| 64| Just FYI, I think the answer here is 56 for RISC-V. ~Andrew > | x86 | 52| 64| > - >
Re: [PATCH v2 2/4] tools/ocaml/libs/xc: add binding to xc_evtchn_status
> On 2 Dec 2022, at 10:55, Edwin Török wrote:
>
> There is no API or ioctl to query event channel status, it is only
> present in xenctrl.h
>
> The C union is mapped to an OCaml variant exposing just the value from the
> correct union tag.
>
> The information provided here is similar to 'lsevtchn', but rather than
> parsing its output it queries the underlying API directly.
>
> Signed-off-by: Edwin Török
Acked-by: Christian Lindig
> ---
> Changes since v1:
> * drop paragraph about where this is used
> * add comment about max port
> * use Xeneventchn.virq_t instead of int, add a dependency: xc -> eventchn
> * initialize struct without memset-ing first
> * use 2 CAMLreturn, I found an example in the OCaml stdlib that does that so
> should be future-proof
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Focaml%2Focaml%2Fblob%2F663e8d219f566095e3a9497c5bae07b6a95cae39%2Fotherlibs%2Funix%2Fdup_win32.c%23L52-L77&data=05%7C01%7Cchristian.lindig%40citrix.com%7C7d476fd71ea14746b08f08dad453d946%7C335836de42ef43a2b145348c2ee9ca5b%7C0%7C0%7C638055753844059822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c97tdCv0VPS7UBPoLJXf3geZKQq0AkhjWuA1wq2ZUW0%3D&reserved=0
> * use Tag_some, defining it if needed
> * fix typo on failwith
> ---
> tools/ocaml/libs/Makefile | 2 +-
> tools/ocaml/libs/xc/META.in | 2 +-
> tools/ocaml/libs/xc/Makefile| 2 +-
> tools/ocaml/libs/xc/xenctrl.ml | 15 +++
> tools/ocaml/libs/xc/xenctrl.mli | 15 +++
> tools/ocaml/libs/xc/xenctrl_stubs.c | 67 +
> 6 files changed, 100 insertions(+), 3 deletions(-)
>
> diff --git a/tools/ocaml/libs/Makefile b/tools/ocaml/libs/Makefile
> index 7e7c27e2d5..15f45a6d66 100644
> --- a/tools/ocaml/libs/Makefile
> +++ b/tools/ocaml/libs/Makefile
> @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
> SUBDIRS= \
> mmap \
> xentoollog \
> - xc eventchn \
> + eventchn xc\
> xb xs xl
>
> .PHONY: all
> diff --git a/tools/ocaml/libs/xc/META.in b/tools/ocaml/libs/xc/META.in
> index 2ff4dcb6bf..6a273936a3 100644
> --- a/tools/ocaml/libs/xc/META.in
> +++ b/tools/ocaml/libs/xc/META.in
> @@ -1,5 +1,5 @@
> version = "@VERSION@"
> description = "Xen Control Interface"
> -requires = "unix,xenmmap"
> +requires = "unix,xenmmap,xeneventchn"
> archive(byte) = "xenctrl.cma"
> archive(native) = "xenctrl.cmxa"
> diff --git a/tools/ocaml/libs/xc/Makefile b/tools/ocaml/libs/xc/Makefile
> index 3b76e9ad7b..1d9fecb06e 100644
> --- a/tools/ocaml/libs/xc/Makefile
> +++ b/tools/ocaml/libs/xc/Makefile
> @@ -4,7 +4,7 @@ include $(OCAML_TOPLEVEL)/common.make
>
> CFLAGS += -I../mmap $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> CFLAGS += $(APPEND_CFLAGS)
> -OCAMLINCLUDE += -I ../mmap
> +OCAMLINCLUDE += -I ../mmap -I ../eventchn
>
> OBJS = xenctrl
> INTF = xenctrl.cmi
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index 2ed7454b16..5dac47991e 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -267,6 +267,21 @@ external evtchn_alloc_unbound: handle -> domid -> domid
> -> int
> = "stub_xc_evtchn_alloc_unbound"
> external evtchn_reset: handle -> domid -> unit = "stub_xc_evtchn_reset"
>
> +(* FIFO has theoretical maximum of 2^28 ports, fits in an int *)
> +type evtchn_interdomain = { dom: domid; port: int}
> +
> +type evtchn_stat =
> + | EVTCHNSTAT_unbound of domid
> + | EVTCHNSTAT_interdomain of evtchn_interdomain
> + | EVTCHNSTAT_pirq of int
> + | EVTCHNSTAT_virq of Xeneventchn.virq_t
> + | EVTCHNSTAT_ipi
> +
> +type evtchn_status = { vcpu: int; status: evtchn_stat }
> +
> +external evtchn_status: handle -> domid -> int -> evtchn_status option =
> + "stub_xc_evtchn_status"
> +
> external readconsolering: handle -> string = "stub_xc_readconsolering"
>
> external send_debug_keys: handle -> string -> unit = "stub_xc_send_debug_keys"
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index 0f80aafea0..6c9206bc74 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -206,6 +206,21 @@ external shadow_allocation_get : handle -> domid -> int
> external evtchn_alloc_unbound : handle -> domid -> domid -> int
> = "stub_xc_evtchn_alloc_unbound"
> external evtchn_reset : handle -> domid -> unit = "stub_xc_evtchn_reset"
> +
> +type evtchn_interdomain = { dom: domid; port: int}
> +
> +type evtchn_stat =
> + | EVTCHNSTAT_unbound of domid
> + | EVTCHNSTAT_interdomain of evtchn_interdomain
> + | EVTCHNSTAT_pirq of int
> + | EVTCHNSTAT_virq of Xeneventchn.virq_t
> + | EVTCHNSTAT_ipi
> +
> +type evtchn_status = { vcpu: int; status: evtchn_stat }
> +
> +external evtchn_status: handle -> domid -> int -> evtchn_status option =
> + "stub_xc_evtchn_status"
> +
> external readconsolering : handle -> string = "stub_xc_readconsolering"
> external send_debug_keys : ha
Re: [PATCH 2/4] xen/scripts: add cppcheck tool to the xen-analysis.py script
> On 1 Dec 2022, at 20:23, Stefano Stabellini wrote:
>
> On Thu, 1 Dec 2022, Luca Fancellu wrote:
>> Hi Stefano,
>>
>
>
>> +sm_tool_args="n"
>> +;;
>> +--cppcheck-cmd=*)
>> +CPPCHECK_TOOL="$(eval echo "${OPTION#*=}")"
>> +sm_tool_args="y"
>> +;;
>> +--cppcheck-html)
>> +CPPCHECK_HTML="y"
>> +sm_tool_args="n"
>> +;;
>> +--cppcheck-plat=*)
>> +CPPCHECK_PLAT_PATH="$(eval echo "${OPTION#*=}")"
>> +sm_tool_args="n"
>> +;;
>> +--ignore-path=*)
>> +IGNORE_PATH_LIST="${IGNORE_PATH_LIST} $(eval echo
>> "${OPTION#*=}")"
>> +sm_tool_args="n"
>> +;;
>> +--)
>> +forward_to_cc="y"
>> +sm_tool_args="n"
>> +;;
>> +*)
>> +if [ "${sm_tool_args}" = "y" ]; then
>> +CPPCHECK_TOOL_ARGS="${CPPCHECK_TOOL_ARGS} ${OPTION}"
>> +else
>> +echo "Invalid option ${OPTION}"
>> +exit 1
>
> It doesn't look like sm_tool_args is really needed? It is only set to
> 'y' in the case of --cppcheck-cmd, and in that case we also set
> CPPCHECK_TOOL. CPPCHECK_TOOL is the variable used below. Am I missing
> something?
We use sm_tool_args to fill CPPCHECK_TOOL_ARGS, basically it’s a state
machine where
when we find --cppcheck-cmd= we expect that every other space
separated arguments
passed afterwards are the args for cppcheck, so we append to
CPPCHECK_TOOL_ARGS
until we find an argument that is supposed to be only for this script.
>>>
>>> That seems a bit unnecessary: if the user wants to pass arguments to
>>> cppcheck, the user would do --cppcheck-cmd="cppcheck arg1 arg2" with ""
>>> quotes. Doing that should make --cppcheck-cmd="cppcheck arg1 arg2" be
>>> seen as a single argument from this script point of view. CPPCHECK_TOOL
>>> would end up being set to "cppcheck arg1 arg2" which is what we want
>>> anyway? And if we need to distinguish between the cppcheck binary and
>>> its argument we could use "cut" to extract "cppcheck", "arg1", and
>>> "arg2" from CPPCHECK_TOOL. Would that work?
>>>
>>
>> I gave a try for the quotes, the problem is that we need to have quotes in
>> CC=“...”, so adding
>> quotes also to --cppcheck-cmd= which is inside CC=“...” is preventing the
>> Makefile to work,
>> I tried escaping etc but I didn’t manage to have it working, so would you
>> agree on keeping it
>> like that?
>
> Is the problem coming from the following?
>
>cppcheck_cc_flags = """--compiler={} --cppcheck-cmd={} {}
> --cppcheck-plat={}/cppcheck-plat --ignore-path=tools/
> """.format(xen_cc, settings.cppcheck_binpath, cppcheck_flags,
> settings.tools_dir)
>
>if settings.cppcheck_html:
>cppcheck_cc_flags = cppcheck_cc_flags + " --cppcheck-html"
>
># Generate the extra make argument to pass the cppcheck-cc.sh wrapper as CC
>cppcheck_extra_make_args = "CC=\"{}/cppcheck-cc.sh {} --\"".format(
>settings.tools_dir,
>cppcheck_cc_flags
>).replace("\n", "")
>
>
> Wouldn't something like the following solve the issue?
>
>settings.cppcheck_binpath = settings.cppcheck_binpath + " " +
> cppcheck_cc_flags
>
>cppcheck_cc_flags = """--compiler={} --cppcheck-cmd=\"{}\"
> --cppcheck-plat={}/cppcheck-plat --ignore-path=tools/
> """.format(xen_cc, settings.cppcheck_binpath, settings.tools_dir)
>
>if settings.cppcheck_html:
>cppcheck_cc_flags = cppcheck_cc_flags + " --cppcheck-html"
>
># Generate the extra make argument to pass the cppcheck-cc.sh wrapper as CC
>cppcheck_extra_make_args = "CC=\"{}/cppcheck-cc.sh {} --\"".format(
>settings.tools_dir,
>cppcheck_cc_flags
>).replace("\n", "")
No unfortunately not, Makefile is very sensitive to quotes, I’ve tried with
many combination of single/double quotes but nothing worked
Re: [XEN v3] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used as a rhs operand of shift operator
On 02.12.2022 13:35, Ayan Kumar Halder wrote: > We want to ensure that "xenheap_bits - PAGE_SHIFT" is strictly less than > the number of bits to represent unsigned long as it is used a rhs operand > to shift mfn. > It is also important to note that the "xenheap_bits - PAGE_SHIFT" is never > used to shift an address (rather than a frame number), and going forward > then also shouldn't be (perhaps unless further precautions are taken). Hmm, now you've lost why you are making the change in the first place: The way things are before the patch is quite fine for the described purpose. (This then also extends to the title. I should have noticed this in v2 already, but didn't because I still had the v1 title in mind.) Furthermore in the 2nd paragraph instead of 'the "xenheap_bits - PAGE_SHIFT"' you mean '"xenheap_bits" alone'. Jan
Re: [XEN v3] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used as a rhs operand of shift operator
Hi, On 02/12/2022 13:43, Jan Beulich wrote: On 02.12.2022 13:35, Ayan Kumar Halder wrote: We want to ensure that "xenheap_bits - PAGE_SHIFT" is strictly less than the number of bits to represent unsigned long as it is used a rhs operand to shift mfn. It is also important to note that the "xenheap_bits - PAGE_SHIFT" is never used to shift an address (rather than a frame number), and going forward then also shouldn't be (perhaps unless further precautions are taken). Hmm, now you've lost why you are making the change in the first place: The way things are before the patch is quite fine for the described purpose. (This then also extends to the title. I should have noticed this in v2 already, but didn't because I still had the v1 title in mind.) Furthermore in the 2nd paragraph instead of 'the "xenheap_bits - PAGE_SHIFT"' you mean '"xenheap_bits" alone'. Let me propose a commit message: " xen/page_alloc: Relax the BUILD_BUG_ON() in xenheap_max_mfn() In the near future, we are considering to use a common xen/domain heap for Arm 32-bit V8-R. In this setup, both PADDR_BITS and BITS_PER_LONG will be 32. Therefore, the condition PADDR_BITS >= BITS_PER_LONG will become true. Looking at the commit that introduce the BUILD_BUG_ON (88e3ed61642b "x86/NUMA: make init_node_heap() respect Xen heap limit") and the current use, it seems this check was mainly to ensure that the shift of xenheap_bits is not going to be undefined (>> N for a N-bit type is undefined). So far, all the shifts are using "xenheap_bits - PAGE_SHIFT". Therefore, the existing code should work for 32-bit architecture as long as the result of the substraction is below 32. Therefore relax the BUILD_BUG_ON() to check that (PADDR_BITS - PAGE_SHIFT) is not equal of above BITS_PER_LONG. Note that we would need further precaution if we ended up to use 'xenheap_bits' alone in shifts. " If you end up to take my commit message, then please add my signed-off-by. Cheers, -- Julien Grall
[xen-4.17-testing test] 175015: tolerable FAIL - PUSHED
flight 175015 xen-4.17-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/175015/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175007 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175007 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175007 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175007 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175007 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175007 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175007 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175007 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175007 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175007 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175007 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175007 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen 942f881eb1b4e90cbd2096e88551750092d2eaaa baseline version: xen 345135942bf9
Release checklist and qemu-xen-traditional
(Adding xen-devel to the CC list.) Hi, Henry. Pleaed to "meet" you. To answer your questions: > > > (1) Why do the instructions say to branch that repo? > > > (2) Where can we find this repo? > > > (3) Is this repo used anywhere since the 4.16 release? > > > (4) Is this repo used elsewhere in the release process? This repo is this one. I think it is still used during some builds. See this line in Config.mk: QEMU_TRADITIONAL_URL ?= http://xenbits.xen.org/git-http/qemu-xen-traditional.git It is very old and we have been slowly deprecating it. (The copy on my workstation was called qemu-iwj.git for historical reasons which aren't relevant, but that's how that got into the checklist.) The release checklist will also instruct the release technician to update the pinning in Config.mk to the tag. For example, Config.mk in RELEASE-4.16.0 says this: QEMU_TRADITIONAL_REVISION ?= xen-4.16.0 This needs to be updated so that people who get 4.16 don't get any changes that are made to the "master" branch in qemu-xen-traditional. The same will be true for 4.17, if it qemu-xen-traditional hasn't been completely abolished there yet. > > These instructons relate to my local clone of qemu-xen-traditional, > > and will need adjustment. > > Thanks for your reply! It would be good for you to clarify what adjustments > we need to do. That said, I completely understand that you are quite busy > today, so... A clone of qemu-xen-traditional ought to do for this. My tree here, rescued from my old Citrix workstation, has this for the "origin" remote: xenbits.xen.org:/home/xen/git/qemu-xen-traditional.git I hope this is helpful. If you want to talk through it some more, ping me on irc. I'm Diziet on oftc. I usually lurk on #xendevel (although I fell off at some point and only just rejoined), or you may send me a private message. Regards, Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: [RFC PATCH 15/21] xen/arm: vsmmuv3: Emulated SMMUv3 device tree node for dom0less
Hi Rahul, On 01/12/2022 17:02, Rahul Singh wrote: > > > XEN will create an Emulated SMMUv3 device tree node in the device tree > to enable the dom0less domains to discover the virtual SMMUv3 during > boot. Emulated SMMUv3 device tree node will only be created when cmdline > option vsmmuv3 is enabled. I think you meant viommu option. In any case, I think that you want to introduce a device-tree property for dom0less domU e.g. string property viommu = "smmuv3" to control whether to add a virtual IOMMU node or not for a given domU. You did exactly the same for xl created domUs so you should do the same for dom0less domUs. Otherwise the behavior will be inconsistent and we will lack per-domain control over virtual IOMMU. ~Michal
RE: Release checklist and qemu-xen-traditional
Hi Ian, > -Original Message- > From: Ian Jackson > Subject: Release checklist and qemu-xen-traditional > > (Adding xen-devel to the CC list.) Thank you for doing this, it would be great to have the answer below logged in the mailing list. > > Hi, Henry. Pleased to "meet" you. To answer your questions: > > > > > (1) Why do the instructions say to branch that repo? > > > > (2) Where can we find this repo? > > > > (3) Is this repo used anywhere since the 4.16 release? > > > > (4) Is this repo used elsewhere in the release process? > > This repo is this one. I think it is still used during some builds. > See this line in Config.mk: > > QEMU_TRADITIONAL_URL ?= http://xenbits.xen.org/git-http/qemu-xen- > traditional.git > > It is very old and we have been slowly deprecating it. (The copy on > my workstation was called qemu-iwj.git for historical reasons which > aren't relevant, but that's how that got into the checklist.) > > The release checklist will also instruct the release technician to > update the pinning in Config.mk to the tag. For example, Config.mk in > RELEASE-4.16.0 says this: > > QEMU_TRADITIONAL_REVISION ?= xen-4.16.0 > > This needs to be updated so that people who get 4.16 don't get any > changes that are made to the "master" branch in qemu-xen-traditional. > The same will be true for 4.17, if it qemu-xen-traditional hasn't > been completely abolished there yet. Great thanks for your detailed explanation! I checked yesterday's branching commit done by Julien [1] and seeing the qemu-xen-traditional tags [2] and qemu-xen tags [3], I think Julien did everything correctly (Thanks Julien!) :) Although I am wondering if the instruction about qemu-iwj.git here: ``` * make branch in qemu-iwj.git git-branch $v-testing master ``` would be duplicated with instructions here: ``` # make branches in xenbits.xen.org qemus ssh x...@xenbits.xen.org cd ~/git/qemu-xen.git git branch staging-$v staging git branch stable-$v master cd ~/git/qemu-xen-traditional.git git branch stable-$v master ``` [1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=f51079b5d87b39e79fe499ed818d50d856bc9c35 [2] https://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=summary [3] https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary Kind regards, Henry > > > > These instructons relate to my local clone of qemu-xen-traditional, > > > and will need adjustment. > > > > Thanks for your reply! It would be good for you to clarify what adjustments > > we need to do. That said, I completely understand that you are quite busy > > today, so... > > A clone of qemu-xen-traditional ought to do for this. My tree here, > rescued from my old Citrix workstation, has this for the "origin" > remote: > xenbits.xen.org:/home/xen/git/qemu-xen-traditional.git > > I hope this is helpful. If you want to talk through it some more, > ping me on irc. I'm Diziet on oftc. I usually lurk on #xendevel > (although I fell off at some point and only just rejoined), or you > may send me a private message. > > Regards, > Ian. > > -- > Ian JacksonThese opinions are my own. > > Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, > that is a private address which bypasses my fierce spamfilter.
Re: [RFC PATCH 21/21] xen/arm: vIOMMU: Modify the partial device tree for dom0less
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> To configure IOMMU in guest for passthrough devices, user will need to
> copy the unmodified "iommus" property from host device tree to partial
> device tree. To enable the dom0 linux kernel to confiure the IOMMU
> correctly replace the phandle in partial device tree with virtual
> IOMMU phandle when "iommus" property is set.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/arm/domain_build.c | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7cd99a6771..afb3e76409 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -3235,7 +3235,35 @@ static int __init handle_prop_pfdt(struct kernel_info
> *kinfo,
> return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
> }
>
> -static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
> +static void modify_pfdt_node(void *pfdt, int nodeoff)
> +{
> +int proplen, i, rc;
> +const fdt32_t *prop;
> +fdt32_t *prop_c;
> +
> +prop = fdt_getprop(pfdt, nodeoff, "iommus", &proplen);
> +if ( !prop )
> +return;
> +
> +prop_c = xzalloc_bytes(proplen);
> +
> +for ( i = 0; i < proplen / 8; ++i )
> +{
> +prop_c[i * 2] = cpu_to_fdt32(GUEST_PHANDLE_VSMMUV3);
> +prop_c[i * 2 + 1] = prop[i * 2 + 1];
> +}
> +
> +rc = fdt_setprop(pfdt, nodeoff, "iommus", prop_c, proplen);
> +if ( rc )
> +{
> +dprintk(XENLOG_ERR, "Can't set the iommus property in partial FDT");
> +return;
> +}
> +
> +return;
> +}
> +
> +static int __init scan_pfdt_node(struct kernel_info *kinfo, void *pfdt,
> int nodeoff,
> uint32_t address_cells, uint32_t size_cells,
> bool scan_passthrough_prop)
> @@ -3261,6 +3289,7 @@ static int __init scan_pfdt_node(struct kernel_info
> *kinfo, const void *pfdt,
> node_next = fdt_first_subnode(pfdt, nodeoff);
> while ( node_next > 0 )
> {
> +modify_pfdt_node(pfdt, node_next);
You do not protect this call in any way and there is no check inside it whether
viommu is enabled or not.
This means that even with viommu disabled, if a user copies the iommus property
to partial dtb
(which is understandable as the flow is to copy almost everything), you will
perform the phandle replacement.
I do not think we should do that (no need for an extra code).
> scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
> scan_passthrough_prop);
> node_next = fdt_next_subnode(pfdt, node_next);
> --
> 2.25.1
>
>
~Michal
Re: [QEMU][PATCH v2 10/11] hw/arm: introduce xenpv machine
Vikram Garhwal writes:
> Add a new machine xenpv which creates a IOREQ server to register/connect with
> Xen Hypervisor.
>
> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
> TPM emulator and connects to swtpm running on host machine via chardev socket
> and support TPM functionalities for a guest domain.
>
> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>
> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
> provides access to TPM functionality over socket, chardev and CUSE interface.
> Github repo: https://github.com/stefanberger/swtpm
> Example for starting swtpm on host machine:
> mkdir /tmp/vtpm2
> swtpm socket --tpmstate dir=/tmp/vtpm2 \
> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
>
> /* Comment about machine name. Will be removed in next version*/
> Please reply with the machine name you agree. Below are two possible names:
> 1. xenpv
> 2. xenpvh
>
> Signed-off-by: Vikram Garhwal
> Signed-off-by: Stefano Stabellini
> ---
> hw/arm/meson.build| 2 +
> hw/arm/xen_arm.c | 175 ++
> include/hw/arm/xen_arch_hvm.h | 9 ++
> include/hw/xen/arch_hvm.h | 2 +
> 4 files changed, 188 insertions(+)
> create mode 100644 hw/arm/xen_arm.c
> create mode 100644 include/hw/arm/xen_arch_hvm.h
>
> diff --git a/hw/arm/meson.build b/hw/arm/meson.build
> index 92f9f6e000..0cae024374 100644
> --- a/hw/arm/meson.build
> +++ b/hw/arm/meson.build
> @@ -62,5 +62,7 @@ arm_ss.add(when: 'CONFIG_FSL_IMX7', if_true:
> files('fsl-imx7.c', 'mcimx7d-sabre.
> arm_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true: files('smmu-common.c',
> 'smmuv3.c'))
> arm_ss.add(when: 'CONFIG_FSL_IMX6UL', if_true: files('fsl-imx6ul.c',
> 'mcimx6ul-evk.c'))
> arm_ss.add(when: 'CONFIG_NRF51_SOC', if_true: files('nrf51_soc.c'))
> +arm_ss.add(when: 'CONFIG_XEN', if_true: files('xen_arm.c'))
> +arm_ss.add_all(xen_ss)
>
> hw_arch += {'arm': arm_ss}
> diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
> new file mode 100644
> index 00..bcb8e95f2c
> --- /dev/null
> +++ b/hw/arm/xen_arm.c
> @@ -0,0 +1,175 @@
> +/*
> + * QEMU ARM Xen PV Machine
> + *
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/error-report.h"
> +#include "qapi/qapi-commands-migration.h"
> +#include "hw/boards.h"
> +#include "hw/sysbus.h"
> +#include "sysemu/block-backend.h"
> +#include "sysemu/tpm_backend.h"
> +#include "sysemu/sysemu.h"
> +#include "hw/xen/xen-legacy-backend.h"
> +#include "hw/xen/xen-hvm-common.h"
> +#include "sysemu/tpm.h"
> +#include "hw/xen/arch_hvm.h"
> +
> +#define TYPE_XEN_ARM MACHINE_TYPE_NAME("xenpv")
> +OBJECT_DECLARE_SIMPLE_TYPE(XenArmState, XEN_ARM)
> +
> +static MemoryListener xen_memory_listener = {
> +.region_add = xen_region_add,
> +.region_del = xen_region_del,
> +.log_start = NULL,
> +.log_stop = NULL,
> +.log_sync = NULL,
> +.log_global_start = NULL,
> +.log_global_stop = NULL,
> +.priority = 10,
> +};
> +
> +struct XenArmState {
> +/*< private >*/
> +MachineState parent;
> +
> +XenIOState *state;
> +};
> +
> +void arch_handle_ioreq(XenIOState *state, ioreq_t *req)
> +{
> +hw_error("Invalid ioreq type 0x%x\n", req->type);
> +
> +return;
> +}
> +
> +void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section,
> + bool add)
> +{
> +}
> +
> +void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
> +{
> +}
> +
> +void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
> +{
> +}
> +
This function is only used under CONFIG_TPM so without it you get:
../../hw/arm/xen_arm.c:78:12: error: ‘xen_init_ioreq’ defined but not used
[-Werror=unused-fun
Re: [PATCH V6 1/3] libxl: Add support for generic virtio device
On 08.11.22 13:23, Viresh Kumar wrote:
Hello Viresh
[sorry for the possible format issues if any]
This patch adds basic support for configuring and assisting generic
Virtio backend which could run in any domain.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
Also to make this work on Arm, allocate Virtio MMIO params (IRQ and
memory region) and pass them to the backend. Update guest device-tree as
well to create a DT node for the Virtio devices.
Some NITs regarding the commit description:
1. Besides making generic things current patch also adds i2c/gpio device
nodes, I would mention that in the description.
2. I assume current patch is not enough to make this work on Arm, at
least the subsequent patch is needed, I would mention that as well.
3. I understand where "virtio,device22"/"virtio,device29" came from, but
I think that links to the corresponding device-tree bindings should be
mentioned here (and/or maybe in the code).
Signed-off-by: Viresh Kumar
---
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_arm.c | 89 +++
tools/libs/light/libxl_create.c | 5 +
tools/libs/light/libxl_internal.h | 1 +
tools/libs/light/libxl_types.idl | 29 +
tools/libs/light/libxl_types_internal.idl | 1 +
tools/libs/light/libxl_virtio.c | 127 ++
7 files changed, 253 insertions(+)
create mode 100644 tools/libs/light/libxl_virtio.c
diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
index 374be1cfab25..4fddcc6f51d7 100644
--- a/tools/libs/light/Makefile
+++ b/tools/libs/light/Makefile
@@ -106,6 +106,7 @@ OBJS-y += libxl_vdispl.o
OBJS-y += libxl_pvcalls.o
OBJS-y += libxl_vsnd.o
OBJS-y += libxl_vkb.o
+OBJS-y += libxl_virtio.o
OBJS-y += libxl_genid.o
OBJS-y += _libxl_types.o
OBJS-y += libxl_flask.o
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index b4928dbf673c..f33c9b273a4f 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -113,6 +113,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
}
}
+for (i = 0; i < d_config->num_virtios; i++) {
+libxl_device_virtio *virtio = &d_config->virtios[i];
+
+if (virtio->transport != LIBXL_VIRTIO_TRANSPORT_MMIO)
+continue;
+
+rc = alloc_virtio_mmio_params(gc, &virtio->base, &virtio->irq,
+ &virtio_mmio_base, &virtio_mmio_irq);
+
+if (rc)
+return rc;
+}
+
/*
* Every virtio-mmio device uses one emulated SPI. If Virtio devices are
* present, make sure that we allocate enough SPIs for them.
@@ -968,6 +981,68 @@ static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
uint64_t base,
return fdt_end_node(fdt);
}
+static int make_virtio_mmio_node_i2c(libxl__gc *gc, void *fdt)
+{
+int res;
+
+res = fdt_begin_node(fdt, "i2c");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "virtio,device22");
+if (res) return res;
+
+return fdt_end_node(fdt);
+}
+
+static int make_virtio_mmio_node_gpio(libxl__gc *gc, void *fdt)
+{
+int res;
+
+res = fdt_begin_node(fdt, "gpio");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "virtio,device29");
+if (res) return res;
+
+res = fdt_property(fdt, "gpio-controller", NULL, 0);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#gpio-cells", 2);
+if (res) return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 2);
+if (res) return res;
+
+return fdt_end_node(fdt);
+}
+
+static int make_virtio_mmio_node_device(libxl__gc *gc, void *fdt, uint64_t
base,
+uint32_t irq, const char *type,
+uint32_t backend_domid)
+{
+int res, len = strlen(type);
+
+res = make_virtio_mmio_node_common(gc, fdt, base, irq, backend_domid);
+if (res) return res;
+
+/* Add device specific nodes */
+if (!strncmp(type, "virtio,device22", len)) {
+res = make_virtio_mmio_node_i2c(gc, fdt);
+if (res) return res;
+} else if (!strncmp(type, "virtio,device29", len)) {
+res = make_virtio_mmio_node_gpio(gc, fdt);
+if (res) return res;
+} else {
+LOG(ERROR, "Invalid type for virtio device: %s", type);
+return -EINVAL;
+}
I am not sure whether it is the best place to ask, but I will try
anyway. So I assume that with the whole series applied it would be
possible to configure only two specific device types ("22" and "29").
But what to do if user, for example, is interested in usual virtio
device (which doesn't require specific device-tree sub node with
specific compatible in it). For thes
Re: [QEMU][PATCH v2 10/11] hw/arm: introduce xenpv machine
Vikram Garhwal writes:
> Add a new machine xenpv which creates a IOREQ server to register/connect with
> Xen Hypervisor.
>
> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
> TPM emulator and connects to swtpm running on host machine via chardev socket
> and support TPM functionalities for a guest domain.
>
> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>
> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
> provides access to TPM functionality over socket, chardev and CUSE interface.
> Github repo: https://github.com/stefanberger/swtpm
> Example for starting swtpm on host machine:
> mkdir /tmp/vtpm2
> swtpm socket --tpmstate dir=/tmp/vtpm2 \
> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
> +
> +static void xen_enable_tpm(void)
> +{
> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
> +#ifdef CONFIG_TPM
> +Error *errp = NULL;
> +DeviceState *dev;
> +SysBusDevice *busdev;
> +
> +TPMBackend *be = qemu_find_tpm_be("tpm0");
> +if (be == NULL) {
> +DPRINTF("Couldn't fine the backend for tpm0\n");
> +return;
> +}
> +dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
> +object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
> +object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
> +busdev = SYS_BUS_DEVICE(dev);
> +sysbus_realize_and_unref(busdev, &error_fatal);
> +sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
Still fails on my aarch64 Debian machine:
FAILED: libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o
cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I../.. -Itarget/arm -I../../target/arm
-Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/local/include
-I/usr/include/capstone -I/usr/include/spice-server -I/usr/include/spice-1
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include
-fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem
/home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote . -iquote
/home/alex/lsrc/qemu.git -iquote /home/alex/lsrc/qemu.git/include -iquote
/home/alex/lsrc/qemu.git/tcg/aarch64 -pthread -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2
-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi
-fstack-protector-strong -fPIE -isystem../../linux-headers
-isystemlinux-headers -DNEED_CPU_H
'-DCONFIG_TARGET="aarch64-softmmu-config-target.h"'
'-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ
libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -MF
libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o.d -o
libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -c ../../hw/arm/xen_arm.c
../../hw/arm/xen_arm.c: In function ‘xen_enable_tpm’:
../../hw/arm/xen_arm.c:126:32: error: ‘GUEST_TPM_BASE’ undeclared (first use
in this function); did you mean ‘GUEST_RAM_BASE’?
126 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
|^~
|GUEST_RAM_BASE
../../hw/arm/xen_arm.c:126:32: note: each undeclared identifier is reported
only once for each function it appears in
[2082/3246] Compiling C object
libqemu-aarch64-softmmu.fa.p/hw_xen_xen-mapcache.c.o
[2083/3246] Compiling C object
libqemu-aarch64-softmmu.fa.p/hw_xen_xen-hvm-common.c.o
ninja: build stopped: subcommand failed.
make: *** [Makefile:165: run-ninja] Error 1
> +
> +DPRINTF("Connected tpmdev at address 0x%lx\n", GUEST_TPM_BASE);
> +#endif
> +}
If there is a minimum required version for TPM then it needs to be
picked up by configure.
--
Alex Bennée
Re: [QEMU][PATCH v2 00/11] Introduce xenpv machine for arm architecture
Vikram Garhwal writes:
> Hi,
> This series add xenpv machine for aarch64. Motivation behind creating xenpv
> machine with IOREQ and TPM was to enable each guest on Xen aarch64 to have
> it's
> own unique and emulated TPM.
>
> This series does following:
> 1. Moved common xen functionalities from hw/i386/xen to hw/xen/ so those
> can
>be used for aarch64.
> 2. We added a minimal xenpv arm machine which creates an IOREQ server and
>support TPM.
So I've managed to test the basics:
16:02:33 [root@latte:~] # xl create simple-guest.conf
Parsing config from simple-guest.conf
libxl: info: libxl_create.c:120:libxl__domain_build_info_setdefault: qemu-xen
is unavailable, using qemu-xen-traditional instead: No such file or directory
16:02:43 [root@latte:~] # xl list
NameID Mem VCPUs State
Time(s)
Domain-0 0 4096 4 r-
25.6
xenpv-test-guest 2 4095 2 r-
14.9
16:02:51 [root@latte:~] # ps ax | grep qemu
578 ?Sl 0:00
/home/alex/lsrc/qemu.git/builds/xen/qemu-system-aarch64 -xen-domid 0
-xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null
-serial /dev/null -parallel /dev/null -pidfile /var/run/xen/qemu-dom0.pid
2053 pts/2S+ 0:00 grep --color=auto qemu
However I'm a little lost on how to add HW to this machine. Is it all
via the guest configuration?
I think it would be worthwhile adding some documentation for this
machine to the manual, maybe docs/system/xen/xenpv.rst and then it can
be linked to from the appropriate target-arm.rst.
>
> Also, checkpatch.pl fails for 03/12 and 06/12. These fails are due to
> moving old code to new place which was not QEMU code style compatible.
> No new add code was added.
>
> Regards,
> Vikram
>
> ChangeLog:
> v1 -> v2
> Merged patch 05 and 06.
> 04/12: xen-hvm-common.c:
> 1. Moved xen_be_init() and xen_be_register_common() from
> xen_register_ioreq() to xen_register_backend().
> 2. Changed g_malloc to g_new and perror -> error_setg_errno.
> 3. Created a local subroutine function for Xen_IOREQ_register.
> 4. Fixed build issues with inclusion of xenstore.h.
> 5. Fixed minor errors.
>
> Stefano Stabellini (5):
> hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState
> xen-hvm: reorganize xen-hvm and move common function to xen-hvm-common
> include/hw/xen/xen_common: return error from xen_create_ioreq_server
> hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration
> failure
> meson.build: do not set have_xen_pci_passthrough for aarch64 targets
>
> Vikram Garhwal (6):
> hw/i386/xen/: move xen-mapcache.c to hw/xen/
> hw/i386/xen: rearrange xen_hvm_init_pc
> hw/xen/xen-hvm-common: Use g_new and error_setg_errno
> accel/xen/xen-all: export xenstore_record_dm_state
> hw/arm: introduce xenpv machine
> meson.build: enable xenpv machine build for ARM
>
> accel/xen/xen-all.c |2 +-
> hw/arm/meson.build |2 +
> hw/arm/xen_arm.c | 175 +
> hw/i386/meson.build |1 +
> hw/i386/xen/meson.build |1 -
> hw/i386/xen/trace-events | 19 -
> hw/i386/xen/xen-hvm.c| 1084 +++---
> hw/xen/meson.build |7 +
> hw/xen/trace-events | 19 +
> hw/xen/xen-hvm-common.c | 888
> hw/{i386 => }/xen/xen-mapcache.c |0
> include/hw/arm/xen_arch_hvm.h|9 +
> include/hw/i386/xen_arch_hvm.h | 11 +
> include/hw/xen/arch_hvm.h|5 +
> include/hw/xen/xen-hvm-common.h | 98 +++
> include/hw/xen/xen.h |2 +
> include/hw/xen/xen_common.h | 13 +-
> meson.build |4 +-
> 18 files changed, 1323 insertions(+), 1017 deletions(-)
> create mode 100644 hw/arm/xen_arm.c
> create mode 100644 hw/xen/xen-hvm-common.c
> rename hw/{i386 => }/xen/xen-mapcache.c (100%)
> create mode 100644 include/hw/arm/xen_arch_hvm.h
> create mode 100644 include/hw/i386/xen_arch_hvm.h
> create mode 100644 include/hw/xen/arch_hvm.h
> create mode 100644 include/hw/xen/xen-hvm-common.h
--
Alex Bennée
[libvirt test] 175018: tolerable all pass - PUSHED
flight 175018 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/175018/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175002 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175002 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175002 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: libvirt 522ffd2e969ddf52755efc5bb3e20229315efbc4 baseline version: libvirt 93b9e6503e13cb6243d3af55ae4b304397f40d74 Last test of basis 175002 2022-12-01 04:20:55 Z1 days Testing same since 175018 2022-12-02 04:20:12 Z0 days1 attempts People who touched revisions under test: Jim Fehlig Jiri Denemark Kristina Hanicova Michal Privoznik jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanati
Re: [PATCH 1/3] acpi/processor: fix evaluating _PDC method when running as Xen dom0
On 12/2/22 04:24, Roger Pau Monné wrote: > On the implementation side, is the proposed approach acceptable? > Mostly asking because it adds Xen conditionals to otherwise generic > ACPI code. That's a good Rafael question. But, how do other places in the ACPI code handle things like this?
RE: Release checklist and qemu-xen-traditional
Henry Wang writes ("RE: Release checklist and qemu-xen-traditional"):
> Although I am wondering if the instruction about qemu-iwj.git here:
> ```
> * make branch in qemu-iwj.git
> git-branch $v-testing master
> ```
>
> would be duplicated with instructions here:
> ```
> # make branches in xenbits.xen.org qemus
> ssh x...@xenbits.xen.org
> cd ~/git/qemu-xen.git
> git branch staging-$v staging
> git branch stable-$v master
> cd ~/git/qemu-xen-traditional.git
> git branch stable-$v master
> ```
I confess I answered without looking at the instructions again myself.
I think you are right, and that branch instruction may be a duplicate.
Later, when it comes to tagging, you'll probably want to have a local
staging-$v branch in your working tree, so that the tag is in the
right place.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Re: [PATCH 1/3] acpi/processor: fix evaluating _PDC method when running as Xen dom0
On Fri, Dec 02, 2022 at 08:17:56AM -0800, Dave Hansen wrote: > On 12/2/22 04:24, Roger Pau Monné wrote: > > On the implementation side, is the proposed approach acceptable? > > Mostly asking because it adds Xen conditionals to otherwise generic > > ACPI code. > > That's a good Rafael question. > > But, how do other places in the ACPI code handle things like this? Hm, I don't know of other places in the Xen case, the only resource in ACPI AML tables managed by Xen are Processor objects/devices AFAIK. The rest of devices are fully managed by the dom0 guest. I think such special handling is very specific to Xen, but maybe I'm wrong and there are similar existing cases in ACPI code already. We could add some kind of hook (iow: a function pointer in some struct that could be filled on a implementation basis?) but I didn't want overengineering this if adding a conditional was deemed OK. Thanks, Roger.
[xen-unstable-smoke test] 175024: tolerable all pass - PUSHED
flight 175024 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175024/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 10acd21795a9df5c0908c58104e82472c5fa2d17 baseline version: xen 133f35f0f0cd0a415e599c201565598356c0 Last test of basis 175022 2022-12-02 10:00:30 Z0 days Testing same since 175024 2022-12-02 14:07:16 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Christian Lindig Edwin Török jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 133f35f0f0..10acd21795 10acd21795a9df5c0908c58104e82472c5fa2d17 -> smoke
Re: [PATCH 1/3] acpi/processor: fix evaluating _PDC method when running as Xen dom0
On Fri, Dec 2, 2022 at 5:37 PM Roger Pau Monné wrote: > > On Fri, Dec 02, 2022 at 08:17:56AM -0800, Dave Hansen wrote: > > On 12/2/22 04:24, Roger Pau Monné wrote: > > > On the implementation side, is the proposed approach acceptable? > > > Mostly asking because it adds Xen conditionals to otherwise generic > > > ACPI code. > > > > That's a good Rafael question. Sorry for joining late, but first off _PDC has been deprecated since ACPI 3.0 (2004) and it is not even present in ACPI 6.5 any more. It follows from your description that _PDC is still used in the field, though, after 18 years of deprecation. Who uses it, if I may know? > > But, how do other places in the ACPI code handle things like this? > > Hm, I don't know of other places in the Xen case, the only resource > in ACPI AML tables managed by Xen are Processor objects/devices AFAIK. > The rest of devices are fully managed by the dom0 guest. > > I think such special handling is very specific to Xen, but maybe I'm > wrong and there are similar existing cases in ACPI code already. > > We could add some kind of hook (iow: a function pointer in some struct > that could be filled on a implementation basis?) but I didn't want > overengineering this if adding a conditional was deemed OK. What _PDC capabilities specifically do you need to pass to the firmware for things to work correctly? What platforms are affected?
Re: [PATCH V6 2/3] xl: Add support to parse generic virtio device
On 08.11.22 13:23, Viresh Kumar wrote:
Hello Viresh
[sorry for the possible format issues if any]
This patch adds basic support for parsing generic Virtio backend.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
Signed-off-by: Viresh Kumar
---
tools/ocaml/libs/xl/genwrap.py | 1 +
tools/ocaml/libs/xl/xenlight_stubs.c | 1 +
tools/xl/xl_parse.c | 84
3 files changed, 86 insertions(+)
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 7bf26bdcd831..b188104299b1 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -36,6 +36,7 @@ DEVICE_LIST = [ ("list", ["ctx", "domid", "t
list"]),
functions = { # ( name , [type1,type2,] )
"device_vfb": DEVICE_FUNCTIONS,
"device_vkb": DEVICE_FUNCTIONS,
+"device_virtio": DEVICE_FUNCTIONS,
"device_disk":DEVICE_FUNCTIONS + DEVICE_LIST +
[ ("insert", ["ctx", "t", "domid", "?async:'a", "unit",
"unit"]),
("of_vdev",["ctx", "domid", "string", "t"]),
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c
b/tools/ocaml/libs/xl/xenlight_stubs.c
index 45b8af61c74a..8e54f95da7c7 100644
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -707,6 +707,7 @@ DEVICE_ADDREMOVE(disk)
DEVICE_ADDREMOVE(nic)
DEVICE_ADDREMOVE(vfb)
DEVICE_ADDREMOVE(vkb)
+DEVICE_ADDREMOVE(virtio)
DEVICE_ADDREMOVE(pci)
_DEVICE_ADDREMOVE(disk, cdrom, insert)
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 1b5381cef033..c6f35c069d2a 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1208,6 +1208,87 @@ static void parse_vkb_list(const XLU_Config *config,
if (rc) exit(EXIT_FAILURE);
}
+static int parse_virtio_config(libxl_device_virtio *virtio, char *token)
+{
+char *oparg;
+int rc;
+
+if (MATCH_OPTION("backend", token, oparg)) {
+virtio->backend_domname = strdup(oparg);
+} else if (MATCH_OPTION("type", token, oparg)) {
+virtio->type = strdup(oparg);
+} else if (MATCH_OPTION("transport", token, oparg)) {
+rc = libxl_virtio_transport_from_string(oparg, &virtio->transport);
+if (rc) return rc;
+} else if (MATCH_OPTION("irq", token, oparg)) {
+virtio->irq = strtoul(oparg, NULL, 0);
+} else if (MATCH_OPTION("base", token, oparg)) {
+virtio->base = strtoul(oparg, NULL, 0);
Interesting, I see you allow user to configure virtio-mmio params (irq
and base), as far as I remember for virtio-disk these are internal only
(allocated by tools/libs/light/libxl_arm.c).
I am not really sure why we need to configure virtio "base", could you
please clarify? But if we really want/need to be able to configure
virtio "irq" (for example to avoid possible clashing with physical one),
I am afraid, this will require more changes that current patch does.
Within current series saving virtio->irq here doesn't have any effect as
it will be overwritten in
libxl__arch_domain_prepare_config()->alloc_virtio_mmio_params() anyway.
I presume the code in libxl__arch_domain_prepare_config() shouldn't try
to allocate virtio->irq if it is already configured by user, also the
allocator should probably take into the account of what is already
configured by user, to avoid allocating the same irq for another device
assigned for the same guest.
Also doc change in the subsequent patch doesn't mention about irq/base
configuration.
So maybe we should just drop for now?
+} else if (MATCH_OPTION("irq", token, oparg)) {
+virtio->irq = strtoul(oparg, NULL, 0);
+} else if (MATCH_OPTION("base", token, oparg)) {
+virtio->base = strtoul(oparg, NULL, 0);
+} else {
+fprintf(stderr, "Unknown string \"%s\" in virtio spec\n", token);
+return -1;
+}
+
+return 0;
+}
+
+static void parse_virtio_list(const XLU_Config *config,
+ libxl_domain_config *d_config)
+{
+XLU_ConfigList *virtios;
+const char *item;
+char *buf = NULL, *oparg, *str = NULL;
+int rc;
+
+if (!xlu_cfg_get_list (config, "virtio", &virtios, 0, 0)) {
+int entry = 0;
+while ((item = xlu_cfg_get_listitem(virtios, entry)) != NULL) {
+libxl_device_virtio *virtio;
+char *p;
+
+virtio = ARRAY_EXTEND_INIT(d_config->virtios,
d_config->num_virtios,
+ libxl_device_virtio_init);
+
+buf = strdup(item);
+
+p = strtok(buf, ",");
+while (p != NULL)
+{
+while (*p == ' ') p++;
+
+// Type may contain a comma, do special handling.
+if (MATCH_OPTION("type", p, oparg)) {
+if (!strncmp(oparg, "virtio", strlen("virtio"))) {
+
Re: [PATCH v8 2/3] freezer: refactor pm_freezing into a function.
On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda wrote:
>
> Add a way to let the drivers know if the processes are frozen.
>
> This is needed by drivers that are waiting for processes to end on their
> shutdown path.
>
> Convert pm_freezing into a function and export it, so it can be used by
> drivers that are either built-in or modules.
>
> Cc: sta...@vger.kernel.org
> Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> in .shutdown")
> Signed-off-by: Ricardo Ribalda
Why can't you export the original pm_freezing variable and why is this
fixing anything?
> ---
> include/linux/freezer.h | 3 ++-
> kernel/freezer.c| 3 +--
> kernel/power/process.c | 24
> 3 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index b303472255be..3413c869d68b 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -13,7 +13,7 @@
> #ifdef CONFIG_FREEZER
> DECLARE_STATIC_KEY_FALSE(freezer_active);
>
> -extern bool pm_freezing; /* PM freezing in effect */
> +bool pm_freezing(void);
> extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
>
> /*
> @@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return -ENOSYS; }
> static inline int freeze_kernel_threads(void) { return -ENOSYS; }
> static inline void thaw_processes(void) {}
> static inline void thaw_kernel_threads(void) {}
> +static inline bool pm_freezing(void) { return false; }
>
> static inline bool try_to_freeze(void) { return false; }
>
> diff --git a/kernel/freezer.c b/kernel/freezer.c
> index 4fad0e6fca64..2d3530ebdb7e 100644
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
> * indicate whether PM freezing is in effect, protected by
> * system_transition_mutex
> */
> -bool pm_freezing;
> bool pm_nosig_freezing;
>
> /* protects freezing and frozen transitions */
> @@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
> if (pm_nosig_freezing || cgroup_freezing(p))
> return true;
>
> - if (pm_freezing && !(p->flags & PF_KTHREAD))
> + if (pm_freezing() && !(p->flags & PF_KTHREAD))
> return true;
>
> return false;
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index ddd9988327fe..8a4d0e2c8c20 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
> return todo ? -EBUSY : 0;
> }
>
> +/*
> + * Indicate whether PM freezing is in effect, protected by
> + * system_transition_mutex.
> + */
> +static bool pm_freezing_internal;
> +
> +/**
> + * pm_freezing - indicate whether PM freezing is in effect.
> + *
> + */
> +bool pm_freezing(void)
> +{
> + return pm_freezing_internal;
> +}
> +EXPORT_SYMBOL(pm_freezing);
Use EXPORT_SYMBOL_GPL() instead, please.
> +
> /**
> * freeze_processes - Signal user space processes to enter the refrigerator.
> * The current thread will not be frozen. The same process that calls
> @@ -126,12 +142,12 @@ int freeze_processes(void)
> /* Make sure this task doesn't get frozen */
> current->flags |= PF_SUSPEND_TASK;
>
> - if (!pm_freezing)
> + if (!pm_freezing())
> static_branch_inc(&freezer_active);
>
> pm_wakeup_clear(0);
> pr_info("Freezing user space processes ... ");
> - pm_freezing = true;
> + pm_freezing_internal = true;
> error = try_to_freeze_tasks(true);
> if (!error) {
> __usermodehelper_set_disable_depth(UMH_DISABLED);
> @@ -187,9 +203,9 @@ void thaw_processes(void)
> struct task_struct *curr = current;
>
> trace_suspend_resume(TPS("thaw_processes"), 0, true);
> - if (pm_freezing)
> + if (pm_freezing())
> static_branch_dec(&freezer_active);
> - pm_freezing = false;
> + pm_freezing_internal = false;
> pm_nosig_freezing = false;
>
> oom_killer_enable();
>
> --
Re: [QEMU][PATCH v2 07/11] hw/xen/xen-hvm-common: Use g_new and error_setg_errno
Hi Markus & Philippe,
Thanks for reviewing this one. Please see the question below.
On 12/2/22 12:53 AM, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
On 2/12/22 03:59, Vikram Garhwal wrote:
Replace g_malloc with g_new and perror with error_setg_errno.
Signed-off-by: Vikram Garhwal
---
hw/xen/xen-hvm-common.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
@@ -717,7 +717,7 @@ void destroy_hvm_domain(bool reboot)
xc_interface *xc_handle;
int sts;
int rc;
-
+Error *errp = NULL;
unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
if (xen_dmod) {
@@ -726,7 +726,7 @@ void destroy_hvm_domain(bool reboot)
return;
}
if (errno != ENOTTY /* old Xen */) {
-perror("xendevicemodel_shutdown failed");
+error_setg_errno(&errp, errno, "xendevicemodel_shutdown failed");
See "qapi/error.h":
* = Passing errors around =
*
* Errors get passed to the caller through the conventional @errp
* parameter.
Here you are not passing the error to the caller.
Instead, you're leaking its memory.
Maybe you are looking for the "qemu/error-report.h" API?
Plausible.
Also, @errp is the conventional name for the Error ** parameter used to
pass errors to the caller. Local Error * variables are usually called
@err or @local_err (I prefer the former).
[...]
IIUC, error_set_errno() is not okay as it needs to be called with errp
from caller. But error_set(&err, "") is okay with locally defined **err
= NULL;
Is that correct understanding?
[PATCH] drivers/xen/hypervisor: Expose Xen SIF flags to userspace
/proc/xen is a legacy pseudo filesystem which predates Xen support
getting merged into Linux. It has largely been replaced with more
normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for
user devices). We want to compile xenfs support out of the dom0 kernel.
There is one item which only exists in /proc/xen, namely
/proc/xen/capabilities with "control_d" being the signal of "you're in
the control domain". This ultimately comes from the SIF flags provided
at VM start.
This patch exposes all SIF flags in /sys/hypervisor/start_flags/ as
boolean files, one for each bit, returning '1' if set, '0' otherwise.
Two known flags, 'privileged' and 'initdomain', are explicitly named,
and all remaining flags can be accessed via generically named files,
as suggested by Andrew Cooper.
This patch replaces previous suggestion for SIF flags exposure in its
entirety.
Signed-off-by: Per Bilse
---
Documentation/ABI/stable/sysfs-hypervisor-xen | 8 +++
drivers/xen/sys-hypervisor.c | 70 +--
2 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-hypervisor-xen
b/Documentation/ABI/stable/sysfs-hypervisor-xen
index 748593c64568..f52f98548184 100644
--- a/Documentation/ABI/stable/sysfs-hypervisor-xen
+++ b/Documentation/ABI/stable/sysfs-hypervisor-xen
@@ -120,3 +120,11 @@ Contact: xen-devel@lists.xenproject.org
Description: If running under Xen:
The Xen version is in the format .
This is the part of it.
+
+What: /sys/hypervisor/start_flags/*
+Date: December 2022
+KernelVersion: 6.1.0
+Contact: xen-devel@lists.xenproject.org
+Description: If running under Xen:
+ All bits in Xen's start-flags are represented as
+ boolean files, returning '1' if set, '0' otherwise.
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index fcb0792f090e..e15d3ff2c56f 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -31,7 +31,10 @@ struct hyp_sysfs_attr {
struct attribute attr;
ssize_t (*show)(struct hyp_sysfs_attr *, char *);
ssize_t (*store)(struct hyp_sysfs_attr *, const char *, size_t);
- void *hyp_attr_data;
+ union {
+ void *hyp_attr_data;
+ unsigned long hyp_attr_value;
+ };
};
static ssize_t type_show(struct hyp_sysfs_attr *attr, char *buffer)
@@ -399,6 +402,61 @@ static int __init xen_sysfs_properties_init(void)
return sysfs_create_group(hypervisor_kobj, &xen_properties_group);
}
+#define FLAG_UNAME "unknown"
+#define FLAG_UNAME_FMT FLAG_UNAME "%02u"
+#define FLAG_UNAME_MAX sizeof(FLAG_UNAME "XX")
+#define FLAG_COUNT (sizeof(xen_start_flags) * BITS_PER_BYTE)
+static_assert(sizeof(xen_start_flags)
+ <= sizeof_field(struct hyp_sysfs_attr, hyp_attr_value));
+
+static ssize_t flag_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+ char *p = buffer;
+
+ *p++ = '0' + ((xen_start_flags & attr->hyp_attr_value) != 0);
+ *p++ = '\n';
+ return p - buffer;
+}
+
+/*
+* Add new, known flags here. No other changes are required, but
+* note that each known flag wastes one entry in flag_unames[].
+* The code/complexity machinations to avoid this isn't worth it
+* for a few entries, but keep it in mind.
+*/
+static struct hyp_sysfs_attr flag_attrs[FLAG_COUNT] = {
+ [ilog2(SIF_PRIVILEGED)] = {
+ .attr = { .name = "privileged", .mode = 0444 },
+ .show = flag_show,
+ .hyp_attr_value = SIF_PRIVILEGED
+ },
+ [ilog2(SIF_INITDOMAIN)] = {
+ .attr = { .name = "initdomain", .mode = 0444 },
+ .show = flag_show,
+ .hyp_attr_value = SIF_INITDOMAIN
+ }
+};
+static struct attribute_group xen_flags_group = {
+ .name = "start_flags",
+ .attrs = (struct attribute *[FLAG_COUNT + 1]){}
+};
+static char flag_unames[FLAG_COUNT][FLAG_UNAME_MAX];
+
+static int __init xen_sysfs_flags_init(void)
+{
+ for (unsigned fnum = 0; fnum != FLAG_COUNT; fnum++) {
+ if (likely(flag_attrs[fnum].attr.name == NULL)) {
+ sprintf(flag_unames[fnum], FLAG_UNAME_FMT, fnum);
+ flag_attrs[fnum].attr.name = flag_unames[fnum];
+ flag_attrs[fnum].attr.mode = 0444;
+ flag_attrs[fnum].show = flag_show;
+ flag_attrs[fnum].hyp_attr_value = 1 << fnum;
+ }
+ xen_flags_group.attrs[fnum] = &flag_attrs[fnum].attr;
+ }
+ return sysfs_create_group(hypervisor_kobj, &xen_flags_group);
+}
+
#ifdef CONFIG_XEN_HAVE_VPMU
struct pmu_mode {
const char *name;
@@ -539,18 +597,22 @@ static int __init hyper_sysfs_init(void)
ret = xen_sysfs_properties_init();
if (ret)
goto prop_out;
+ ret = xen_sysfs_flags_init();
+ if (ret)
+
Re: [XEN v3] Xen: Ensure "xenheap_bits - PAGE_SHIFT" can be used as a rhs operand of shift operator
On Fri, Dec 02, 2022 at 12:56:06PM +, Andrew Cooper wrote: > On 02/12/2022 12:35, Ayan Kumar Halder wrote: > > Currently this change will not have any impact on the existing > > architectures. > > The following table illustrates PADDR_BITS vs BITS_PER_LONG of different > > archs > > > > > > | Arch | PADDR_BITS| BITS_PER_LONG | > > > > | Arm_64| 48| 64| > > | Arm_32| 40| 32| > > | RISCV_64 | Don't know| 64| > > Just FYI, I think the answer here is 56 for RISC-V. > > ~Andrew > Andrew got it: 56.
[ovmf test] 175026: all pass - PUSHED
flight 175026 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175026/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5d5be45bd7c1e479863125e7d772e54772c9 baseline version: ovmf 47d988387efc8b45561f542f7a8e5b6a43979a8c Last test of basis 175017 2022-12-02 01:10:50 Z0 days Testing same since 175026 2022-12-02 14:40:46 Z0 days1 attempts People who touched revisions under test: Zhihao Li jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 47d988387e..5d5be45bd1 5d5be45bd7c1e479863125e7d772e54772c9 -> xen-tested-master
[xen-unstable test] 175021: regressions - FAIL
flight 175021 xen-unstable real [real] flight 175027 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/175021/ http://logs.test-lab.xenproject.org/osstest/logs/175027/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-livepatch 7 xen-install fail REGR. vs. 175009 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175009 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175009 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175009 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175009 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175009 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175009 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175009 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175009 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check
Re: [ANNOUNCE] Call for agenda items for 1 December Community Call @ 1600 UTC
On Fri, Dec 02, 2022 at 11:17:18AM +, George Dunlap wrote: > > > > On 1 Dec 2022, at 21:56, Elliott Mitchell wrote: > > > > On Thu, Nov 24, 2022 at 05:11:36PM +, George Dunlap wrote: > >> > >> == Dial-in Information == > >> ## Meeting time > >> 16:00 - 17:00 UTC > >> Further International meeting times: > >> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=12&day=1&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179 > >> > > Ellliot, > > Thanks for your feedback. Replies in-line. > > > I guess I have to ask, what is the goal of the Community Call? Neither > > this message, nor the wiki page > > (https://wiki.xenproject.org/wiki/Community_Call) say much about the > > Community Call. > > The goal of the call in general is just to talk about things that need > talking about. We obviously have the mailing list, but sometimes discussions > here are easy to miss; and sometimes a discussion can get sorted out more > quickly with a fast back-and-forth than with long email chains. The intent > has always been that if we start getting one topic that consistently 1) takes > up a large amount of time and 2) only requires a subset of the attendees, to > split it off into a separate meeting. > The page on the wiki and announcement should provide some sort of statement. I'm still unsure the two items I was proposing were good candidates as they're more "these two /should/ be getting more attention". > > This seemed to be being pointed out at the end of D.3, which was meant as > > low-priority, but was dealt with first purely due to being added first. > > Then most of the time was spent on D.4 when D.9 actually seemed a rather > > timely issue (the idea to get a bit of consideration before 4.17). > > To be honest, part of my reluctance to move that one up in the agenda was > because it was my own item. Even with the number of items ahead of it, I > didn’t expect it to be a problem to get to — there were several items which > took much longer to discuss than I was expecting. In the future I’ll be more > pro-active about trying to prioritize things. > First there is a need to know whether things can run long or not. If key people need to drop out right at the end of the specified time, prioritization is important. If everyone can run long, then in-order is fine. > > Problem with D.1 being at the start is it was unexpected half the agenda > > would be thrown in the garbage due to time. Could I suggest the 10th as > > better? > > The 10th of January instead of the 12th of January? Why is that better? > > I work as a stay-at-home dad on Tuesdays, so I wouldn’t be able to chair the > meeting if it was on the 10th. > As stated, I didn't expect everything to get dropped on the floor and so didn't comment on the 12th being no-go for me. I've no idea which dates work better for whom, but the 10th or before is workable for me (heck, even the 29th is viable, but I suspect that will be worse for others). -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Re: [QEMU][PATCH v2 05/11] include/hw/xen/xen_common: return error from xen_create_ioreq_server
On Fri, 1 Dec 2022, Philippe Mathieu-Daudé wrote:
> On 2/12/22 08:19, Philippe Mathieu-Daudé wrote:
> > Hi Stefano and Vikram,
> >
> > On 2/12/22 03:59, Vikram Garhwal wrote:
> > > From: Stefano Stabellini
> > >
> > > This is done to prepare for enabling xenpv support for ARM architecture.
> > > On ARM it is possible to have a functioning xenpv machine with only the
> > > PV backends and no IOREQ server. If the IOREQ server creation fails,
> > > continue to the PV backends initialization.
> > >
> > > Signed-off-by: Stefano Stabellini
> > > Signed-off-by: Vikram Garhwal
> > > ---
> > > include/hw/xen/xen_common.h | 13 -
> > > 1 file changed, 8 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> > > index 77ce17d8a4..6510ac15e0 100644
> > > --- a/include/hw/xen/xen_common.h
> > > +++ b/include/hw/xen/xen_common.h
> > > @@ -467,9 +467,10 @@ static inline void xen_unmap_pcidev(domid_t dom,
> > > {
> > > }
> > > -static inline void xen_create_ioreq_server(domid_t dom,
> > > - ioservid_t *ioservid)
> >
> > How long are we supposed to maintain this code? Per [*]:
> >
> > In general XenProject.org supports stable branches for 18 months full
> > support plus 18 months security fixes. When a new X.Y.0 release is
> > made there is usually one more release on the to-be-retired stable
> > branch to mop up any loose patches sitting in the repository at which
> > point the branch is retired.
> >
> > 4.17 was just released. 4.5 was 7 years ago. IIUC EOL'ed 4 years ago.
Hi Philippe,
So far we have not removed any of the old compatibility code in the xen
headers like xen_common.h. However, you have a point and I think we
could do so going forward. Like you wrote, 4.5 was 7 years ago, I would
be happy to remove the old compatibility code to support ancient
releases and that would simplify the code in the QEMU xen headers quite
a bit.
That said, the change in this patch is orthogonal. This is needed anyway
because we can have very modern Xen builds without IOREQ server
capabilities (it is a kconfig option). So we would still need this patch.
Cheers,
Stefano
> > [*]
> > https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases#Stable_Maintenance_Branches
>
> +Paolo for commit 14efd8d3b5 ("meson, configure: move Xen detection to
> meson"):
>
> xen_libs = {
> '4.11.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory',
> 'xengnttab', 'xenevtchn', 'xentoolcore' ],
> '4.10.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory',
> 'xengnttab', 'xenevtchn', 'xentoolcore' ],
> '4.9.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory',
> 'xengnttab', 'xenevtchn' ],
> '4.8.0': [ 'xenstore', 'xenctrl', 'xenforeignmemory', 'xengnttab',
> 'xenevtchn' ],
> '4.7.1': [ 'xenstore', 'xenctrl', 'xenforeignmemory', 'xengnttab',
> 'xenevtchn' ],
> '4.6.0': [ 'xenstore', 'xenctrl' ],
> '4.5.0': [ 'xenstore', 'xenctrl' ],
> '4.2.0': [ 'xenstore', 'xenctrl' ],
> }
>
> According to repology for the 'xen' package:
>
>FreeBSD (ports):4.16
>Debian 11: 4.14.5
>Fedora 35: 4.16.2
>Ubuntu 20.04: 4.11.3
>OpenSUSE Leap 15.3: 4.14.1
>RHEL 8: ?
>
Re: [QEMU][PATCH v2 10/11] hw/arm: introduce xenpv machine
Hi Alex,
On 12/2/22 6:52 AM, Alex Bennée wrote:
Vikram Garhwal writes:
Add a new machine xenpv which creates a IOREQ server to register/connect with
Xen Hypervisor.
Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
TPM emulator and connects to swtpm running on host machine via chardev socket
and support TPM functionalities for a guest domain.
Extra command line for aarch64 xenpv QEMU to connect to swtpm:
-chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
-tpmdev emulator,id=tpm0,chardev=chrtpm \
swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
provides access to TPM functionality over socket, chardev and CUSE interface.
Github repo: https://github.com/stefanberger/swtpm
Example for starting swtpm on host machine:
mkdir /tmp/vtpm2
swtpm socket --tpmstate dir=/tmp/vtpm2 \
--ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
+
+static void xen_enable_tpm(void)
+{
+/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
+#ifdef CONFIG_TPM
+Error *errp = NULL;
+DeviceState *dev;
+SysBusDevice *busdev;
+
+TPMBackend *be = qemu_find_tpm_be("tpm0");
+if (be == NULL) {
+DPRINTF("Couldn't fine the backend for tpm0\n");
+return;
+}
+dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
+object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
+object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
+busdev = SYS_BUS_DEVICE(dev);
+sysbus_realize_and_unref(busdev, &error_fatal);
+sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
Still fails on my aarch64 Debian machine:
FAILED: libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o
cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I../.. -Itarget/arm -I../../target/arm -Iqapi -Itrace
-Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/local/include -I/usr/include/capstone
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/glib-2.0
-I/usr/lib/aarch64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror
-std=gnu11 -O2 -g -isystem /home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote .
-iquote /home/alex/lsrc/qemu.git -iquote /home/alex/lsrc/qemu.git/include -iquote
/home/alex/lsrc/qemu.git/tcg/aarch64 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k
-Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-psabi -fstack-protector-strong -fPIE -isystem../../linux-headers -isystemlinux-headers
-DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"'
'-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ
libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -MF
libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o.d -o
libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -c ../../hw/arm/xen_arm.c
../../hw/arm/xen_arm.c: In function ‘xen_enable_tpm’:
../../hw/arm/xen_arm.c:126:32: error: ‘GUEST_TPM_BASE’ undeclared (first use
in this function); did you mean ‘GUEST_RAM_BASE’?
126 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
|^~
|GUEST_RAM_BASE
../../hw/arm/xen_arm.c:126:32: note: each undeclared identifier is reported
only once for each function it appears in
[2082/3246] Compiling C object
libqemu-aarch64-softmmu.fa.p/hw_xen_xen-mapcache.c.o
[2083/3246] Compiling C object
libqemu-aarch64-softmmu.fa.p/hw_xen_xen-hvm-common.c.o
ninja: build stopped: subcommand failed.
make: *** [Makefile:165: run-ninja] Error 1
Do you know what Xen version your build env has?
Another way to fix this(as Julien suggested) is by setting this
GUEST_TPM_BASE value via a property or something and user can set it via
command line.
@sstabell...@kernel.org, do you think of any other fix?
+
+DPRINTF("Connected tpmdev at address 0x%lx\n", GUEST_TPM_BASE);
+#endif
+}
If there is a minimum required version for TPM then it needs to be
picked up by configure.
Re: [QEMU][PATCH v2 10/11] hw/arm: introduce xenpv machine
On Fri, 2 Dec 2022, Vikram Garhwal wrote:
> On 12/2/22 6:52 AM, Alex Bennée wrote:
> > Vikram Garhwal writes:
> >
> > > Add a new machine xenpv which creates a IOREQ server to register/connect
> > > with
> > > Xen Hypervisor.
> > >
> > > Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device,
> > > adds a
> > > TPM emulator and connects to swtpm running on host machine via chardev
> > > socket
> > > and support TPM functionalities for a guest domain.
> > >
> > > Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> > > -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> > > -tpmdev emulator,id=tpm0,chardev=chrtpm \
> > >
> > > swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms
> > > and
> > > provides access to TPM functionality over socket, chardev and CUSE
> > > interface.
> > > Github repo: https://github.com/stefanberger/swtpm
> > > Example for starting swtpm on host machine:
> > > mkdir /tmp/vtpm2
> > > swtpm socket --tpmstate dir=/tmp/vtpm2 \
> > > --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
> >
> > > +
> > > +static void xen_enable_tpm(void)
> > > +{
> > > +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
> > > +#ifdef CONFIG_TPM
> > > +Error *errp = NULL;
> > > +DeviceState *dev;
> > > +SysBusDevice *busdev;
> > > +
> > > +TPMBackend *be = qemu_find_tpm_be("tpm0");
> > > +if (be == NULL) {
> > > +DPRINTF("Couldn't fine the backend for tpm0\n");
> > > +return;
> > > +}
> > > +dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
> > > +object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
> > > +object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
> > > +busdev = SYS_BUS_DEVICE(dev);
> > > +sysbus_realize_and_unref(busdev, &error_fatal);
> > > +sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
> > Still fails on my aarch64 Debian machine:
> >
> >FAILED: libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o
> >cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I../.. -Itarget/arm
> > -I../../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1
> > -I/usr/local/include -I/usr/include/capstone -I/usr/include/spice-server
> > -I/usr/include/spice-1 -I/usr/include/glib-2.0
> > -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall
> > -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem
> > /home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote .
> > -iquote /home/alex/lsrc/qemu.git -iquote /home/alex/lsrc/qemu.git/include
> > -iquote /home/alex/lsrc/qemu.git/tcg/aarch64 -pthread -U_FORTIFY_SOURCE
> > -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings
> > -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
> > -Wold-style-declaration -Wold-style-definition -Wtype-limits
> > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body
> > -Wnested-externs -Wendif-labels -Wexpansion-to-defined
> > -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value
> > -Wno-psabi -fstack-protector-strong -fPIE -isystem../../linux-headers
> > -isystemlinux-headers -DNEED_CPU_H
> > '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"'
> > '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ
> > libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -MF
> > libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o.d -o
> > libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -c ../../hw/arm/xen_arm.c
> >../../hw/arm/xen_arm.c: In function ‘xen_enable_tpm’:
> >../../hw/arm/xen_arm.c:126:32: error: ‘GUEST_TPM_BASE’ undeclared (first
> > use in this function); did you mean ‘GUEST_RAM_BASE’?
> > 126 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
> > |^~
> > |GUEST_RAM_BASE
> >../../hw/arm/xen_arm.c:126:32: note: each undeclared identifier is
> > reported only once for each function it appears in
> >[2082/3246] Compiling C object
> > libqemu-aarch64-softmmu.fa.p/hw_xen_xen-mapcache.c.o
> >[2083/3246] Compiling C object
> > libqemu-aarch64-softmmu.fa.p/hw_xen_xen-hvm-common.c.o
> >ninja: build stopped: subcommand failed.
> >make: *** [Makefile:165: run-ninja] Error 1
> >
> Do you know what Xen version your build env has?
I think Alex is just building against upstream Xen. GUEST_TPM_BASE is
not defined there yet. I think we would need to introduce in
xen_common.h something like:
#ifndef GUEST_TPM_BASE
#define GUEST_TPM_BASE 0x0c00
#endif
We already have similar code in xen_common.h for other things. Also, it
would be best to get GUEST_TPM_BASE defined upstream in Xen first.
> Another way to fix this(as Julien suggested) is by setting this GUEST_TPM_BASE
> value via a property or something and user can set it via command line.
>
> @sstabell...@kernel.org, d
[linux-linus test] 175023: regressions - FAIL
flight 175023 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175023/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-examine 8 reboot fail REGR. vs. 173462 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-raw 8 xen-boot fail REGR. vs. 173462 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 173462 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173462 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173462 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: linuxa4412fdd49dc011bcc2c0d81ac4cab7457092650 baseline version: linux9d84bb40bcb30a7fa16f33baa967aeb9953dda78 Last test of basis 173462 2022-10-07 18:41:45 Z 56 days Failing since173470 2022-10-08 06:21:34 Z 55 days 108 attempts Testing same since 175023 2022-12-02 11:08:32 Z0 days1 attempts 1931 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xlpass test-arm64-arm64-xl fail test-armhf-armhf-xl fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-am
Re: [PATCH 2/4] xen/scripts: add cppcheck tool to the xen-analysis.py script
On Fri, 2 Dec 2022, Luca Fancellu wrote:
> > On 1 Dec 2022, at 20:23, Stefano Stabellini wrote:
> >
> > On Thu, 1 Dec 2022, Luca Fancellu wrote:
> >> Hi Stefano,
> >>
> >
> >
> >> +sm_tool_args="n"
> >> +;;
> >> +--cppcheck-cmd=*)
> >> +CPPCHECK_TOOL="$(eval echo "${OPTION#*=}")"
> >> +sm_tool_args="y"
> >> +;;
> >> +--cppcheck-html)
> >> +CPPCHECK_HTML="y"
> >> +sm_tool_args="n"
> >> +;;
> >> +--cppcheck-plat=*)
> >> +CPPCHECK_PLAT_PATH="$(eval echo "${OPTION#*=}")"
> >> +sm_tool_args="n"
> >> +;;
> >> +--ignore-path=*)
> >> +IGNORE_PATH_LIST="${IGNORE_PATH_LIST} $(eval echo
> >> "${OPTION#*=}")"
> >> +sm_tool_args="n"
> >> +;;
> >> +--)
> >> +forward_to_cc="y"
> >> +sm_tool_args="n"
> >> +;;
> >> +*)
> >> +if [ "${sm_tool_args}" = "y" ]; then
> >> +CPPCHECK_TOOL_ARGS="${CPPCHECK_TOOL_ARGS} ${OPTION}"
> >> +else
> >> +echo "Invalid option ${OPTION}"
> >> +exit 1
> >
> > It doesn't look like sm_tool_args is really needed? It is only set to
> > 'y' in the case of --cppcheck-cmd, and in that case we also set
> > CPPCHECK_TOOL. CPPCHECK_TOOL is the variable used below. Am I missing
> > something?
>
> We use sm_tool_args to fill CPPCHECK_TOOL_ARGS, basically it’s a state
> machine where
> when we find --cppcheck-cmd= we expect that every other space
> separated arguments
> passed afterwards are the args for cppcheck, so we append to
> CPPCHECK_TOOL_ARGS
> until we find an argument that is supposed to be only for this script.
> >>>
> >>> That seems a bit unnecessary: if the user wants to pass arguments to
> >>> cppcheck, the user would do --cppcheck-cmd="cppcheck arg1 arg2" with ""
> >>> quotes. Doing that should make --cppcheck-cmd="cppcheck arg1 arg2" be
> >>> seen as a single argument from this script point of view. CPPCHECK_TOOL
> >>> would end up being set to "cppcheck arg1 arg2" which is what we want
> >>> anyway? And if we need to distinguish between the cppcheck binary and
> >>> its argument we could use "cut" to extract "cppcheck", "arg1", and
> >>> "arg2" from CPPCHECK_TOOL. Would that work?
> >>>
> >>
> >> I gave a try for the quotes, the problem is that we need to have quotes in
> >> CC=“...”, so adding
> >> quotes also to --cppcheck-cmd= which is inside CC=“...” is preventing the
> >> Makefile to work,
> >> I tried escaping etc but I didn’t manage to have it working, so would you
> >> agree on keeping it
> >> like that?
> >
> > Is the problem coming from the following?
> >
> >cppcheck_cc_flags = """--compiler={} --cppcheck-cmd={} {}
> > --cppcheck-plat={}/cppcheck-plat --ignore-path=tools/
> > """.format(xen_cc, settings.cppcheck_binpath, cppcheck_flags,
> > settings.tools_dir)
> >
> >if settings.cppcheck_html:
> >cppcheck_cc_flags = cppcheck_cc_flags + " --cppcheck-html"
> >
> ># Generate the extra make argument to pass the cppcheck-cc.sh wrapper as
> > CC
> >cppcheck_extra_make_args = "CC=\"{}/cppcheck-cc.sh {} --\"".format(
> >settings.tools_dir,
> >cppcheck_cc_flags
> >).replace("\n", "")
> >
> >
> > Wouldn't something like the following solve the issue?
> >
> >settings.cppcheck_binpath = settings.cppcheck_binpath + " " +
> > cppcheck_cc_flags
> >
> >cppcheck_cc_flags = """--compiler={} --cppcheck-cmd=\"{}\"
> > --cppcheck-plat={}/cppcheck-plat --ignore-path=tools/
> > """.format(xen_cc, settings.cppcheck_binpath, settings.tools_dir)
> >
> >if settings.cppcheck_html:
> >cppcheck_cc_flags = cppcheck_cc_flags + " --cppcheck-html"
> >
> ># Generate the extra make argument to pass the cppcheck-cc.sh wrapper as
> > CC
> >cppcheck_extra_make_args = "CC=\"{}/cppcheck-cc.sh {} --\"".format(
> >settings.tools_dir,
> >cppcheck_cc_flags
> >).replace("\n", "")
>
> No unfortunately not, Makefile is very sensitive to quotes, I’ve tried with
> many combination of single/double quotes but nothing worked
I spent a couple of hours to try to get it to work. I also admit defeat.
Keep your original code, that's better.
[xen-4.17-testing test] 175025: tolerable FAIL - PUSHED
flight 175025 xen-4.17-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/175025/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175015 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175015 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175015 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175015 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175015 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175015 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175015 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175015 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175015 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175015 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175015 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175015 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen 100c3416b5cab2e06c774f68e1d7410cb0fc52b1 baseline version: xen 942f881eb1b4
[xen-unstable test] 175029: regressions - trouble: blocked/broken/fail/pass
flight 175029 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175029/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 5 host-build-prep fail REGR. vs. 175009 Tests which did not succeed, but are not blocking: build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175009 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175009 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175009 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175009 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175009 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175009 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass version targeted for testing: xen 10acd21795a9df5c0908c58104e82472c5fa2d17 baseline version: xen ddcc208ccdd44c688b3265be26237875c16b6258 Last test of basis 175009 2022-12-01 15:40:23 Z1 days Failing since175021 2022-12-02 07:22:22 Z0 days2 attempts Testing same since 175029 2022-12-02 20:08:34 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Christian Lindig Edwin Török Jan Beulich Juergen Gross Julien Grall Michal Orzel Pau Ruiz Safont Roger Pau Monné Stefano Stabellini Stefano Stabellini jobs: build-amd
