[PATCH] x86: also discard .fini_array in linker script
This simply parallels .dtors. Both section types can reference
.text.exit, which requires them to be discarded together with that one.
Compilers, depending on their findings during the configure phase, may
elect to use either model. While .{init,fini}_array look to be
preferred, cross compilers apparently have this guessed, likely
resulting in a fallback to .{c,d}tors. Hence we need to support both
sets.
Fixes: 4b7fd8153ddf ("x86: fold sections in final binaries")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
As mentioned elsewhere, I don't think init_constructors() is correct
for the .ctors variant. But that's a separate issue.
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -415,6 +415,8 @@ SECTIONS
*(.eh_frame)
*(.dtors)
*(.dtors.*)
+ *(.fini_array)
+ *(.fini_array.*)
#ifdef EFI
*(.comment)
*(.comment.*)
Re: [Regression] [PATCH] x86: fold sections in final binaries
On 04.03.2022 08:29, Jan Beulich wrote:
> On 03.03.2022 21:02, Andrew Cooper wrote:
>> On 01/03/2022 08:55, Jan Beulich wrote:
>>> Especially when linking a PE binary (xen.efi), standalone output
>>> sections are expensive: Often the linker will align the subsequent one
>>> on the section alignment boundary (2Mb) when the linker script doesn't
>>> otherwise place it. (I haven't been able to derive from observed
>>> behavior under what conditions it would not do so.)
>>>
>>> With gcov enabled (and with gcc11) I'm observing enough sections that,
>>> as of quite recently, the resulting image doesn't fit in 16Mb anymore,
>>> failing the final ASSERT() in the linker script. (That assertion is
>>> slated to go away, but that's a separate change.)
>>>
>>> Any destructor related sections can be discarded, as we never "exit"
>>> the hypervisor. This includes .text.exit, which is referenced from
>>> .dtors.*. Constructor related sections need to all be taken care of, not
>>> just those with historically used names: .ctors.* and .text.startup is
>>> what gcc11 populates. While there re-arrange ordering / sorting to match
>>> that used by the linker provided scripts.
>>>
>>> Finally, for xen.efi only, also discard .note.gnu.*. These are
>>> meaningless in a PE binary. Quite likely, while not meaningless there,
>>> the section is also of no use in ELF, but keep it there for now.
>>>
>>> Signed-off-by: Jan Beulich
>>> ---
>>> TBD: We also use CONSTRUCTORS for an unknown reason. Documentation for
>>> ld is quite clear that this is an a.out-only construct.
>>> Implementation doesn't look to fully match this for ELF, but I'd
>>> nevertheless be inclined to remove its use.
>>>
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -194,6 +194,7 @@ SECTIONS
>>> #endif
>>> _sinittext = .;
>>> *(.init.text)
>>> + *(.text.startup)
>>> _einittext = .;
>>> /*
>>> * Here are the replacement instructions. The linker sticks them
>>> @@ -258,9 +259,10 @@ SECTIONS
>>>
>>> . = ALIGN(8);
>>> __ctors_start = .;
>>> - *(.ctors)
>>> + *(SORT_BY_INIT_PRIORITY(.init_array.*))
>>> + *(SORT_BY_INIT_PRIORITY(.ctors.*))
>>> *(.init_array)
>>> - *(SORT(.init_array.*))
>>> + *(.ctors)
>>> __ctors_end = .;
>>>} PHDR(text)
>>>
>>> @@ -404,16 +406,20 @@ SECTIONS
>>>
>>>/* Sections to be discarded */
>>>/DISCARD/ : {
>>> + *(.text.exit)
>>> *(.exit.text)
>>> *(.exit.data)
>>> *(.exitcall.exit)
>>> *(.discard)
>>> *(.discard.*)
>>> *(.eh_frame)
>>> + *(.dtors)
>>> + *(.dtors.*)
>>> #ifdef EFI
>>> *(.comment)
>>> *(.comment.*)
>>> *(.note.Xen)
>>> + *(.note.gnu.*)
>>> #endif
>>>}
>>
>> This breaks reliably in Gitlab CI.
>>
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2159059956 (gcc 11)
>
> Hmm, I wonder why I'm not seeing this locally. The lack of mentioning of
> .fini_array in the linker script struck me as odd already before. I can
> easily make a patch to add those sections to the script, but I'd first
> like to understand why I'm seeing gcc11 use .ctors / .dtors while here
> it's .init_array / .fini_array.
And it's as simple as this, seen in gcc's config.log:
configure:24049: checking for .preinit_array/.init_array/.fini_array support
configure:24214: checking cross compile... guessing
configure:24219: result: no
The mentioning of .preinit_array there of course makes me wonder whether
we need to also cater for that section. But with the orphan section
warning in place (hopefully soon), we'd at least be made aware by the
linker if such a section ever appears for whichever reason.
Jan
Re: [Regression] [PATCH] x86: fold sections in final binaries
On 03.03.2022 21:02, Andrew Cooper wrote:
> On 01/03/2022 08:55, Jan Beulich wrote:
>> Especially when linking a PE binary (xen.efi), standalone output
>> sections are expensive: Often the linker will align the subsequent one
>> on the section alignment boundary (2Mb) when the linker script doesn't
>> otherwise place it. (I haven't been able to derive from observed
>> behavior under what conditions it would not do so.)
>>
>> With gcov enabled (and with gcc11) I'm observing enough sections that,
>> as of quite recently, the resulting image doesn't fit in 16Mb anymore,
>> failing the final ASSERT() in the linker script. (That assertion is
>> slated to go away, but that's a separate change.)
>>
>> Any destructor related sections can be discarded, as we never "exit"
>> the hypervisor. This includes .text.exit, which is referenced from
>> .dtors.*. Constructor related sections need to all be taken care of, not
>> just those with historically used names: .ctors.* and .text.startup is
>> what gcc11 populates. While there re-arrange ordering / sorting to match
>> that used by the linker provided scripts.
>>
>> Finally, for xen.efi only, also discard .note.gnu.*. These are
>> meaningless in a PE binary. Quite likely, while not meaningless there,
>> the section is also of no use in ELF, but keep it there for now.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> TBD: We also use CONSTRUCTORS for an unknown reason. Documentation for
>> ld is quite clear that this is an a.out-only construct.
>> Implementation doesn't look to fully match this for ELF, but I'd
>> nevertheless be inclined to remove its use.
>>
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -194,6 +194,7 @@ SECTIONS
>> #endif
>> _sinittext = .;
>> *(.init.text)
>> + *(.text.startup)
>> _einittext = .;
>> /*
>> * Here are the replacement instructions. The linker sticks them
>> @@ -258,9 +259,10 @@ SECTIONS
>>
>> . = ALIGN(8);
>> __ctors_start = .;
>> - *(.ctors)
>> + *(SORT_BY_INIT_PRIORITY(.init_array.*))
>> + *(SORT_BY_INIT_PRIORITY(.ctors.*))
>> *(.init_array)
>> - *(SORT(.init_array.*))
>> + *(.ctors)
>> __ctors_end = .;
>>} PHDR(text)
>>
>> @@ -404,16 +406,20 @@ SECTIONS
>>
>>/* Sections to be discarded */
>>/DISCARD/ : {
>> + *(.text.exit)
>> *(.exit.text)
>> *(.exit.data)
>> *(.exitcall.exit)
>> *(.discard)
>> *(.discard.*)
>> *(.eh_frame)
>> + *(.dtors)
>> + *(.dtors.*)
>> #ifdef EFI
>> *(.comment)
>> *(.comment.*)
>> *(.note.Xen)
>> + *(.note.gnu.*)
>> #endif
>>}
>
> This breaks reliably in Gitlab CI.
>
> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2159059956 (gcc 11)
Hmm, I wonder why I'm not seeing this locally. The lack of mentioning of
.fini_array in the linker script struck me as odd already before. I can
easily make a patch to add those sections to the script, but I'd first
like to understand why I'm seeing gcc11 use .ctors / .dtors while here
it's .init_array / .fini_array.
Jan
Re: [PATCH v2 1/3] xen/vpci: msix: move x86 specific code to x86 file
On 03.03.2022 17:31, Rahul Singh wrote:
>> On 1 Mar 2022, at 1:55 pm, Jan Beulich wrote:
>> On 01.03.2022 14:34, Rahul Singh wrote:
On 24 Feb 2022, at 2:57 pm, Jan Beulich wrote:
On 15.02.2022 16:25, Rahul Singh wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -925,4 +925,106 @@ int vpci_msix_arch_print(const struct vpci_msix
> *msix)
>
>return 0;
> }
> +
> +int vpci_make_msix_hole(const struct pci_dev *pdev)
> +{
> +struct domain *d = pdev->domain;
> +unsigned int i;
> +
> +if ( !pdev->vpci->msix )
> +return 0;
> +
> +/* Make sure there's a hole for the MSIX table/PBA in the p2m. */
> +for ( i = 0; i < ARRAY_SIZE(pdev->vpci->msix->tables); i++ )
> +{
> +unsigned long start = PFN_DOWN(vmsix_table_addr(pdev->vpci, i));
> +unsigned long end = PFN_DOWN(vmsix_table_addr(pdev->vpci, i) +
> + vmsix_table_size(pdev->vpci, i) -
> 1);
> +
> +for ( ; start <= end; start++ )
> +{
> +p2m_type_t t;
> +mfn_t mfn = get_gfn_query(d, start, );
> +
> +switch ( t )
> +{
> +case p2m_mmio_dm:
> +case p2m_invalid:
> +break;
> +case p2m_mmio_direct:
> +if ( mfn_x(mfn) == start )
> +{
> +clear_identity_p2m_entry(d, start);
> +break;
> +}
> +/* fallthrough. */
> +default:
> +put_gfn(d, start);
> +gprintk(XENLOG_WARNING,
> +"%pp: existing mapping (mfn: %" PRI_mfn
> +"type: %d) at %#lx clobbers MSIX MMIO area\n",
> +>sbdf, mfn_x(mfn), t, start);
> +return -EEXIST;
> +}
> +put_gfn(d, start);
> +}
> +}
> +
> +return 0;
> +}
... nothing in this function looks to be x86-specific, except maybe
functions like clear_identity_p2m_entry() may not currently be available
on Arm. But this doesn't make the code x86-specific.
>>>
>>> I will maybe be wrong but what I understand from the code is that for x86
>>> if there is no p2m entries setup for the region, accesses to them will be
>>> trapped
>>> into the hypervisor and can be handled by specific MMIO handler.
>>>
>>> But for ARM when we are registering the MMIO handler we have to provide
>>> the GPA also for the MMIO handler.
>>
>> Question is: Is this just an effect resulting from different implementation,
>> or an inherent requirement? In the former case, harmonizing things may be an
>> alternative option.
>
> This is an inherent requirement to provide a GPA when registering the MMIO
> handler.
So you first say yes to my "inherent" question, but then ...
> For x86 msix mmio handlers is registered in init_msix(..) function as there
> is no requirement
> on x86 to provide GPA when registering the handler. Later point of time when
> BARs are configured
> and memory decoding bit is enabled vpci_make_msix_hole() will clear the
> identity mapping for msix
> base table address so that access to msix tables will be trapped.
>
> On ARM we need to provide GPA to register the mmio handler and MSIX table base
> address is not valid when init_msix() is called as BAR will be configured
> later point in time.
> Therefore on ARM mmio handler will be registered in function
> vpci_make_msix_hole() when
> memory decoding bit is enabled.
... you explain it's an implementation detail. I'm inclined to
suggest that x86 also pass the GPA where possible. Handler lookup
really would benefit from not needing to iterate over all registered
handlers, until one claims the access. The optimization part of this
of course doesn't need to be done right here, but harmonizing
register_mmio_handler() between both architectures would seem to be
a reasonable prereq step.
I'm adding Paul to Cc in case he wants to comment, as this would
touch his territory on the x86 side.
Jan
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
On 03.03.2022 18:14, Alex Olson wrote:
> I wasn't sure of the distinction between hardware domain and control domain
> for these commands, but they appear to be blocked at the moment when dom0
> executes them, including a lot at boot. Are you suggesting to use
> is_hardware_domain(currd) instead in my diff?
>
> Or should the hardware domain always be able to execute any physdev op
> command? (such as to bypass the switch statement entirely)
No, certainly not. It was on purpose to restrict PVH Dom0. Only PV
Dom0 is supposed to be able to access all sub-ops.
> It looks like hvm_physdev_op() is the only real caller of do_physdev_op(),
> and several other commands (besides the ones in the diff below) are also
> being blocked by the default case of hvm_physdev_op.
>
> PHYSDEVOP_pirq_eoi_gmfn_v2
> PHYSDEVOP_pirq_eoi_gmfn_v1
> PHYSDEVOP_IRQ_UNMASK_NOTIFY // legacy?
> PHYSDEVOP_apic_read
> PHYSDEVOP_apic_write
> PHYSDEVOP_alloc_irq_vector
> PHYSDEVOP_set_iopl
> PHYSDEVOP_set_iobitmap
> PHYSDEVOP_restore_msi
> PHYSDEVOP_restore_msi_ext
> PHYSDEVOP_setup_gsi
> PHYSDEVOP_get_free_pirq
> PHYSDEVOP_dbgp_op
>
> Thanks
>
> -Alex
Also - please don't top-post.
Jan
> On Thu, 2022-03-03 at 17:47 +0100, Jan Beulich wrote:
>> On 03.03.2022 17:45, Alex Olson wrote:
>>> --- a/xen/arch/x86/hvm/hypercall.c
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
>>> switch ( cmd )
>>> {
>>> +
>>> +case PHYSDEVOP_manage_pci_add:
>>> +case PHYSDEVOP_manage_pci_remove:
>>> +case PHYSDEVOP_pci_device_add:
>>> +case PHYSDEVOP_pci_device_remove:
>>> +case PHYSDEVOP_manage_pci_add_ext:
>>> +case PHYSDEVOP_prepare_msix:
>>> +case PHYSDEVOP_release_msix:
>>> +if ( is_control_domain(currd) )
>>> +break;
>>
>> These are all operations which I think are purposefully permitted to
>> be invoked by the hardware domain only. That's where all the devices
>> live when they're not passed through to guests.
>>
>> Jan
>>
>
RE: Proposal for Porting Xen to Armv8-R64 - DraftA
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年3月4日 3:51
> To: Wei Chen ; xen-devel@lists.xenproject.org; Stefano
> Stabellini
> Cc: Bertrand Marquis ; Penny Zheng
> ; Henry Wang ; nd
> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
>
> Hi Wei,
>
> On 03/03/2022 02:06, Wei Chen wrote:
> >> -Original Message-
> >> From: Julien Grall
> >> Sent: 2022年3月2日 20:00
> >> To: Wei Chen ; xen-devel@lists.xenproject.org;
> Stefano
> >> Stabellini
> >> Cc: Bertrand Marquis ; Penny Zheng
> >> ; Henry Wang ; nd
> >> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
> >>
> >>
> >>
> >> On 01/03/2022 07:51, Wei Chen wrote:
> >>> Hi Julien,
> >>
> >> Hi Wei,
> >>
> -Original Message-
> From: Julien Grall
> Sent: 2022年2月26日 4:55
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> >> Stefano
> Stabellini
> Cc: Bertrand Marquis ; Penny Zheng
> ; Henry Wang ; nd
>
> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
> > ### 1.2. Xen Challenges with PMSA Virtualization
> > Xen is PMSA unaware Type-1 Hypervisor, it will need modifications to
> >> run
> > with an MPU and host multiple guest OSes.
> >
> > - No MMU at EL2:
> >- No EL2 Stage 1 address translation
> >- Xen provides fixed ARM64 virtual memory layout as basis
> of
> EL2
> > stage 1 address translation, which is not applicable on
> >> MPU
> system,
> > where there is no virtual addressing. As a result, any
> operation
> > involving transition from PA to VA, like ioremap, needs
> modification
> > on MPU system.
> >- Xen's run-time addresses are the same as the link time
> >> addresses.
> >- Enable PIC (position-independent code) on a real-time
> >> target
> > processor probably very rare.
>
> Aside the assembly boot code and UEFI stub, Xen already runs at the
> >> same
> address as it was linked.
>
> >>>
> >>> But the difference is that, base on MMU, we can use the same link
> >> address
> >>> for all platforms. But on MPU system, we can't do it in the same way.
> >>
> >> I agree that we currently use the same link address for all the
> >> platforms. But this is also a problem when using MMU because EL2 has a
> >> single TTBR.
> >>
> >> At the moment we are switching page-tables with the MMU which is not
> >> safe. Instead we need to turn out the MMU off, switch page-tables and
> >> then turn on the MMU. This means we need to have an identity mapping of
> >> Xen in the page-tables. Assuming Xen is not relocated, the identity
> >> mapping may clash with Xen (or the rest of the virtual address map).
> >>
> >
> > Is this the same reason we create a dummy reloc section for EFI loader?
>
> The relocations for the EFI loader are necessary because IIRC it is
> running with virt == phys.
>
> But this brings to all sort of problem:
>
> https://lore.kernel.org/all/20171221145521.29526-1-
> julien.gr...@linaro.org/
>
It's interesting, I will have a look into that thread.
> [...]
>
> >>>
> >>> Some callers that want to change a memory's attribute will set them.
> >> Something like
> >>> ioremap_nocache. I am not sure is this what you had asked : )
> >>
> >> I am a bit confused. If ioremap_nocache() can change the attribute,
> then
> >> why would ioremap_attr() not be able to do it?
> >>
> >
> > MMU based iorepmap_ can use a new VA and new PTE to do this. But for
> > MPU, we can't do it, except you change the whole MPU region's attribute.
> > The reasons are:
> > 1. For V8R PMSA, one physical address only be existed one MPU region.
> > 2. There's not enough MPU regions for us to split one MPU region to
> > multiple MPU regions (changed pages region and unmodified pages
> regions).
>
> Ok. I think we should at least check the attributes requested match the
> one in the MPU.
>
Yes, this is what we want to do.
> >
> >>>
>
> >if ( CACHE_ATTR_need_change )
> >return NULL;
> >return (void *)pa;
> >}
> >static inline void __iomem *ioremap_nocache(...)
> >{
> >return ioremap_attr(start, len,
> PAGE_HYPERVISOR_NOCACHE);
> >}
> >static inline void __iomem *ioremap_cache(...)
> >{
> >return ioremap_attr(start, len, PAGE_HYPERVISOR);
> >}
> >static inline void __iomem *ioremap_wc(...)
> >{
> >return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
> >}
> >void *ioremap(...)
> >{
> >return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
> >}
> >
> >```
> >4. For `alternative`,
Re: [PATCH RFC] xen/sched: Optimise when only one scheduler is compiled in
On 03.03.22 01:40, Andrew Cooper wrote:
When only one scheduler is compiled in, function pointers can be optimised to
direct calls, and the hooks hardened against controlflow hijacking.
RFC for several reasons.
1) There's an almost beautiful way of not introducing MAYBE_SCHED() and hiding
the magic in REGISTER_SCHEDULER(), except it falls over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91765 which has no comment or
resolution at all.
2) A different alternative which almost works is to remove the indirection in
.data.schedulers, but the singleton scheduler object can't be both there
and in .init.rodata.cf_clobber.
3) I can't think of a way of build time check to enforce that new schedulers
get added to the preprocessor magic.
And the blocker:
4) This isn't compatible with how sched_idle_ops get used for granularity > 1.
Correct. Either you have core scheduling or you can optimize the
indirect calls to direct ones.
Suggestions very welcome.
Dynamic code generation for replacing the function vector with scheduler
id based if/switch statements.
Something like the attached patch for generating the code (won't build
right now as the related scheduler code adaptions are missing, but the
header is created).
The code generation script could share quite some code with my hypercall
series, and expansion for other function vectors should be rather easy.
Juergen
From 4bdee23501739236bee34d9c5dae90fef2bde057 Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Thu, 3 Mar 2022 10:32:22 +0100
Subject: [PATCH] xen/sched: generate code for calling scheduler callbacks
In order to avoid calls via function pointers don't use per scheduler
call vectors, but generate the respective call stubs dynamically based
on the defined schedulers.
Use a definition file for defining the templates of the callbacks and
the configured schedulers. The stubs will be using if () and switch ()
statements to call into the correct scheduler using the scheduler id.
The default scheduler is likely to be used in most cases, so it is
called using an if ( likely() ) construct.
In case only a single scheduler is configured the stub will be just a
wrapper for that scheduler.
The callbacks inside the single schedulers need to have standard names
in the form "sched_callback" with "sched" being the scheduler name
(e.g. "credit2"), and "callback" being the specific function (e.g.
"init"), resulting in a function name like "credit2_init".
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
xen/common/sched/Makefile | 12 +++
xen/common/sched/gen-sched-defs.awk | 152
xen/common/sched/private.h | 2 +
xen/common/sched/sched-defs.c | 62
5 files changed, 229 insertions(+)
create mode 100644 xen/common/sched/gen-sched-defs.awk
create mode 100644 xen/common/sched/sched-defs.c
diff --git a/.gitignore b/.gitignore
index d425be4bd9..d976cbf794 100644
--- a/.gitignore
+++ b/.gitignore
@@ -316,6 +316,7 @@ xen/arch/*/efi/runtime.c
xen/arch/*/include/asm/asm-offsets.h
xen/common/config_data.S
xen/common/config.gz
+xen/common/sched/sched-defs.h
xen/include/headers*.chk
xen/include/compat/*
xen/include/config/
diff --git a/xen/common/sched/Makefile b/xen/common/sched/Makefile
index 3537f2a68d..f7ba8b184c 100644
--- a/xen/common/sched/Makefile
+++ b/xen/common/sched/Makefile
@@ -5,3 +5,15 @@ obj-$(CONFIG_SCHED_CREDIT2) += credit2.o
obj-$(CONFIG_SCHED_RTDS) += rt.o
obj-$(CONFIG_SCHED_NULL) += null.o
obj-y += core.o
+
+quiet_cmd_gendefs = GEN $@
+cmd_gendefs = awk -f $(src)/gen-sched-defs.awk <$< >$@
+
+$(addprefix $(obj)/,$(obj-y)): $(obj)/sched-defs.h
+
+$(obj)/sched-defs.h: $(obj)/sched-defs.i $(src)/gen-sched-defs.awk FORCE
+ $(call if_changed,gendefs)
+
+targets += sched-defs.h
+
+clean-files := sched-defs.h sched-defs.i
diff --git a/xen/common/sched/gen-sched-defs.awk b/xen/common/sched/gen-sched-defs.awk
new file mode 100644
index 00..b445271db0
--- /dev/null
+++ b/xen/common/sched/gen-sched-defs.awk
@@ -0,0 +1,152 @@
+# awk script to generate scheduler calling stubs without using function vectors
+
+BEGIN {
+printf("/* Generated file, do not edit! */\n\n");
+s = 0;
+n = 0;
+ret[0] = 0;
+}
+
+# Issue error to stderr
+function do_err(msg) {
+print "Error: "msg": "$0 >"/dev/stderr";
+exit 1;
+}
+
+function parse_def(id, ret) {
+sub("^ *", "", id); # Remove leading white space
+sub(" +", " ", id); # Replace multiple spaces with single ones
+sub(" *$", "", id); # Remove trailing white space
+ret[1] = index(id, "*");# Is it a pointer type?
+sub("[*]", "", id); # Remove "*"
+if (index(id, " ") == 0)
+do_err("Identifier with no type or no name");
+ret[0] = id;
+sub(" [^ ]+$", "", ret[0]);# Remove identifier name
+ret[2] = id;
+sub("^([^ ]+ )+", "", ret[2]); # Remove type
+}
+
+function
[ovmf test] 168392: regressions - FAIL
flight 168392 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168392/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf b83d0a6438f24ba3c6234d9b7593be6f2246ec1e baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z3 days 30 attempts Testing same since 168392 2022-03-04 04:10:32 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Sebastien Boeuf Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. (No revision log; it would be 327 lines long.)
[linux-linus test] 168383: tolerable FAIL - PUSHED
flight 168383 linux-linus real [real] flight 168391 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168383/ http://logs.test-lab.xenproject.org/osstest/logs/168391/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 8 xen-bootfail pass in 168391-retest test-amd64-amd64-xl-xsm 22 guest-start/debian.repeat fail pass in 168391-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 168391 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 168391 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168355 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168355 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168355 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168355 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168355 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168355 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168355 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168355 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-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-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 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-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-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 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linuxb949c21fc23ecaccef89582f251e6281cad1f81e baseline version: linux5859a2b1991101d6b978f3feb5325dad39421f29 Last test of basis 168355 2022-03-03 05:19:36 Z0 days Testing same since 168383 2022-03-03 19:41:08 Z0 days1 attempts People who touched revisions under test: Alex Elder Alexander Lobakin Amit Cohen Andy Shevchenko
[ovmf test] 168389: regressions - FAIL
flight 168389 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z3 days 29 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days9 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
[qemu-mainline test] 168376: tolerable FAIL - PUSHED
flight 168376 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/168376/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 168343 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168343 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168343 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168343 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168343 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168343 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168343 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168343 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168343 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-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-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-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 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-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-amd64-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-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-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 15 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-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 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-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-libvirt-qcow2 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-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: qemuu36eae3a732a1f2aa81391e871ac0e9bb3233e7d7 baseline version: qemuu64ada298b98a51eb2512607f6e6180cb330c47b1 Last test of basis 168343 2022-03-02 18:07:05 Z1 days Testing same since 168376 2022-03-03 15:08:22 Z0 days1 attempts
[xen-unstable-smoke test] 168386: tolerable all pass - PUSHED
flight 168386 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/168386/ 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 1f410b0c7455748021be4ede59e7a0c0a2ffb1c4 baseline version: xen b692523fafb39f5f930e1e8a316f7b8cebc9f62a Last test of basis 168384 2022-03-03 20:00:30 Z0 days Testing same since 168386 2022-03-03 23:01:40 Z0 days1 attempts People who touched revisions under test: Julien Grall 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 b692523faf..1f410b0c74 1f410b0c7455748021be4ede59e7a0c0a2ffb1c4 -> smoke
Re: [XEN v9 4/4] xen/arm64: io: Handle data abort due to cache maintenance instructions
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> When the data abort is caused due to cache maintenance for an address,
> there are two scenarios:-
>
> 1. Address belonging to a non emulated region - For this, Xen should
> set the corresponding bit in the translation table entry to valid and
> return to the guest to retry the instruction. This can happen sometimes
> as Xen need to set the translation table entry to invalid. (for eg
> 'Break-Before-Make' sequence).
>
> 2. Address belongs to an emulated region - Xen should ignore the
> instruction (ie increment the PC) and return to the guest.
>
> We try to deal with scenario#1, by invoking check_p2m(). If this is
> unsuccessful, then we assume scenario#2.
>
> Signed-off-by: Ayan Kumar Halder
Acked-by: Stefano Stabellini
> ---
>
> Changelog:-
>
> v1...v8 - NA
>
> v9 - Extracted this change from "[XEN v7 2/2] xen/arm64: io: Support
> instructions (for which ISS is not ..." into a separate patch of its
> own. The reason being this addresses an existing bug in the codebase.
>
> xen/arch/arm/include/asm/mmio.h | 3 ++-
> xen/arch/arm/io.c | 11 +++
> xen/arch/arm/traps.c| 6 ++
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/include/asm/mmio.h b/xen/arch/arm/include/asm/mmio.h
> index ef2c57a2d5..75d362d5f5 100644
> --- a/xen/arch/arm/include/asm/mmio.h
> +++ b/xen/arch/arm/include/asm/mmio.h
> @@ -34,7 +34,8 @@ enum instr_decode_state
> * Instruction is decoded successfully. It is a ldr/str post indexing
> * instruction.
> */
> -INSTR_LDR_STR_POSTINDEXING
> +INSTR_LDR_STR_POSTINDEXING,
> +INSTR_IGNORE/* Instruction is ignored */
> };
>
> typedef struct
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index ebcb8ed548..7e9dd4bb08 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -139,6 +139,17 @@ void try_decode_instruction(const struct cpu_user_regs
> *regs,
> return;
> }
>
> +/*
> + * When the data abort is caused due to cache maintenance, Xen should
> ignore
> + * this instruction as the cache maintenance was caused on an address
> belonging
> + * to the emulated region.
> + */
> +if ( info->dabt.cache )
> +{
> +info->dabt_instr.state = INSTR_IGNORE;
> +return;
> +}
> +
> /*
> * Armv8 processor does not provide a valid syndrome for decoding some
> * instructions. So in order to process these instructions, Xen must
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index e491ca15d7..5879640b73 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2011,6 +2011,12 @@ static void do_trap_stage2_abort_guest(struct
> cpu_user_regs *regs,
>
> try_decode_instruction(regs, );
>
> +if ( info.dabt_instr.state == INSTR_IGNORE )
> +{
> +advance_pc(regs, hsr);
> +return;
> +}
> +
> /*
> * If Xen could not decode the instruction or encountered an error
> * while decoding, then it should forward the abort to the guest.
> --
> 2.17.1
>
Re: [XEN v9 3/4] xen/arm64: io: Handle the abort due to access to stage1 translation table
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> If the abort was caused due to access to stage1 translation table, Xen
> will assume that the stage1 translation table is in the non MMIO region.
> It will try to resolve the translation fault. If it succeeds, it will
> return to the guest to retry the instruction. If not, then it means
> that the table is in MMIO region which is not expected by Xen. Thus,
> Xen will forward the abort to the guest.
>
> Signed-off-by: Ayan Kumar Halder
> ---
>
> Changelog :-
>
> v1..v8 - NA
>
> v9 - 1. Extracted this change from "[XEN v8 2/2] xen/arm64: io: Support
> instructions (for which ISS is not..." into a separate patch of its own.
> The reason being this is an existing bug in the codebase.
>
> xen/arch/arm/io.c| 11 +++
> xen/arch/arm/traps.c | 12 +++-
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index bea69ffb08..ebcb8ed548 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -128,6 +128,17 @@ void try_decode_instruction(const struct cpu_user_regs
> *regs,
> return;
> }
>
> +/*
> + * At this point, we know that the stage1 translation table is in the
> MMIO
> + * region. This is not expected by Xen and thus it forwards the abort to
> the
> + * guest.
> + */
> +if ( info->dabt.s1ptw )
> +{
> +info->dabt_instr.state = INSTR_ERROR;
> +return;
> +}
> +
> /*
> * Armv8 processor does not provide a valid syndrome for decoding some
> * instructions. So in order to process these instructions, Xen must
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 120c971b0f..e491ca15d7 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1923,6 +1923,7 @@ static void do_trap_stage2_abort_guest(struct
> cpu_user_regs *regs,
> bool is_data = (hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
> mmio_info_t info;
> enum io_state state;
> +bool check_mmio_region = true;
>
> /*
> * If this bit has been set, it means that this stage-2 abort is caused
> @@ -1987,7 +1988,16 @@ static void do_trap_stage2_abort_guest(struct
> cpu_user_regs *regs,
> */
> if ( !is_data || !info.dabt.valid )
> {
> -if ( check_p2m(is_data, gpa) )
> +/*
> + * If the translation fault was caused due to access to stage 1
> + * translation table, then we try to set the translation table
> entry
> + * for page1 translation table (assuming that it is in the non
> mmio
^ stage1
Do you mean to say maybe:
If the translation fault was caused by an access to stage 1 translation
table, then no need to change the stage 2 p2m.
?
> + * region).
> + */
> +if ( xabt.s1ptw )
> +check_mmio_region = false;
> +
> +if ( check_p2m((is_data && check_mmio_region), gpa) )
> return;
>
> /*
> --
> 2.17.1
>
[ovmf test] 168387: regressions - FAIL
flight 168387 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168387/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 28 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days8 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
[xen-unstable test] 168369: regressions - FAIL
flight 168369 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/168369/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 168328 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit2 20 guest-localmigrate/x10 fail pass in 168349 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168328 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168328 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168328 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168328 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168328 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 168328 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168328 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168328 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168328 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168328 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168328 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168328 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168328 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass 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-xsm 15 migrate-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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-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-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 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-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 test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass
[ovmf test] 168385: regressions - FAIL
flight 168385 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168385/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 27 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days7 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
Re: [XEN v9 1/4] xen/arm64: Decode ldr/str post increment operations
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> At the moment, Xen does not decode any of the arm64 instructions. This
> means that when hsr_dabt.isv == 0, Xen cannot handle those instructions.
> This will lead to Xen to abort the guests (from which those instructions
> originate).
>
> With this patch, Xen is able to decode ldr/str post indexing instructions.
> These are a subset of instructions for which hsr_dabt.isv == 0.
>
> The following instructions are now supported by Xen :-
> 1. ldr x2,[x1],#8
> 2. ldr w2,[x1],#-4
> 3. ldr x2,[x1],#-8
> 4. ldr w2,[x1],#4
> 5. ldrhw2,[x1],#2
> 6. ldrbw2,[x1],#1
> 7. str x2,[x1],#8
> 8. str w2,[x1],#-4
> 9. strhw2,[x1],#2
> 10. strbw2,[x1],#1
>
> In the subsequent patch, decode_arm64() will get invoked when
> hsr_dabt.isv == 0.
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Stefano Stabellini
> ---
>
> Changelog :-
>
> v2..v5 - Mentioned in the cover letter.
>
> v6 - 1. Fixed the code style issues as mentioned in v5.
>
> v7 - No change.
>
> v8 - 1. Removed some un-necessary header files inclusion.
> 2. Some style changes pointed out in v7.
>
> v9 - 1. Rebased on top of the master.
> 2. Renamed psr_mode_is_32bit to regs_mode_is_32bit.
>
> xen/arch/arm/decode.c | 79 -
> xen/arch/arm/decode.h | 48 +---
> xen/arch/arm/include/asm/mmio.h | 4 ++
> xen/arch/arm/io.c | 2 +-
> 4 files changed, 124 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
> index 792c2e92a7..3add87e83a 100644
> --- a/xen/arch/arm/decode.c
> +++ b/xen/arch/arm/decode.c
> @@ -84,6 +84,78 @@ bad_thumb2:
> return 1;
> }
>
> +static int decode_arm64(register_t pc, mmio_info_t *info)
> +{
> +union instr opcode = {0};
> +struct hsr_dabt *dabt = >dabt;
> +struct instr_details *dabt_instr = >dabt_instr;
> +
> +if ( raw_copy_from_guest(, (void * __user)pc, sizeof
> (opcode)) )
> +{
> +gprintk(XENLOG_ERR, "Could not copy the instruction from PC\n");
> +return 1;
> +}
> +
> +/*
> + * Refer Arm v8 ARM DDI 0487G.b, Page - C6-1107
> + * "Shared decode for all encodings" (under ldr immediate)
> + * If n == t && n != 31, then the return value is implementation defined
> + * (can be WBSUPPRESS, UNKNOWN, UNDEFINED or NOP). Thus, we do not
> support
> + * this. This holds true for ldrb/ldrh immediate as well.
> + *
> + * Also refer, Page - C6-1384, the above described behaviour is same for
> + * str immediate. This holds true for strb/strh immediate as well
> + */
> +if ( (opcode.ldr_str.rn == opcode.ldr_str.rt) && (opcode.ldr_str.rn !=
> 31) )
> +{
> +gprintk(XENLOG_ERR, "Rn should not be equal to Rt except for r31\n");
> +goto bad_loadstore;
> +}
> +
> +/* First, let's check for the fixed values */
> +if ( (opcode.value & POST_INDEX_FIXED_MASK) != POST_INDEX_FIXED_VALUE )
> +{
> +gprintk(XENLOG_ERR,
> +"Decoding instruction 0x%x is not supported\n",
> opcode.value);
> +goto bad_loadstore;
> +}
> +
> +if ( opcode.ldr_str.v != 0 )
> +{
> +gprintk(XENLOG_ERR,
> +"ldr/str post indexing for vector types are not
> supported\n");
> +goto bad_loadstore;
> +}
> +
> +/* Check for STR (immediate) */
> +if ( opcode.ldr_str.opc == 0 )
> +dabt->write = 1;
> +/* Check for LDR (immediate) */
> +else if ( opcode.ldr_str.opc == 1 )
> +dabt->write = 0;
> +else
> +{
> +gprintk(XENLOG_ERR,
> +"Decoding ldr/str post indexing is not supported for this
> variant\n");
> +goto bad_loadstore;
> +}
> +
> +gprintk(XENLOG_INFO,
> +"opcode->ldr_str.rt = 0x%x, opcode->ldr_str.size = 0x%x,
> opcode->ldr_str.imm9 = %d\n",
> +opcode.ldr_str.rt, opcode.ldr_str.size, opcode.ldr_str.imm9);
> +
> +update_dabt(dabt, opcode.ldr_str.rt, opcode.ldr_str.size, false);
> +
> +dabt_instr->rn = opcode.ldr_str.rn;
> +dabt_instr->imm9 = opcode.ldr_str.imm9;
> +
> +return 0;
> +
> + bad_loadstore:
> +gprintk(XENLOG_ERR, "unhandled Arm instruction 0x%x\n", opcode.value);
> +return 1;
> +}
> +
> static int decode_thumb(register_t pc, struct hsr_dabt *dabt)
> {
> uint16_t instr;
> @@ -150,10 +222,13 @@ bad_thumb:
> return 1;
> }
>
> -int decode_instruction(const struct cpu_user_regs *regs, struct hsr_dabt
> *dabt)
> +int decode_instruction(const struct cpu_user_regs *regs, mmio_info_t *info)
> {
> if ( is_32bit_domain(current->domain) && regs->cpsr & PSR_THUMB )
> -return decode_thumb(regs->pc, dabt);
> +return decode_thumb(regs->pc, >dabt);
> +
> +if (
Re: [XEN v9 2/4] xen/arm64: io: Support instructions (for which ISS is not valid) on emulated MMIO region using MMIO/ioreq handler
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> When an instruction is trapped in Xen due to translation fault, Xen
> checks if the ISS is invalid (for data abort) or it is an instruction
> abort. If so, Xen tries to resolve the translation fault using p2m page
> tables. In case of data abort, Xen will try to map the mmio region to
> the guest (ie tries to emulate the mmio region).
>
> If the ISS is not valid and it is a data abort, then Xen tries to
> decode the instruction. In case of ioreq, Xen saves the decoding state,
> rn and imm9 to vcpu_io. Whenever the vcpu handles the ioreq successfully,
> it will read the decoding state to determine if the instruction decoded
> was a ldr/str post indexing (ie INSTR_LDR_STR_POSTINDEXING). If so, it
> uses these details to post increment rn.
>
> In case of mmio handler, if the mmio operation was successful, then Xen
> retrives the decoding state, rn and imm9. For state ==
> INSTR_LDR_STR_POSTINDEXING, Xen will update rn.
>
> If there is an error encountered while decoding/executing the instruction,
> Xen will forward the abort to the guest.
>
> Signed-off-by: Ayan Kumar Halder
> ---
>
> Changelog :-
>
> v2..v5 - Mentioned in the cover letter.
>
> v6 - 1. Mantained the decoding state of the instruction. This is used by the
> caller to either abort the guest or retry or ignore or perform read/write on
> the mmio region.
>
> 2. try_decode() invokes decoding for both aarch64 and thumb state. (Previously
> it used to invoke decoding only for aarch64 state). Thus, it handles all the
> checking of the registers before invoking any decoding of instruction.
> try_decode_instruction_invalid_iss() has thus been removed.
>
> 3. Introduced a new field('enum instr_decode_state state') inside
> 'struct instr_details'. This holds the decoding state of the instruction.
> This is later read by the post_increment_register() to determine if rn needs
> to
> be incremented. Also, this is read by the callers of try_decode_instruction()
> to determine if the instruction was valid or ignored or to be retried or
> error or decoded successfully.
>
> 4. Also stored 'instr_details' inside 'struct ioreq'. This enables
> arch_ioreq_complete_mmio() to invoke post_increment_register() without
> decoding
> the instruction again.
>
> 5. Check hsr.dabt.valid in do_trap_stage2_abort_guest(). If it is not valid,
> then decode the instruction. This ensures that try_handle_mmio() is invoked
> only
> when the instruction is either valid or decoded successfully.
>
> 6. Inside do_trap_stage2_abort_guest(), if hsr.dabt.valid is not set, then
> resolve the translation fault before trying to decode the instruction. If
> translation fault is resolved, then return to the guest to execute the
> instruction
> again.
>
>
> v7 - 1. Moved the decoding instruction details ie instr_details from 'struct
> ioreq'
> to 'struct vcpu_io'.
>
> 2. The instruction is decoded only when we get a data abort.
>
> 3. Replaced ASSERT_UNREACHABLE() with domain_crash(). The reason being asserts
> can be disabled in some builds. In this scenario when the guest's cpsr is in
> an
> erroneous state, Xen should crash the guest.
>
> 4. Introduced check_p2m() which invokes p2m_resolve_translation_fault() and
> try_map_mmio() to resolve translation fault by configuring the page tables.
> This
> gets invoked first if ISS is invalid and it is an instruction abort. If it is
> a data abort and hsr.dabt.s1ptw is set or try_handle_mmio() returns
> IO_UNHANDLED,
> then check_p2m() gets invoked again.
>
>
> v8 - 1. Removed the handling of data abort when info->dabt.cache is set. This
> will
> be implemented in a subsequent patch. (Not as part of this series)
>
> 2. When the data abort is due to access to stage 1 translation tables, Xen
> will
> try to fix the mapping of the page table for the corresponding address. If
> this
> returns an error, Xen will abort the guest. Else, it will ask the guest to
> retry
> the instruction.
>
> 3. Changed v->io.info.dabt_instr from pointer to variable. The reason being
> that
> arch_ioreq_complete_mmio() is called from leave_hypervisor_to_guest().
> That is after do_trap_stage2_abort_guest() has been invoked. So the original
> variable will be no longer valid.
>
> 4. Some other style issues pointed out in v7.
>
>
> v9 - 1. Ensure that "Erratum 766422" is handled only when ISS is valid.
>
> 2. Whenever Xen receives and instruction abort or data abort (with invalid
> ISS),
> Xen should first try to resolve the p2m translation fault or see if it it
> needs
> to map a MMIO region. If it succeeds, it should return to the guest to retry
> the
> instruction.
>
> 3. Removed handling of "dabt.s1ptw == 1" aborts. This is addressed in patch3
> as
> it is an existing bug in codebase.
>
> 4. Various style issues pointed by Julien in v8.
>
> xen/arch/arm/arm32/traps.c| 11
> xen/arch/arm/arm64/traps.c| 47
> xen/arch/arm/decode.c
Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb
On Thu, 3 Mar 2022, Christoph Hellwig wrote: > On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote: > > Thinking more about it we actually need to drop the xen_initial_domain() > > check otherwise some cases won't be functional (Dom0 not 1:1 mapped, or > > DomU 1:1 mapped). > > Hmm, but that would be the case even before this series, right? Before this series we only have the xen_swiotlb_detect() check in xen_mm_init, we don't have a second xen_initial_domain() check. The issue is that this series is adding one more xen_initial_domain() check in xen_mm_init.
[xen-unstable-smoke test] 168384: tolerable all pass - PUSHED
flight 168384 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/168384/ 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 b692523fafb39f5f930e1e8a316f7b8cebc9f62a baseline version: xen 3e56754b08871ccceff856ff634731b9b9bccbbe Last test of basis 168374 2022-03-03 14:00:31 Z0 days Testing same since 168384 2022-03-03 20:00:30 Z0 days1 attempts People who touched revisions under test: Julien Grall Michal Orzel 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 3e56754b08..b692523faf b692523fafb39f5f930e1e8a316f7b8cebc9f62a -> smoke
[ovmf test] 168381: regressions - FAIL
flight 168381 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168381/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 26 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days6 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
Re: [PATCH] xen/arm: mm: Encode existing constraints of the memory layout
On 03/03/2022 16:04, Bertrand Marquis wrote: Hi Julien, Hi Bertrand, On 28 Feb 2022, at 10:06, Julien Grall wrote: From: Julien Grall The boot code expects the regions XEN_VIRT_START, FIXMAP_ADDR(0), BOOT_FDT_VIRT_START to use the same 0th (arm64 only) and 1st slot. Add some BUILD_BUG_ON() to confirm that. This is helpful if one wants to re-order the memory layout. Very good idea :-) I actually hit this issue when trying to re-order the memory layout for testing a patch. Signed-off-by: Julien Grall Reviewed-by: Bertrand Marquis Just a small NIT after if you want to do it on commit... I have update the comment and committed the patch. Thanks! Cheers, -- Julien Grall
Re: [PATCH] x86: fold sections in final binaries
Hi Bertrand, On 01/03/2022 13:30, Bertrand Marquis wrote: On 1 Mar 2022, at 08:58, Jan Beulich wrote: On 01.03.2022 09:55, Jan Beulich wrote: Especially when linking a PE binary (xen.efi), standalone output sections are expensive: Often the linker will align the subsequent one on the section alignment boundary (2Mb) when the linker script doesn't otherwise place it. (I haven't been able to derive from observed behavior under what conditions it would not do so.) With gcov enabled (and with gcc11) I'm observing enough sections that, as of quite recently, the resulting image doesn't fit in 16Mb anymore, failing the final ASSERT() in the linker script. (That assertion is slated to go away, but that's a separate change.) Any destructor related sections can be discarded, as we never "exit" the hypervisor. This includes .text.exit, which is referenced from .dtors.*. Constructor related sections need to all be taken care of, not just those with historically used names: .ctors.* and .text.startup is what gcc11 populates. While there re-arrange ordering / sorting to match that used by the linker provided scripts. Finally, for xen.efi only, also discard .note.gnu.*. These are meaningless in a PE binary. Quite likely, while not meaningless there, the section is also of no use in ELF, but keep it there for now. Signed-off-by: Jan Beulich Some of this will likely want mirroring to Arm as well, even if xen.efi there isn't produced by the linker. Sections are better properly folded even for ELF, and constructors not ending up in [__ctors_start,__ctors_end) can surely not do any good. I fully agree with that and it would make sense to do both changes together to avoid differences between x86 and arm unless required. Right now our discard section on arm is a lot shorter and I do not see why we would need any of the sections that are discarded on x86. Me neither. As this needs testing and checking I do not think it makes sense for you to do that right now. @Stefano and Julien: I am ok to create myself a task to sync with x86 in the next weeks/months, what do you think ? I haven't looked in details the exact difference between two linker scripts. After the sync, I would expect to be mostly similar. We also have the RISCv and possibly soon PowerPC. So, I would consider to consolidate the linker scripts if possible. This would help to keep them in sync. Anyway, as discussed on IRC, let's start with updating the Arm linker scripts. We can then look at the differences. Cheers, -- Julien Grall
[Regression] [PATCH] x86: fold sections in final binaries
On 01/03/2022 08:55, Jan Beulich wrote:
> Especially when linking a PE binary (xen.efi), standalone output
> sections are expensive: Often the linker will align the subsequent one
> on the section alignment boundary (2Mb) when the linker script doesn't
> otherwise place it. (I haven't been able to derive from observed
> behavior under what conditions it would not do so.)
>
> With gcov enabled (and with gcc11) I'm observing enough sections that,
> as of quite recently, the resulting image doesn't fit in 16Mb anymore,
> failing the final ASSERT() in the linker script. (That assertion is
> slated to go away, but that's a separate change.)
>
> Any destructor related sections can be discarded, as we never "exit"
> the hypervisor. This includes .text.exit, which is referenced from
> .dtors.*. Constructor related sections need to all be taken care of, not
> just those with historically used names: .ctors.* and .text.startup is
> what gcc11 populates. While there re-arrange ordering / sorting to match
> that used by the linker provided scripts.
>
> Finally, for xen.efi only, also discard .note.gnu.*. These are
> meaningless in a PE binary. Quite likely, while not meaningless there,
> the section is also of no use in ELF, but keep it there for now.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: We also use CONSTRUCTORS for an unknown reason. Documentation for
> ld is quite clear that this is an a.out-only construct.
> Implementation doesn't look to fully match this for ELF, but I'd
> nevertheless be inclined to remove its use.
>
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -194,6 +194,7 @@ SECTIONS
> #endif
> _sinittext = .;
> *(.init.text)
> + *(.text.startup)
> _einittext = .;
> /*
> * Here are the replacement instructions. The linker sticks them
> @@ -258,9 +259,10 @@ SECTIONS
>
> . = ALIGN(8);
> __ctors_start = .;
> - *(.ctors)
> + *(SORT_BY_INIT_PRIORITY(.init_array.*))
> + *(SORT_BY_INIT_PRIORITY(.ctors.*))
> *(.init_array)
> - *(SORT(.init_array.*))
> + *(.ctors)
> __ctors_end = .;
>} PHDR(text)
>
> @@ -404,16 +406,20 @@ SECTIONS
>
>/* Sections to be discarded */
>/DISCARD/ : {
> + *(.text.exit)
> *(.exit.text)
> *(.exit.data)
> *(.exitcall.exit)
> *(.discard)
> *(.discard.*)
> *(.eh_frame)
> + *(.dtors)
> + *(.dtors.*)
> #ifdef EFI
> *(.comment)
> *(.comment.*)
> *(.note.Xen)
> + *(.note.gnu.*)
> #endif
>}
This breaks reliably in Gitlab CI.
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2159059956 (gcc 11)
~Andrew
[ovmf bisection] complete build-i386-xsm
branch xen-unstable xenbranch xen-unstable job build-i386-xsm testid xen-build Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: ovmf https://github.com/tianocore/edk2.git Bug introduced: d3febfd9ade35dc552df6b3607c2b15d26b82867 Bug not present: 84338c0d498555f860a480693ee8647a1795fba3 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/168382/ commit d3febfd9ade35dc552df6b3607c2b15d26b82867 Author: Jason Date: Mon Jan 10 21:46:27 2022 +0800 MdePkg: Replace Opcode with the corresponding instructions. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3790 Replace Opcode with the corresponding instructions. The code changes have been verified with CompareBuild.py tool, which can be used to compare the results of two different EDK II builds to determine if they generate the same binaries. (tool link: https://github.com/mdkinney/edk2/tree/sandbox/CompareBuild) Signed-off-by: Jason Lou Cc: Michael D Kinney Reviewed-by: Liming Gao Cc: Zhiguang Liu For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-i386-xsm.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/ovmf/build-i386-xsm.xen-build --summary-out=tmp/168382.bisection-summary --basis-template=168254 --blessings=real,real-bisect,real-retry ovmf build-i386-xsm xen-build Searching for failure / basis pass: 168377 fail [host=elbling0] / 168254 [host=albana0] 168249 [host=huxelrebe0] 168232 [host=huxelrebe0] 168185 [host=huxelrebe0] 168131 [host=albana0] 168127 [host=huxelrebe0] 168119 [host=albana0] 168115 [host=huxelrebe1] 168074 [host=huxelrebe0] 168048 [host=albana0] 168046 [host=huxelrebe0] 168043 [host=huxelrebe0] 168042 [host=chardonnay1] 168038 [host=huxelrebe0] 168017 [host=albana0] 167989 [host=huxelrebe1] 167980 [host=albana1] 167976 [host=huxelrebe0] 167956 [host=huxelrebe1] 167950 [hos\ t=albana0] 167946 [host=fiano0] 167940 [host=albana0] 167933 [host=albana0] 167929 [host=huxelrebe1] 167919 [host=elbling1] 167907 [host=albana1] 167803 [host=huxelrebe0] 167775 [host=albana0] 167760 [host=fiano0] 167754 [host=albana0] 167729 [host=albana1] 167727 [host=huxelrebe0] 167689 [host=fiano0] 167685 [host=chardonnay1] 167651 [host=albana0] 167636 [host=fiano0] 167627 [host=albana0] 167601 [host=albana1] 167598 [host=huxelrebe0] 167559 [host=huxelrebe0] 167555 [host=huxelrebe0] 167552 [\ host=albana0] 167535 [host=chardonnay1] 167527 [host=chardonnay1] 167522 [host=huxelrebe0] 167513 [host=albana1] 167487 [host=huxelrebe1] 167465 [host=albana1] 167463 [host=huxelrebe0] 167450 [host=fiano1] 167445 [host=chardonnay0] 167436 [host=pinot0] 167419 [host=huxelrebe1] 167414 [host=albana1] 167409 [host=albana0] 167394 [host=albana1] 167393 [host=albana1] 167392 [host=albana1] 167391 [host=albana1] 167379 [host=huxelrebe0] 167377 [host=huxelrebe1] 167239 [host=huxelrebe0] 167237 [host=al\ bana0] 167231 [host=albana0] 167225 [host=albana0] 167122 [host=huxelrebe1] 167104 [host=albana0] 167081 [host=albana0] 166961 [host=albana0] 166951 [host=pinot0] 166949 [host=pinot0] 166826 [host=albana0] 166360 ok. Failure / basis pass flights: 168377 / 166360 (tree with no url: minios) Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 589d51df260465e2561979b8a988e77b0f32a6e8 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42 d239552ce7220e448ae81f41515138f7b9e3c4db faecea18d252f97c6ad41f0f457566ff2c125b8d Basis pass 4c7ce0d285bc7fd593718fd5dec02e136cbfad8e 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b6e539830bf45e2d7a6bd86ddfdf003088b173b0 64f37cc530f144e53c190c9e8209a51b58fd5c43 be12fcca8b784e456df3adedbffe657d753c5ff9 Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#4c7ce0d285bc7fd593718fd5dec02e136cbfad8e-589d51df260465e2561979b8a988e77b0f32a6e8 git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#b6e539830bf45e2d7a6bd86ddfdf003088b173b0-a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42 git://xenbits.xen.org/osstest/seabios.git#64f37cc530f144e53c190c9e8209a51b58fd5c\ 43-d239552ce7220e448ae81f41515138f7b9e3c4db
Re: [PATCH v2] xen/arm: gic: Introduce GIC_PRI_{IRQ/IPI}_ALL
Hi,
On 02/03/2022 09:59, Michal Orzel wrote:
Introduce macros GIC_PRI_IRQ_ALL and GIC_PRI_IPI_ALL to be used in all
the places where we want to set default priority for all the offsets
in interrupt priority register. This will improve readability and
allow to get rid of introducing variables just to store this value.
Take the opportunity to mark GIC_PRI_{IRQ/IPI} as unsigned values
to suppress static analyzer warnings as they are used in expressions
exceeding integer range (shifting into signed bit). Modify also other
priority related macros to be coherent.
Signed-off-by: Michal Orzel
Acked-by: Julien Grall
I have committed the patch. Thanks!
Cheers,
--
Julien Grall
Re: Proposal for Porting Xen to Armv8-R64 - DraftA
Hi Wei,
On 03/03/2022 02:06, Wei Chen wrote:
-Original Message-
From: Julien Grall
Sent: 2022年3月2日 20:00
To: Wei Chen ; xen-devel@lists.xenproject.org; Stefano
Stabellini
Cc: Bertrand Marquis ; Penny Zheng
; Henry Wang ; nd
Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
On 01/03/2022 07:51, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2022年2月26日 4:55
To: Wei Chen ; xen-devel@lists.xenproject.org;
Stefano
Stabellini
Cc: Bertrand Marquis ; Penny Zheng
; Henry Wang ; nd
Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
### 1.2. Xen Challenges with PMSA Virtualization
Xen is PMSA unaware Type-1 Hypervisor, it will need modifications to
run
with an MPU and host multiple guest OSes.
- No MMU at EL2:
- No EL2 Stage 1 address translation
- Xen provides fixed ARM64 virtual memory layout as basis of
EL2
stage 1 address translation, which is not applicable on
MPU
system,
where there is no virtual addressing. As a result, any
operation
involving transition from PA to VA, like ioremap, needs
modification
on MPU system.
- Xen's run-time addresses are the same as the link time
addresses.
- Enable PIC (position-independent code) on a real-time
target
processor probably very rare.
Aside the assembly boot code and UEFI stub, Xen already runs at the
same
address as it was linked.
But the difference is that, base on MMU, we can use the same link
address
for all platforms. But on MPU system, we can't do it in the same way.
I agree that we currently use the same link address for all the
platforms. But this is also a problem when using MMU because EL2 has a
single TTBR.
At the moment we are switching page-tables with the MMU which is not
safe. Instead we need to turn out the MMU off, switch page-tables and
then turn on the MMU. This means we need to have an identity mapping of
Xen in the page-tables. Assuming Xen is not relocated, the identity
mapping may clash with Xen (or the rest of the virtual address map).
Is this the same reason we create a dummy reloc section for EFI loader?
The relocations for the EFI loader are necessary because IIRC it is
running with virt == phys.
But this brings to all sort of problem:
https://lore.kernel.org/all/20171221145521.29526-1-julien.gr...@linaro.org/
[...]
Some callers that want to change a memory's attribute will set them.
Something like
ioremap_nocache. I am not sure is this what you had asked : )
I am a bit confused. If ioremap_nocache() can change the attribute, then
why would ioremap_attr() not be able to do it?
MMU based iorepmap_ can use a new VA and new PTE to do this. But for
MPU, we can't do it, except you change the whole MPU region's attribute.
The reasons are:
1. For V8R PMSA, one physical address only be existed one MPU region.
2. There's not enough MPU regions for us to split one MPU region to
multiple MPU regions (changed pages region and unmodified pages regions).
Ok. I think we should at least check the attributes requested match the
one in the MPU.
if ( CACHE_ATTR_need_change )
return NULL;
return (void *)pa;
}
static inline void __iomem *ioremap_nocache(...)
{
return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
}
static inline void __iomem *ioremap_cache(...)
{
return ioremap_attr(start, len, PAGE_HYPERVISOR);
}
static inline void __iomem *ioremap_wc(...)
{
return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
}
void *ioremap(...)
{
return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
}
```
4. For `alternative`, it depends on `vmap` too.
The only reason we depend on vmap() is because the map the sections
*text read-only and we enforce WnX. For VMSA, it would be possible to
avoid vmap() with some rework. I don't know for PMSA.
For PMSA, we still enforce WnX. For your use case, I assume it's
alternative.
It still may have some possibility to avoid vmap(). But there may be
some
security issues. We had thought to disable MPU -> update xen text ->
enable
MPU to copy VMSA alternative's behavior. The problem with this, however,
is that at some point, all memory is RWX. There maybe some security
risk. > But because it's in init stage, it probably doesn't matter as much
as
I thought.
For boot code, we need to ensure the code is compliant to the Arm Arm.
Other than that, it is OK to have the memory RWX for a short period of
time.
In fact, when we originally boot Xen, we don't enforce WnX. We will
start to enforce when initializing the memory. But there are no blocker
to delay it (other than writing the code :)).
Ah, ok, it seems we
Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb
On 3/3/22 5:57 AM, Christoph Hellwig wrote: On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote: Not for me, I fail to boot with [ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes), total 0 (slots), used 0 (slots) (this is iscsi root so I need the NIC). I bisected it to "x86: remove the IOMMU table infrastructure" but haven't actually looked at the code yet. Thanks. Looks like the sizing is going wrong. Just to confirm, this is dom0 on x86 and no special command line options? Right. module2 /boot/vmlinuz-5.17.0-rc6swiotlb placeholder root=UUID=dbef1262-8c8a-43db-8055-7d9bec7bece0 ro crashkernel=auto LANG=en_US.UTF-8 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 panic=20 nokaslr earlyprintk=xen console=hvc0 loglevel=8 4
[xen-unstable-smoke test] 168374: tolerable all pass - PUSHED
flight 168374 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/168374/ 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 3e56754b08871ccceff856ff634731b9b9bccbbe baseline version: xen 4b7fd8153ddfe95d6d427ff241abb6fdf37e027b Last test of basis 168331 2022-03-02 09:00:26 Z1 days Testing same since 168374 2022-03-03 14:00:31 Z0 days1 attempts People who touched revisions under test: Andrew Cooper 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 4b7fd8153d..3e56754b08 3e56754b08871ccceff856ff634731b9b9bccbbe -> smoke
Re: [ovmf test] 168340: regressions - FAIL
On Wed, Mar 2, 2022 at 12:57 PM osstest service owner wrote: > > flight 168340 ovmf real [real] > http://logs.test-lab.xenproject.org/osstest/logs/168340/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-amd64 6 xen-buildfail REGR. vs. > 168254 > build-amd64-xsm 6 xen-buildfail REGR. vs. > 168254 > build-i3866 xen-buildfail REGR. vs. > 168254 > build-i386-xsm6 xen-buildfail REGR. vs. > 168254 > > commit 6a890db161cd6d378bec3499a1e774db3f5a27a7 > Author: Jason > Date: Mon Jan 10 22:30:29 2022 +0800 > > BaseTools: Upgrade the version of NASM tool > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3790 > > Upgrade the version of NASM tool to avoid compilation errors when > compiling NASM code change. ... > commit bbaa00dd01ed0df30e43a5a89fd2b0433d858b73 > Author: Jason > Date: Mon Jan 10 22:05:47 2022 +0800 > > MdePkg: Remove the macro definitions regarding Opcode. > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3790 > > Remove the macro definitions regarding Opcode because new version of > NASM tool(e.g. v2.15.05) supports the corresponding instructions. > Note: This patch need to be merged after other NASM code change to avoid > compilation errors. Looks like OVMF now expects NASM v2.15.05. -Jason
Re: Network driver domain broken
On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
>
> On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
> > On 03/03/2022 15:54, Andrea Stevanato wrote:
> > > Hi all,
> > >
> > > according to the conversation that I had with royger, aa67b97ed34 broke
> > > the driver domain support.
> > >
> > > What I'm trying to do is to setup networking between guests using driver
> > > domain. Therefore, the guest (driver) has been started with the following
> > > cfg.
> > >
> > > name= "guest0"
> > > kernel = "/media/sd-mmcblk0p1/Image"
> > > ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> > > extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> > > memory = 1024 vcpus = 2
> > > driver_domain = 1
> > >
> > > On guest0 I created the bridge, assigned a static IP and started the
> > > udhcpd on xenbr0 interface.
> > > While the second guest has been started with the following cfg:
> > >
> > > name= "guest1"
> > > kernel = "/media/sd-mmcblk0p1/Image"
> > > ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> > > extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> > > memory = 1024 vcpus = 2
> > > vcpus = 2
> > > vif = [ 'bridge=xenbr0, backend=guest0' ]
> > >
> > > Follows the result of strace xl devd:
> > >
> > > # strace xl devd
> > > execve("/usr/sbin/xl", ["xl", "devd"], 0xdf0420c8 /* 13 vars */) = 0
> > > ioctl(5, _IOC(_IOC_NONE, 0x50, 0, 0x30), 0xe6e41b40) = -1 EPERM
> > > (Operation not permitted)
> > > write(2, "libxl: ", 7libxl: ) = 7
> > > write(2, "error: ", 7error: ) = 7
> > > write(2, "libxl_utils.c:820:libxl_cpu_bitm"...,
> > > 87libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve the
> > > maximum number of cpus) = 87
> > > write(2, "\n", 1
> > > ) = 1
> > > clone(child_stack=NULL,
> > > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> > > child_tidptr=0x9ee7a0e0) = 814
> > > wait4(814, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 814
> > > --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=814, si_uid=0,
> > > si_status=0, si_utime=2, si_stime=2} ---
xl devd is daemonizing, but strace is only following the first
process. Use `strace xl devd -F` to prevent the daemonizing (or
`strace -f xl devd` to follow children).
> > > close(6)= 0
> > > close(5)= 0
> > > munmap(0x9f45f000, 4096)= 0
> > > close(7)= 0
> > > close(10) = 0
> > > close(9)= 0
> > > close(8)= 0
> > > close(11) = 0
> > > close(3)= 0
> > > close(4)= 0
> > > exit_group(0) = ?
> > > +++ exited with 0 +++
> > >
> > > royger told me that it is a BUG and not an issue with my setup. Therefore
> > > here I am.
>
> Just a bit more context: AFAICT the calls to libxl_cpu_bitmap_alloc in
> parse_global_config will prevent xl from being usable on anything
> different than the control domain (due to sysctl only available to
> privileged domains). This is an issue for 'xl devd', as it won't
> start anymore.
These look non-fatal at first glance?
Regards,
Jason
Re: [PATCH] x86emul/test: correct VRNDSCALES{S,D} entries in predicates test
On 03/03/2022 16:48, Jan Beulich wrote: > While benign (because only the decoder is exercised here, whereas a > wrong EVEX.W would cause an exception only during actual emulation), > let's still have correct information in the table entries. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper
Re: [PATCH] x86emul: correct a few scalar insn comments
On 03/03/2022 16:52, Jan Beulich wrote:
> Truly scalar insns (i.e. not VBROADCASTS{S,D}) only every act on
> %xmm. Adjust comments accordingly.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
I wasn't sure of the distinction between hardware domain and control domain for
these commands, but they appear to be blocked at the moment when dom0 executes
them, including a lot at boot. Are you suggesting to use
is_hardware_domain(currd) instead in my diff?
Or should the hardware domain always be able to execute any physdev op command?
(such as to bypass the switch statement entirely)
It looks like hvm_physdev_op() is the only real caller of do_physdev_op(), and
several other commands (besides the ones in the diff below) are also being
blocked by the default case of hvm_physdev_op.
PHYSDEVOP_pirq_eoi_gmfn_v2
PHYSDEVOP_pirq_eoi_gmfn_v1
PHYSDEVOP_IRQ_UNMASK_NOTIFY // legacy?
PHYSDEVOP_apic_read
PHYSDEVOP_apic_write
PHYSDEVOP_alloc_irq_vector
PHYSDEVOP_set_iopl
PHYSDEVOP_set_iobitmap
PHYSDEVOP_restore_msi
PHYSDEVOP_restore_msi_ext
PHYSDEVOP_setup_gsi
PHYSDEVOP_get_free_pirq
PHYSDEVOP_dbgp_op
Thanks
-Alex
On Thu, 2022-03-03 at 17:47 +0100, Jan Beulich wrote:
> On 03.03.2022 17:45, Alex Olson wrote:
> > --- a/xen/arch/x86/hvm/hypercall.c
> > +++ b/xen/arch/x86/hvm/hypercall.c
> > @@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >
> > switch ( cmd )
> > {
> > +
> > +case PHYSDEVOP_manage_pci_add:
> > +case PHYSDEVOP_manage_pci_remove:
> > +case PHYSDEVOP_pci_device_add:
> > +case PHYSDEVOP_pci_device_remove:
> > +case PHYSDEVOP_manage_pci_add_ext:
> > +case PHYSDEVOP_prepare_msix:
> > +case PHYSDEVOP_release_msix:
> > +if ( is_control_domain(currd) )
> > +break;
>
> These are all operations which I think are purposefully permitted to
> be invoked by the hardware domain only. That's where all the devices
> live when they're not passed through to guests.
>
> Jan
>
Re: [XEN PATCH v9 24/30] build: grab common EFI source files in arch specific dir
On 03.03.2022 17:50, Anthony PERARD wrote: > On Thu, Mar 03, 2022 at 05:01:07PM +0100, Jan Beulich wrote: >> On 03.03.2022 16:41, Anthony PERARD wrote: >>> On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote: On 25.01.2022 12:00, Anthony PERARD wrote: > +# Part of the command line transforms $(obj) in to a relative reverted > path. > +# e.g.: It transforms "dir/foo/bar" into successively > +# "dir foo bar", ".. .. ..", "../../.." > +$(obj)/%.c: $(srctree)/common/efi/%.c FORCE > + $(Q)ln -nfs $(subst $(space),/,$(patsubst %,..,$(subst /, > ,$(obj/common/efi/$(>>> What is the "reverted" about in the comment? Also (nit) I think you want s/in to/into/. >>> >>> I've tried to described in the single word that the result is a relative >>> path that goes in the opposite direction to the original relative path. >>> Instead of going down, it goes up the hierarchy of directories. >>> Maybe "reversed" would be better? Do you have other suggestion? >> >> I'd simply omit the word. In case you're fine with that, I'd be happy >> to adjust while committing. > > I think that would sound kind of strange. $(obj) is already a relative > path. It would probably be better to just drop the end of the sentence > in that case. With the example showing what is happening, that would > probably be enough. The sentence would then be: > > # Part of the command line transforms $(obj). > # e.g.: It transforms "dir/foo/bar" into successively > # "dir foo bar", ".. .. ..", "../../.." Fine with me. Then: Acked-by: Jan Beulich Jan
[PATCH] x86emul: correct a few scalar insn comments
Truly scalar insns (i.e. not VBROADCASTS{S,D}) only every act on
%xmm. Adjust comments accordingly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7608,8 +7608,8 @@ x86_emulate(
#ifndef X86EMUL_NO_SIMD
case X86EMUL_OPC_VEX_66(0x0f3a, 0x08): /* vroundps
$imm8,{x,y}mm/mem,{x,y}mm */
case X86EMUL_OPC_VEX_66(0x0f3a, 0x09): /* vroundpd
$imm8,{x,y}mm/mem,{x,y}mm */
-case X86EMUL_OPC_VEX_66(0x0f3a, 0x0a): /* vroundss
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
-case X86EMUL_OPC_VEX_66(0x0f3a, 0x0b): /* vroundsd
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
+case X86EMUL_OPC_VEX_66(0x0f3a, 0x0a): /* vroundss $imm8,xmm/mem,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f3a, 0x0b): /* vroundsd $imm8,xmm/mem,xmm,xmm */
case X86EMUL_OPC_VEX_66(0x0f3a, 0x0c): /* vblendps
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
case X86EMUL_OPC_VEX_66(0x0f3a, 0x0d): /* vblendpd
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
case X86EMUL_OPC_VEX_66(0x0f3a, 0x40): /* vdpps
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
@@ -10576,8 +10576,8 @@ x86_emulate(
host_and_vcpu_must_have(sse4_1);
goto simd_0f3a_common;
-case X86EMUL_OPC_EVEX_66(0x0f3a, 0x0a): /* vrndscaless
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-case X86EMUL_OPC_EVEX_66(0x0f3a, 0x0b): /* vrndscalesd
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x0a): /* vrndscaless
$imm8,xmm/mem,xmm,xmm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x0b): /* vrndscalesd
$imm8,xmm/mem,xmm,xmm{k} */
generate_exception_if(ea.type != OP_REG && evex.brs, EXC_UD);
/* fall through */
case X86EMUL_OPC_EVEX_66(0x0f3a, 0x08): /* vrndscaleps
$imm8,[xyz]mm/mem,[xyz]mm{k} */
@@ -11063,7 +11063,7 @@ x86_emulate(
break;
case X86EMUL_OPC_EVEX_66(0x0f3a, 0x66): /* vfpclassp{s,d}
$imm8,[xyz]mm/mem,k{k} */
-case X86EMUL_OPC_EVEX_66(0x0f3a, 0x67): /* vfpclasss{s,d}
$imm8,[xyz]mm/mem,k{k} */
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x67): /* vfpclasss{s,d}
$imm8,xmm/mem,k{k} */
host_and_vcpu_must_have(avx512dq);
generate_exception_if(!evex.r || !evex.R || evex.z, EXC_UD);
if ( !(b & 1) )
Re: [XEN PATCH v9 24/30] build: grab common EFI source files in arch specific dir
On Thu, Mar 03, 2022 at 05:01:07PM +0100, Jan Beulich wrote: > On 03.03.2022 16:41, Anthony PERARD wrote: > > On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote: > >> On 25.01.2022 12:00, Anthony PERARD wrote: > >>> +# Part of the command line transforms $(obj) in to a relative reverted > >>> path. > >>> +# e.g.: It transforms "dir/foo/bar" into successively > >>> +# "dir foo bar", ".. .. ..", "../../.." > >>> +$(obj)/%.c: $(srctree)/common/efi/%.c FORCE > >>> + $(Q)ln -nfs $(subst $(space),/,$(patsubst %,..,$(subst /, > >>> ,$(obj/common/efi/$( >> > >> What is the "reverted" about in the comment? Also (nit) I think you want > >> s/in to/into/. > > > > I've tried to described in the single word that the result is a relative > > path that goes in the opposite direction to the original relative path. > > Instead of going down, it goes up the hierarchy of directories. > > Maybe "reversed" would be better? Do you have other suggestion? > > I'd simply omit the word. In case you're fine with that, I'd be happy > to adjust while committing. I think that would sound kind of strange. $(obj) is already a relative path. It would probably be better to just drop the end of the sentence in that case. With the example showing what is happening, that would probably be enough. The sentence would then be: # Part of the command line transforms $(obj). # e.g.: It transforms "dir/foo/bar" into successively # "dir foo bar", ".. .. ..", "../../.." -- Anthony PERARD
[ovmf test] 168377: regressions - FAIL
flight 168377 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168377/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 25 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days5 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
[PATCH] x86emul/test: correct VRNDSCALES{S,D} entries in predicates test
While benign (because only the decoder is exercised here, whereas a
wrong EVEX.W would cause an exception only during actual emulation),
let's still have correct information in the table entries.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1974,8 +1974,8 @@ static const struct evex {
{ { 0x05 }, 3, T, R, pfx_66, W1, Ln }, /* vpermilpd */
{ { 0x08 }, 3, T, R, pfx_66, W0, Ln }, /* vrndscaleps */
{ { 0x09 }, 3, T, R, pfx_66, W1, Ln }, /* vrndscalepd */
-{ { 0x0a }, 3, T, R, pfx_66, WIG, LIG }, /* vrndscaless */
-{ { 0x0b }, 3, T, R, pfx_66, WIG, LIG }, /* vrndscalesd */
+{ { 0x0a }, 3, T, R, pfx_66, W0, LIG }, /* vrndscaless */
+{ { 0x0b }, 3, T, R, pfx_66, W1, LIG }, /* vrndscalesd */
{ { 0x0f }, 3, T, R, pfx_66, WIG, Ln }, /* vpalignr */
{ { 0x14 }, 3, T, W, pfx_66, WIG, L0 }, /* vpextrb */
{ { 0x15 }, 3, T, W, pfx_66, WIG, L0 }, /* vpextrw */
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
On 03.03.2022 17:45, Alex Olson wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> switch ( cmd )
> {
> +
> +case PHYSDEVOP_manage_pci_add:
> +case PHYSDEVOP_manage_pci_remove:
> +case PHYSDEVOP_pci_device_add:
> +case PHYSDEVOP_pci_device_remove:
> +case PHYSDEVOP_manage_pci_add_ext:
> +case PHYSDEVOP_prepare_msix:
> +case PHYSDEVOP_release_msix:
> +if ( is_control_domain(currd) )
> +break;
These are all operations which I think are purposefully permitted to
be invoked by the hardware domain only. That's where all the devices
live when they're not passed through to guests.
Jan
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
Hi Roger,
Thanks for the patches. In trying them out, I found some other PHYSDEVOP
commands that were being blocked by the "default" case and were being failed
with -ENOSYS...
Would something like the change below make sense? Or is defaulting to failure
incorrect? (I saw denials for the "add" commands, and also added the
remove/release commands for symmetry).
With this change, I was able to achieve a functional virtual function passed
through to a HVM domain with PVH dom0.
Thanks
-Alex
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index b8becab475..6abaa626a3 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd )
{
+
+case PHYSDEVOP_manage_pci_add:
+case PHYSDEVOP_manage_pci_remove:
+case PHYSDEVOP_pci_device_add:
+case PHYSDEVOP_pci_device_remove:
+case PHYSDEVOP_manage_pci_add_ext:
+case PHYSDEVOP_prepare_msix:
+case PHYSDEVOP_release_msix:
+if ( is_control_domain(currd) )
+break;
+
case PHYSDEVOP_map_pirq:
case PHYSDEVOP_unmap_pirq:
/*
On Thu, 2022-03-03 at 11:30 +0100, Roger Pau Monne wrote:
> Control domains (including domains having control over a single other
> guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
> bindings of interrupts from devices assigned to the controlled guest.
>
> As such relax the check for HVM based guests and allow the usage of
> the hypercalls for any control domains. Note that further safety
> checks will be performed in order to assert that the current domain
> has the right permissions against the target of the hypercall.
>
> Reported-by: Alex Olson
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/hvm/hypercall.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index 030243810e..9128e4d025 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> case PHYSDEVOP_map_pirq:
> case PHYSDEVOP_unmap_pirq:
> +/*
> + * Control domain (and domains controlling others) need to use
> + * PHYSDEVOP_{un,}map_pirq in order to setup interrupts for
> passthrough
> + * devices on behalf of other guests.
> + */
> +if ( is_control_domain(currd) || currd->target )
> +break;
> case PHYSDEVOP_eoi:
> case PHYSDEVOP_irq_status_query:
> case PHYSDEVOP_get_free_pirq:
Re: [PATCH 06/12] MIPS/octeon: use swiotlb_init instead of open coding it
On Tue, Mar 01, 2022 at 12:53:05PM +0200, Christoph Hellwig wrote: > Use the generic swiotlb initialization helper instead of open coding it. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/cavium-octeon/dma-octeon.c | 15 ++- > arch/mips/pci/pci-octeon.c | 2 +- > 2 files changed, 3 insertions(+), 14 deletions(-) Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v4 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86
On 03/03/2022 11:37, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 02.03.2022 16:00, Jane Malalane wrote:
>> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
>> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
>> and x2apic, on x86 hardware.
>> No such features are currently implemented on AMD hardware.
>>
>> For that purpose, also add an arch-specific "capabilities" parameter
>> to struct xen_sysctl_physinfo.
>>
>> Note that this interface is intended to be compatible with AMD so that
>> AVIC support can be introduced in a future patch. Unlike Intel that
>> has multiple controls for APIC Virtualization, AMD has one global
>> 'AVIC Enable' control bit, so fine-graining of APIC virtualization
>> control cannot be done on a common interface. Therefore, for xAPIC HW
>> assisted virtualization support to be reported, HW must support
>> virtualize_apic_accesses as well as apic_reg_virt.
>
> Okay, here you now describe _what_ is being implemented, but I'm
> afraid it still lacks justification (beyond making this re-usable for
> AVIC, which imo can only be a secondary goal). You actually say ...
>
>> For x2APIC HW
>> assisted virtualization reporting, virtualize_x2apic_mode must be
>> supported alongside apic_reg_virt and virtual_intr_delivery.
>>
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Jane Malalane
>>
>> v4:
>> * Fallback to the original v2/v1 conditions for setting
>> assisted_xapic_available and assisted_x2apic_available so that in
>> the future APIC virtualization can be exposed on AMD hardware
>> since fine-graining of "AVIC" is not supported, i.e., AMD solely
>> uses "AVIC Enable". This also means that sysctl mimics what's
>> exposed in CPUID.
>
> ... more here: You claim similarity with CPUID. That's a possible route,
> but we need to be clear that these CPUID flags are optimization hints
> for the guest to use, while the new control is intended to be a functional
> one. Hence it's not obvious that CPUID wants following, and not instead
> the conditionals used in vmx_vlapic_msr_changed() (or yet something else).
>
> What's worse though: What you say is true for x2APIC, but not for xAPIC.
> Which effectively is in line with vmx_vlapic_msr_changed() and CPUID
> handling also agreeing as far as x2APIC is concerned, but disagreeing on
> the xAPIC side. I can only once again try to express that it may well be
> that pre-existing code wants adjusting before actually making the changes
> you're after.
I've been thinking about this. Considering what you say, I propose:
- having assisted_x2apic_available = cpu_has_vmx_virtualize_x2apic_mode
&& (cpu_has_vmx_apic_reg_virt || cpu_has_vmx_virtual_intr_delivery).
This would mean that on Intel CPUs has_assisted_x2apic==1 would signify
that there is at least "some" assistance*, whereas on AMD it would
signify that there is full assistance (assistance here meaning no VM-exits).
* apic_reg_virt prevents VM exits on execution of RDMSR and
virtual_intr_delivery prevents VM exits on execution of RDMSR, from what
I've gathered.
- having assisted_xapic_available = cpu_has_vmx_virtualize_apic_accesses
&& cpu_has_vmx_apic_reg_virt because apic_reg_virt is neccessary for
"any" assistance.
- Currently, the code only sets SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE if
"some" assistance is guaranteed but sets
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES even if no assistance is
guaranteed. So the adjustment to the pre-existing code that I propose is
adding cpu_has_vmx_apic_reg_virt to the initial check in
vmx_vlapic_msr_changed():
void vmx_vlapic_msr_changed(struct vcpu *v)
{
int virtualize_x2apic_mode;
struct vlapic *vlapic = vcpu_vlapic(v);
unsigned int msr;
virtualize_x2apic_mode = ((cpu_has_vmx_apic_reg_virt ||
cpu_has_vmx_virtual_intr_delivery) &&
cpu_has_vmx_virtualize_x2apic_mode);
if ( !cpu_has_vmx_virtualize_apic_accesses &&
+ !cpu_has_vmx_apic_reg_virt &&
!virtualize_x2apic_mode )
return;
which would then eventually just be what I currently have:
+if ( !has_assisted_xapic(v->domain) &&
+ !has_assisted_x2apic(v->domain) )
return;
So, essentially, the only difference from v4 would be
assisted_x2apic_available = (cpu_has_vmx_virtualize_x2apic_mode &&
(cpu_has_vmx_apic_reg_virt ||
cpu_has_vmx_virtual_intr_delivery));
sysctl would now coincide with CPUID for xAPIC but not x2APIC (for CPUID
the condition is the AND of all features unlike the
assisted_x2apic_available proposed). IOW, it would follow the
conditionals used in vmx_vlapic_msr_changed(), if we take the change to
vmx_vlapic_msr_changed() above.
Thank you,
Jane.
Re: Network driver domain broken
On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
> On 03/03/2022 15:54, Andrea Stevanato wrote:
> > Hi all,
> >
> > according to the conversation that I had with royger, aa67b97ed34 broke
> > the driver domain support.
> >
> > What I'm trying to do is to setup networking between guests using driver
> > domain. Therefore, the guest (driver) has been started with the following
> > cfg.
> >
> > name = "guest0"
> > kernel = "/media/sd-mmcblk0p1/Image"
> > ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> > extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> > memory = 1024 vcpus = 2
> > driver_domain = 1
> >
> > On guest0 I created the bridge, assigned a static IP and started the udhcpd
> > on xenbr0 interface.
> > While the second guest has been started with the following cfg:
> >
> > name = "guest1"
> > kernel = "/media/sd-mmcblk0p1/Image"
> > ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> > extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> > memory = 1024 vcpus = 2
> > vcpus = 2
> > vif = [ 'bridge=xenbr0, backend=guest0' ]
> >
> > Follows the result of strace xl devd:
> >
> > # strace xl devd
> > execve("/usr/sbin/xl", ["xl", "devd"], 0xdf0420c8 /* 13 vars */) = 0
> > brk(NULL) = 0xeaf3b000
> > faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file
> > or directory)
> > openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> > fstat(3, {st_mode=S_IFREG|0644, st_size=7840, ...}) = 0
> > mmap(NULL, 7840, PROT_READ, MAP_PRIVATE, 3, 0) = 0x9f45e000
> > close(3)= 0
> > openat(AT_FDCWD, "/usr/lib/libxlutil.so.4.14", O_RDONLY|O_CLOEXEC) = 3
> > read(3,
> > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0200\0\0\0\0\0\0"...,
> > 832) = 832
> > fstat(3, {st_mode=S_IFREG|0755, st_size=68168, ...}) = 0
> > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> > 0x9f45c000
> > mmap(NULL, 131784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> > 0x9f41
> > mprotect(0x9f41f000, 65536, PROT_NONE) = 0
> > mmap(0x9f42f000, 8192, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x9f42f000
> > close(3)= 0
> > openat(AT_FDCWD, "/usr/lib/libxenlight.so.4.14", O_RDONLY|O_CLOEXEC) = 3
> > read(3,
> > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0`\16\2\0\0\0\0\0"...,
> > 832) = 832
> > fstat(3, {st_mode=S_IFREG|0755, st_size=861848, ...}) = 0
> > mmap(NULL, 925752, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> > 0x9f32d000
> > mprotect(0x9f3fa000, 61440, PROT_NONE) = 0
> > mmap(0x9f409000, 24576, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xcc000) = 0x9f409000
> > mmap(0x9f40f000, 56, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f40f000
> > close(3)= 0
> > openat(AT_FDCWD, "/usr/lib/libxentoollog.so.1", O_RDONLY|O_CLOEXEC) = 3
> > read(3,
> > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0P\r\0\0\0\0\0\0"..., 832)
> > = 832
> > fstat(3, {st_mode=S_IFREG|0755, st_size=10368, ...}) = 0
> > mmap(NULL, 73904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> > 0x9f31a000
> > mprotect(0x9f31c000, 61440, PROT_NONE) = 0
> > mmap(0x9f32b000, 8192, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x9f32b000
> > close(3)= 0
> > openat(AT_FDCWD, "/usr/lib/libyajl.so.2", O_RDONLY|O_CLOEXEC) = 3
> > read(3,
> > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\320\22\0\0\0\0\0\0"...,
> > 832) = 832
> > fstat(3, {st_mode=S_IFREG|0755, st_size=38728, ...}) = 0
> > mmap(NULL, 102416, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> > 0x9f30
> > mprotect(0x9f309000, 61440, PROT_NONE) = 0
> > mmap(0x9f318000, 8192, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x9f318000
> > close(3)= 0
> > openat(AT_FDCWD, "/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
> > read(3,
> > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\300j\0\0\0\0\0\0"...,
> > 832) = 832
> > fstat(3, {st_mode=S_IFREG|0755, st_size=113184, ...}) = 0
> > mmap(NULL, 192872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> > 0x9f2d
> > mprotect(0x9f2ea000, 65536, PROT_NONE) = 0
> > mmap(0x9f2fa000, 8192, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x9f2fa000
> > mmap(0x9f2fc000, 12648, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f2fc000
> > close(3)= 0
> > openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> > read(3,
> > "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\320I\2\0\0\0\0\0"...,
> > 832) = 832
> > fstat(3,
Re: [PATCH v2 1/3] xen/vpci: msix: move x86 specific code to x86 file
Hi Jan,
> On 1 Mar 2022, at 1:55 pm, Jan Beulich wrote:
>
> On 01.03.2022 14:34, Rahul Singh wrote:
>>> On 24 Feb 2022, at 2:57 pm, Jan Beulich wrote:
>>>
>>> On 15.02.2022 16:25, Rahul Singh wrote:
vpci/msix.c file will be used for arm architecture when vpci msix
support will be added to ARM, but there is x86 specific code in this
file.
Move x86 specific code to the x86/hvm/vmsi.c file to make sure common
code will be used for other architecture.
>>>
>>> Could you provide some criteria by which code is considered x86-specific
>>> (or not)? For example ...
>>
>> Code moved to x86 file is based on criteria that either the code will be
>> unusable or will be different
>> for ARM when MSIX support will be introduce for ARM.
>
> That's a very abstract statement, which you can't really derive any
> judgement from. It'll be necessary to see in how far the code is
> indeed different. After all PCI, MSI, and MSI-X are largely arch-
> agnostic.
>
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -925,4 +925,106 @@ int vpci_msix_arch_print(const struct vpci_msix
*msix)
return 0;
}
+
+int vpci_make_msix_hole(const struct pci_dev *pdev)
+{
+struct domain *d = pdev->domain;
+unsigned int i;
+
+if ( !pdev->vpci->msix )
+return 0;
+
+/* Make sure there's a hole for the MSIX table/PBA in the p2m. */
+for ( i = 0; i < ARRAY_SIZE(pdev->vpci->msix->tables); i++ )
+{
+unsigned long start = PFN_DOWN(vmsix_table_addr(pdev->vpci, i));
+unsigned long end = PFN_DOWN(vmsix_table_addr(pdev->vpci, i) +
+ vmsix_table_size(pdev->vpci, i) - 1);
+
+for ( ; start <= end; start++ )
+{
+p2m_type_t t;
+mfn_t mfn = get_gfn_query(d, start, );
+
+switch ( t )
+{
+case p2m_mmio_dm:
+case p2m_invalid:
+break;
+case p2m_mmio_direct:
+if ( mfn_x(mfn) == start )
+{
+clear_identity_p2m_entry(d, start);
+break;
+}
+/* fallthrough. */
+default:
+put_gfn(d, start);
+gprintk(XENLOG_WARNING,
+"%pp: existing mapping (mfn: %" PRI_mfn
+"type: %d) at %#lx clobbers MSIX MMIO area\n",
+>sbdf, mfn_x(mfn), t, start);
+return -EEXIST;
+}
+put_gfn(d, start);
+}
+}
+
+return 0;
+}
>>>
>>> ... nothing in this function looks to be x86-specific, except maybe
>>> functions like clear_identity_p2m_entry() may not currently be available
>>> on Arm. But this doesn't make the code x86-specific.
>>
>> I will maybe be wrong but what I understand from the code is that for x86
>> if there is no p2m entries setup for the region, accesses to them will be
>> trapped
>> into the hypervisor and can be handled by specific MMIO handler.
>>
>> But for ARM when we are registering the MMIO handler we have to provide
>> the GPA also for the MMIO handler.
>
> Question is: Is this just an effect resulting from different implementation,
> or an inherent requirement? In the former case, harmonizing things may be an
> alternative option.
This is an inherent requirement to provide a GPA when registering the MMIO
handler.
For x86 msix mmio handlers is registered in init_msix(..) function as there is
no requirement
on x86 to provide GPA when registering the handler. Later point of time when
BARs are configured
and memory decoding bit is enabled vpci_make_msix_hole() will clear the
identity mapping for msix
base table address so that access to msix tables will be trapped.
On ARM we need to provide GPA to register the mmio handler and MSIX table base
address is not valid when init_msix() is called as BAR will be configured later
point in time.
Therefore on ARM mmio handler will be registered in function
vpci_make_msix_hole() when
memory decoding bit is enabled.
>
>> For ARM arch vpci_make_msix_hole() will be used to register the MMIO handler
>> for the MSIX MMIO region.
>>
>> int vpci_make_msix_hole(const struct pci_dev *pdev)
>> {
>>struct vpci_msix *msix = pdev->vpci->msix;
>>paddr_t addr,size;
>>
>> for ( int i = 0; msix && i < ARRAY_SIZE(msix->tables); i++ )
>> {
>>
>> addr = vmsix_table_addr(pdev->vpci, i);
>> size = vmsix_table_size(pdev->vpci, i) - 1;
>>
>>
Re: [PATCH] xen/arm: mm: Encode existing constraints of the memory layout
Hi Julien, > On 28 Feb 2022, at 10:06, Julien Grall wrote: > > From: Julien Grall > > The boot code expects the regions XEN_VIRT_START, FIXMAP_ADDR(0), > BOOT_FDT_VIRT_START to use the same 0th (arm64 only) and 1st slot. > > Add some BUILD_BUG_ON() to confirm that. This is helpful if one wants > to re-order the memory layout. Very good idea :-) > > Signed-off-by: Julien Grall Reviewed-by: Bertrand Marquis Just a small NIT after if you want to do it on commit... > --- > xen/arch/arm/mm.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 8a17222109c6..40423a70f0ae 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -211,6 +211,22 @@ static void __init __maybe_unused build_assertions(void) > #ifdef CONFIG_DOMAIN_PAGE > BUILD_BUG_ON(DOMHEAP_VIRT_START & ~FIRST_MASK); > #endif > +/* > + * The boot code expects the regions XEN_VIRT_START, FIXMAP_ADDR(0), > + * BOOT_FDT_VIRT_START to use the same 0th (arm64 only) and 1st > + * slot. NIT: I would just add at the end of the sentence “in the page tables.” Cheers Bertrand > + */ > +#define CHECK_SAME_SLOT(level, virt1, virt2) \ > +BUILD_BUG_ON(level##_table_offset(virt1) != level##_table_offset(virt2)) > + > +#ifdef CONFIG_ARM_64 > +CHECK_SAME_SLOT(zeroeth, XEN_VIRT_START, FIXMAP_ADDR(0)); > +CHECK_SAME_SLOT(zeroeth, XEN_VIRT_START, BOOT_FDT_VIRT_START); > +#endif > +CHECK_SAME_SLOT(first, XEN_VIRT_START, FIXMAP_ADDR(0)); > +CHECK_SAME_SLOT(first, XEN_VIRT_START, BOOT_FDT_VIRT_START); > + > +#undef CHECK_SAME_SLOT > } > > void dump_pt_walk(paddr_t ttbr, paddr_t addr, > -- > 2.32.0 >
Re: Network driver domain broken
On 03/03/2022 15:54, Andrea Stevanato wrote:
Hi all,
according to the conversation that I had with royger, aa67b97ed34 broke the
driver domain support.
What I'm trying to do is to setup networking between guests using driver
domain. Therefore, the guest (driver) has been started with the following cfg.
name = "guest0"
kernel = "/media/sd-mmcblk0p1/Image"
ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
memory = 1024
vcpus = 2
driver_domain = 1
On guest0 I created the bridge, assigned a static IP and started the udhcpd on
xenbr0 interface.
While the second guest has been started with the following cfg:
name = "guest1"
kernel = "/media/sd-mmcblk0p1/Image"
ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
memory = 1024 vcpus = 2
vcpus = 2
vif = [ 'bridge=xenbr0, backend=guest0' ]
Follows the result of strace xl devd:
# strace xl devd
execve("/usr/sbin/xl", ["xl", "devd"], 0xdf0420c8 /* 13 vars */) = 0
brk(NULL) = 0xeaf3b000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7840, ...}) = 0
mmap(NULL, 7840, PROT_READ, MAP_PRIVATE, 3, 0) = 0x9f45e000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxlutil.so.4.14", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0200\0\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=68168, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x9f45c000
mmap(NULL, 131784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f41
mprotect(0x9f41f000, 65536, PROT_NONE) = 0
mmap(0x9f42f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x9f42f000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxenlight.so.4.14", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0`\16\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=861848, ...}) = 0
mmap(NULL, 925752, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f32d000
mprotect(0x9f3fa000, 61440, PROT_NONE) = 0
mmap(0x9f409000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xcc000) = 0x9f409000
mmap(0x9f40f000, 56, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f40f000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxentoollog.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0P\r\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=10368, ...}) = 0
mmap(NULL, 73904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f31a000
mprotect(0x9f31c000, 61440, PROT_NONE) = 0
mmap(0x9f32b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x9f32b000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libyajl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\320\22\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=38728, ...}) = 0
mmap(NULL, 102416, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f30
mprotect(0x9f309000, 61440, PROT_NONE) = 0
mmap(0x9f318000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x9f318000
close(3)= 0
openat(AT_FDCWD, "/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\300j\0\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=113184, ...}) = 0
mmap(NULL, 192872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f2d
mprotect(0x9f2ea000, 65536, PROT_NONE) = 0
mmap(0x9f2fa000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x9f2fa000
mmap(0x9f2fc000, 12648, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f2fc000
close(3)= 0
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\320I\2\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1428872, ...}) = 0
mmap(NULL, 1502000, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f161000
mprotect(0x9f2b8000, 61440, PROT_NONE) = 0
mmap(0x9f2c7000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x156000) = 0x9f2c7000
mmap(0x9f2cd000, 11056, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f2cd000
close(3)= 0
openat(AT_FDCWD,
Re: [XEN PATCH v9 24/30] build: grab common EFI source files in arch specific dir
On 03.03.2022 16:41, Anthony PERARD wrote:
> On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote:
>> On 25.01.2022 12:00, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -77,8 +77,9 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
>>> obj-y += sysctl.o
>>> endif
>>>
>>> -# Allows "clean" to descend into boot/
>>> +# Allows "clean" to descend
>>> subdir- += boot
>>> +subdir- += efi
>>
>> No similar addition is needed for Arm?
>
> No, because Arm already have "obj-$(CONFIG_ARM_64) += efi/", which has
> the same effect on clean.
>
> Make clean doesn't use ${ALL_OBJS} to find out which directory to clean, so
> adding "subdir-" is needed at the moment.
Oh, I see.
>>> --- /dev/null
>>> +++ b/xen/common/efi/efi-common.mk
>>> @@ -0,0 +1,15 @@
>>> +EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o
>>> +EFIOBJ-$(CONFIG_COMPAT) += compat.o
>>> +
>>> +CFLAGS-y += -fshort-wchar
>>> +CFLAGS-y += -iquote $(srctree)/common/efi
>>> +
>>> +# Part of the command line transforms $(obj) in to a relative reverted
>>> path.
>>> +# e.g.: It transforms "dir/foo/bar" into successively
>>> +# "dir foo bar", ".. .. ..", "../../.."
>>> +$(obj)/%.c: $(srctree)/common/efi/%.c FORCE
>>> + $(Q)ln -nfs $(subst $(space),/,$(patsubst %,..,$(subst /,
>>> ,$(obj/common/efi/$(>
>> What is the "reverted" about in the comment? Also (nit) I think you want
>> s/in to/into/.
>
> I've tried to described in the single word that the result is a relative
> path that goes in the opposite direction to the original relative path.
> Instead of going down, it goes up the hierarchy of directories.
> Maybe "reversed" would be better? Do you have other suggestion?
I'd simply omit the word. In case you're fine with that, I'd be happy
to adjust while committing.
Jan
Re: [XEN PATCH v2 16/29] libs,tools/include: Clean "clean" targets
On Thu, Mar 03, 2022 at 09:21:48AM +0100, Juergen Gross wrote: > On 25.02.22 16:13, Anthony PERARD wrote: > > diff --git a/tools/include/Makefile b/tools/include/Makefile > > index d965987f55..3a03a0b0fa 100644 > > --- a/tools/include/Makefile > > +++ b/tools/include/Makefile > > @@ -82,6 +82,7 @@ uninstall: > > clean: > > rm -rf xen xen-xsm acpi > > $(MAKE) -C xen-foreign clean > > + rm -f _*.h > > Use $(RM) instead? OTOH this could be done in a patch of its own > switching all rm -f instances to $(RM). This isn't really something that I think matter. Per GNU make's manual, "rm" need to exist. Without it part of the build system could be broken. Also setting $(RM) to something other than "rm -f" isn't going to work well either. So whether we use $(RM) or `rm -f` shouldn't matter. All of that to say that I'm not necessarily change one for the other. It mostly depends on context. Also, I might change those "clean:" rules later to collect files to clean in a variable $(_FILES), when that will be possible. > Reviewed-by: Juergen Gross Thanks, -- Anthony PERARD
Re: [XEN PATCH v9 24/30] build: grab common EFI source files in arch specific dir
On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote:
> On 25.01.2022 12:00, Anthony PERARD wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -77,8 +77,9 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> > obj-y += sysctl.o
> > endif
> >
> > -# Allows "clean" to descend into boot/
> > +# Allows "clean" to descend
> > subdir- += boot
> > +subdir- += efi
>
> No similar addition is needed for Arm?
No, because Arm already have "obj-$(CONFIG_ARM_64) += efi/", which has
the same effect on clean.
Make clean doesn't use ${ALL_OBJS} to find out which directory to clean, so
adding "subdir-" is needed at the moment.
> > --- /dev/null
> > +++ b/xen/common/efi/efi-common.mk
> > @@ -0,0 +1,15 @@
> > +EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o
> > +EFIOBJ-$(CONFIG_COMPAT) += compat.o
> > +
> > +CFLAGS-y += -fshort-wchar
> > +CFLAGS-y += -iquote $(srctree)/common/efi
> > +
> > +# Part of the command line transforms $(obj) in to a relative reverted
> > path.
> > +# e.g.: It transforms "dir/foo/bar" into successively
> > +# "dir foo bar", ".. .. ..", "../../.."
> > +$(obj)/%.c: $(srctree)/common/efi/%.c FORCE
> > + $(Q)ln -nfs $(subst $(space),/,$(patsubst %,..,$(subst /,
> > ,$(obj/common/efi/$(
> What is the "reverted" about in the comment? Also (nit) I think you want
> s/in to/into/.
I've tried to described in the single word that the result is a relative
path that goes in the opposite direction to the original relative path.
Instead of going down, it goes up the hierarchy of directories.
Maybe "reversed" would be better? Do you have other suggestion?
Thanks,
--
Anthony PERARD
Re: [PATCH] build: export potentially overridden tool chain components
On 28/02/2022 16:11, Jan Beulich wrote:
> When overriding the tool chain via CROSS_COMPILE, the resulting
> components need to be made available to, in particular (but not limited
> to) the check-endbr.sh script. Note that we don't allow overriding
> ADDR2LINE yet; this would first require additions to some config/*.mk
> before it would make sense to export the resulting variable as well.
>
> The lack of NM exporting was apparently not a problem so far, but add it
> at this occasion as well - we're using the tool, after all.
>
> Fixes: 4d037425dccf ("x86: Build check for embedded endbr64 instructions")
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Re: [PATCH] build: export potentially overridden tool chain components
Hi Jan,
> On 28 Feb 2022, at 16:11, Jan Beulich wrote:
>
> When overriding the tool chain via CROSS_COMPILE, the resulting
> components need to be made available to, in particular (but not limited
> to) the check-endbr.sh script. Note that we don't allow overriding
> ADDR2LINE yet; this would first require additions to some config/*.mk
> before it would make sense to export the resulting variable as well.
>
> The lack of NM exporting was apparently not a problem so far, but add it
> at this occasion as well - we're using the tool, after all.
>
> Fixes: 4d037425dccf ("x86: Build check for embedded endbr64 instructions")
> Signed-off-by: Jan Beulich
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
>
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -55,7 +55,7 @@ export TARGET_ARCH := $(shell echo $
> # Allow someone to change their config file
> export KCONFIG_CONFIG ?= .config
>
> -export CC CXX LD
> +export CC CXX LD NM OBJCOPY OBJDUMP
>
> export TARGET := xen
>
>
>
Re: [XEN PATCH v9 23/30] build,x86: remove the need for build32.mk
On Thu, Mar 03, 2022 at 11:29:36AM +0100, Jan Beulich wrote: > On 25.01.2022 12:00, Anthony PERARD wrote: > > Rework "arch/x86/boot/Makefile" to allow it to build both file > > "cmdline.S" and "reloc.S" without "build32.mk". > > > > These will now use the main rules for "%.o: %.c", and thus generate a > > dependency file. (We will not need to track the dependency manually > > anymore.) > > > > But for that, we need to override the main CFLAGS to do a 32bit build. > > We introduce XEN_TREEWIDE_CFLAGS which can be reused in boot/Makefile, > > and avoid the need to reparse Config.mk with a different value for > > XEN_TARGET_ARCH. From this new $(XEN_TREEWIDE_CFLAGS), we only need to > > change -m64 to have the 32bit flags. Then those are applied only to > > "cmdline.o" and "reloc.o". > > > > Specifically apply the rule "%.S: %.bin" to both cmdline.S and reloc.S > > to avoid make trying to regenerate other %.S files with it. > > > > There is no change expected to the resulting "cmdline.S" and > > "reloc.S", only the *.o file changes as their symbol for FILE goes > > from "cmdline.c" to "arch/x86//cmdline.c". (No idea why "boot" is > > missing from the string.) (I've only check with GCC, not clang.) > > > > Signed-off-by: Anthony PERARD > > Reviewed-by: Jan Beulich > with one question, just to be sure I understand things right: > > > --- a/xen/arch/x86/boot/Makefile > > +++ b/xen/arch/x86/boot/Makefile > > @@ -1,25 +1,42 @@ > > obj-bin-y += head.o > > +head-srcs := cmdline.S reloc.S > > > > -DEFS_H_DEPS = $(abs_srctree)/$(src)/defs.h > > $(abs_srctree)/include/xen/stdbool.h > > +nocov-y += $(head-srcs:.S=.o) > > +noubsan-y += $(head-srcs:.S=.o) > > +targets += $(head-srcs:.S=.o) > > > > -CMDLINE_DEPS = $(DEFS_H_DEPS) $(abs_srctree)/$(src)/video.h \ > > - $(BASEDIR)/include/xen/kconfig.h \ > > - $(BASEDIR)/include/generated/autoconf.h > > +head-srcs := $(addprefix $(obj)/, $(head-srcs)) > > > > -RELOC_DEPS = $(DEFS_H_DEPS) \ > > -$(BASEDIR)/include/generated/autoconf.h \ > > -$(BASEDIR)/include/xen/kconfig.h \ > > -$(BASEDIR)/include/xen/multiboot.h \ > > -$(BASEDIR)/include/xen/multiboot2.h \ > > -$(BASEDIR)/include/xen/const.h \ > > -$(BASEDIR)/include/public/arch-x86/hvm/start_info.h > > +$(obj)/head.o: $(head-srcs) > > > > -$(obj)/head.o: $(obj)/cmdline.S $(obj)/reloc.S > > +CFLAGS_x86_32 := $(subst -m64,-m32 -march=i686,$(XEN_TREEWIDE_CFLAGS)) > > +$(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > +CFLAGS_x86_32 += -Werror -fno-builtin -g0 -msoft-float > > +CFLAGS_x86_32 += -I$(srctree)/include > > > > -$(obj)/cmdline.S: $(src)/cmdline.c $(CMDLINE_DEPS) $(src)/build32.lds > > - $(MAKE) -f $(abs_srctree)/$(src)/build32.mk -C $(obj) $(@F) > > CMDLINE_DEPS="$(CMDLINE_DEPS)" > > +# override for 32bit binaries > > +$(head-srcs:.S=.o): CFLAGS_stack_boundary := > > You overriding CFLAGS_stack_boundary but not object_label_flags is > merely because the latter has no (unwanted) effect on the compilation? Yes. Thanks, -- Anthony PERARD
Re: Kconfig: defaults for UNSUPPORTED
Hi, > On 1 Mar 2022, at 08:24, Jan Beulich wrote: > > Hello, > > when commit d96e5e6c1214 added UNSUPPORTED, it left x86'es TBOOT > default untouched. This means we default-enable an unsupported > setting, which doesn't look to be what's generally wanted. I can > see defaulting to DEBUG as reasonable, and SCHED_NULL's defaulting > to enabled when PV_SHIM can imo also be justified (there it's > rather that UNSUPPORTED is inapplicable for the shim case, and the > adjustment was also done subsequent to the named commit). > > Shouldn't we therefore have a rule of thumb that UNSUPPORTED > entries only ever have no "default" (implying "n") or default to > no more than DEBUG? In general that would definitely make sense yes even though there might be exceptions due to for example a dependency to an other unsupported parameter. I would definitely agree with this. Cheers Bertrand > > Thanks for opinions, > Jan > >
Re: [XEN PATCH v9 26/30] build: replace $(BASEDIR) and use $(srctree)
On Tue, Jan 25, 2022 at 11:00:59AM +, Anthony PERARD wrote: > $(srctree) is a better description for the source directory than > $(BASEDIR) that has been used for both source and build directory > (which where the same). > > This adds $(srctree) to a few path where make's VPATH=$(srctree) won't > apply. And replace $(BASEDIR) by $(srctree). > > Introduce "$(srcdir)" as a shortcut for "$(srctree)/$(src)" as the > later is used often enough. > > Signed-off-by: Anthony PERARD > Acked-by: Jan Beulich This patch is now missing two hunks due to recent changes in the tree: diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 11ac0d5e28a4..1ab9db3424c2 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -153,7 +153,7 @@ $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds >$(@D)/$(@F).map rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]* ifeq ($(CONFIG_XEN_IBT),y) - $(SHELL) $(BASEDIR)/tools/check-endbr.sh $@ + $(SHELL) $(srctree)/tools/check-endbr.sh $@ endif $(obj)/note.o: $(TARGET)-syms @@ -226,7 +226,7 @@ endif | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort >$(@D)/$(@F).map rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]* ifeq ($(CONFIG_XEN_IBT),y) - $(SHELL) $(BASEDIR)/tools/check-endbr.sh $@ + $(SHELL) $(srctree)/tools/check-endbr.sh $@ endif else $(TARGET).efi: FORCE -- Anthony PERARD
Re: [PATCH] x86/build: use --orphan-handling linker option if available
On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
> On 03.03.2022 12:19, Roger Pau Monné wrote:
> > On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> >> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
> >> binaries"), arbitrary sections appearing without our linker script
> >> placing them explicitly can be a problem. Have the linker make us aware
> >> of such sections, so we would know that the script needs adjusting.
> >>
> >> To deal with the resulting warnings:
> >> - Retain .note.* explicitly for ELF, and discard all of them (except the
> >> earlier consumed .note.gnu.build-id) for PE/COFF.
> >> - Have explicit statements for .got, .plt, and alike and add assertions
> >> that they're empty. No output sections will be created for these as
> >> long as they remain empty (or else the assertions would cause early
> >> failure anyway).
> >> - Collect all .rela.* into a single section, with again an assertion
> >> added for the resulting section to be empty.
> >> - Extend the enumerating of .debug_* to ELF. Note that for Clang adding
> >> of .debug_macinfo is necessary. Amend this by its Dwarf5 counterpart,
> >> .debug_macro, then as well (albeit more may need adding for full
> >> coverage).
> >>
> >> Suggested-by: Roger Pau Monné
> >> Signed-off-by: Jan Beulich
> >> ---
> >> I would have wanted to make this generic (by putting it in
> >> xen/Makefile), but the option cannot be added to LDFLAGS, or else
> >> there'll be a flood of warnings with $(LD) -r. (Besides, adding to
> >> LDFLAGS would mean use of the option on every linker pass rather than
> >> just the last one.)
> >>
> >> Retaining of .note in xen-syms is under question. Plus if we want to
> >> retain all notes, the question is whether they wouldn't better go into
> >> .init.rodata. But .note.gnu.build-id shouldn't move there, and when
> >> notes are discontiguous all intermediate space will also be assigned to
> >> the NOTE segment, thus making the contents useless for tools going just
> >> by program headers.
> >>
> >> Newer Clang may require yet more .debug_* to be added. I've only played
> >> with versions 5 and 7 so far.
> >>
> >> Unless we would finally drop all mentioning of Stabs sections, we may
> >> want to extend to there what is done for Dwarf here (allowing the EFI
> >> conditional around the section to also go away).
> >>
> >> See also https://sourceware.org/pipermail/binutils/2022-March/119922.html.
> >
> > LLD 13.0.0 also warns about:
> >
> > ld: warning: :(.symtab) is being placed in '.symtab'
> > ld: warning: :(.shstrtab) is being placed in '.shstrtab'
> > ld: warning: :(.strtab) is being placed in '.strtab'
> >
> > So seeing your mail where you mention GNU ld not needing those, I
> > think we would need to add them anyway for LLVM ld.
>
> Hmm, that's ugly. How do I recognize LLVM ld? I can't simply use a
> pre-processor conditional keying off of __clang__, as that used as the
> compiler doesn't mean their ld is also in use (typically the case on
> Linux).
Hard to tell, `ld -v` for LLD will typically contain '^LLD' I think,
but I don't really like matching on human readable output like this.
> I also don't want to add these uniformly, for now knowing what
> side effects their mentioning might have with GNU ld.
Wouldn't it be fine to just place them at the end, just like it's
done by default by ld?
Are you worried about not getting the proper type if mentioned in the
linker script?
> >> --- a/xen/arch/x86/Makefile
> >> +++ b/xen/arch/x86/Makefile
> >> @@ -120,6 +120,8 @@ syms-warn-dup-y := --warn-dup
> >> syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
> >> syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
> >>
> >> +orphan-handling-$(call ld-option,--orphan-handling=warn) +=
> >> --orphan-handling=warn
> >
> > Might be better to place in xen/Kconfig with the CC checks?
>
> Well. I've tried to stay away from complaining if people introduce
> new tool chain capability checks in Kconfig. But I'm not going to
> add any myself (unless things would become really inconsistent) up
> and until we have actually properly discussed the upsides and
> downsides of either model. Doing this via email (see the "Kconfig
> vs tool chain capabilities" thread started in August 2020) has
> proven to not lead anywhere. I'm really hoping that we can finally
> sort this in Bukarest.
>
> > I'm also wondering whether we could add the flag here into XEN_LDFLAGS
> > and EFI_LDFLAGS, as those options are only used together with the
> > linker script in the targets on the Makefile.
>
> Not for XEN_LDFLAGS at least, and undesirable for EFI_LDFLAGS. See
> the respective post-commit message remark.
But the calls to LD in order to generate $(TARGET)-syms do not use -r,
and are all using the linker script, so it should be fine to use
--orphan-handling=warn there?
Could we do something like:
$(TARGET)-syms: XEN_LDFLAGS += ...
And similar for
[linux-linus test] 168355: tolerable FAIL - PUSHED
flight 168355 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/168355/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168346 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168346 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168346 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168346 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168346 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168346 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168346 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168346 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-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-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 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-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-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 15 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 version targeted for testing: linux5859a2b1991101d6b978f3feb5325dad39421f29 baseline version: linux92ebf5f91b4dd5156886d2509202be0fb4230dfd Last test of basis 168346 2022-03-02 20:40:06 Z0 days Testing same since 168355 2022-03-03 05:19:36 Z0 days1 attempts People who touched revisions under test: "Eric W. Biederman" Eric W. Biederman Johannes Stezenbach Julian Braha Linus Torvalds Randy Dunlap Russell King (Oracle) jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64
Network driver domain broken
Hi all,
according to the conversation that I had with royger, aa67b97ed34 broke the
driver domain support.
What I'm trying to do is to setup networking between guests using driver
domain. Therefore, the guest (driver) has been started with the following cfg.
name = "guest0"
kernel = "/media/sd-mmcblk0p1/Image"
ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
memory = 1024
vcpus = 2
driver_domain = 1
On guest0 I created the bridge, assigned a static IP and started the udhcpd on
xenbr0 interface.
While the second guest has been started with the following cfg:
name = "guest1"
kernel = "/media/sd-mmcblk0p1/Image"
ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
memory = 1024 vcpus = 2
vcpus = 2
vif = [ 'bridge=xenbr0, backend=guest0' ]
Follows the result of strace xl devd:
# strace xl devd
execve("/usr/sbin/xl", ["xl", "devd"], 0xdf0420c8 /* 13 vars */) = 0
brk(NULL) = 0xeaf3b000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7840, ...}) = 0
mmap(NULL, 7840, PROT_READ, MAP_PRIVATE, 3, 0) = 0x9f45e000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxlutil.so.4.14", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0200\0\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=68168, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x9f45c000
mmap(NULL, 131784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f41
mprotect(0x9f41f000, 65536, PROT_NONE) = 0
mmap(0x9f42f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x9f42f000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxenlight.so.4.14", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0`\16\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=861848, ...}) = 0
mmap(NULL, 925752, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f32d000
mprotect(0x9f3fa000, 61440, PROT_NONE) = 0
mmap(0x9f409000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xcc000) = 0x9f409000
mmap(0x9f40f000, 56, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f40f000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxentoollog.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0P\r\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=10368, ...}) = 0
mmap(NULL, 73904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f31a000
mprotect(0x9f31c000, 61440, PROT_NONE) = 0
mmap(0x9f32b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x9f32b000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libyajl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\320\22\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=38728, ...}) = 0
mmap(NULL, 102416, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f30
mprotect(0x9f309000, 61440, PROT_NONE) = 0
mmap(0x9f318000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x9f318000
close(3)= 0
openat(AT_FDCWD, "/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\300j\0\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=113184, ...}) = 0
mmap(NULL, 192872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f2d
mprotect(0x9f2ea000, 65536, PROT_NONE) = 0
mmap(0x9f2fa000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x9f2fa000
mmap(0x9f2fc000, 12648, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f2fc000
close(3)= 0
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\320I\2\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1428872, ...}) = 0
mmap(NULL, 1502000, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x9f161000
mprotect(0x9f2b8000, 61440, PROT_NONE) = 0
mmap(0x9f2c7000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x156000) = 0x9f2c7000
mmap(0x9f2cd000, 11056, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9f2cd000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libxenevtchn.so.1", O_RDONLY|O_CLOEXEC) = 3
[ovmf test] 168372: regressions - FAIL
flight 168372 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 24 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days4 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
[ovmf test] 168366: regressions - FAIL
flight 168366 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168366/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 23 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days3 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
[xen-unstable test] 168349: regressions - FAIL
flight 168349 xen-unstable real [real] flight 168361 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168349/ http://logs.test-lab.xenproject.org/osstest/logs/168361/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 168328 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168328 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168328 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168328 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168328 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168328 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 168328 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168328 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168328 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168328 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168328 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168328 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168328 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168328 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-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-xsm 15 migrate-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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-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-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 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-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 test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15
Re: [PATCH] x86/tboot: adjust Kconfig default
On 3/3/22 07:24, Jan Beulich wrote: > On 03.03.2022 13:16, Daniel P. Smith wrote: >> >> On 3/3/22 07:03, Jan Beulich wrote: >>> On 03.03.2022 12:50, Daniel P. Smith wrote: On 3/3/22 04:49, Jan Beulich wrote: > We shouldn't include unsupported code by default, with not even a means > for its building to be disabled. Convert the dependency from merely > affecting the prompt's visibility to a real one. > > Signed-off-by: Jan Beulich > --- > We could of course go further and make the default also account for > DEBUG, as is done elsewhere. As in you would like to adjust the default based on whether DEBUG is on or not? I guess my question is what motivation is there to adjust this selection if DEBUG is enabled or disabled? >>> >>> This is to have functionality enabled unless overridden in debug builds. >> >> Maybe I am misunderstanding you. If I am wanting to debug either TXT or >> a configuration with TXT on and I adjust my config to turn on debug, >> then I would have to go turn TXT back on. Is that correct? If that is >> the correct understanding, honestly that concerns me because if that is >> being done for other config options, it would create the situation where >> turning on debug to track down an issue would result in a different >> configuration than the one I was experiencing the issue. > > In the scenario that you describe (aiui), the default setting wouldn't > make a difference: If you alter an existing .config by turning on DEBUG, > the .config's existing TBOOT setting wouldn't change. Defaults matter > only for items which have no values recorded yet. Plus - I'm suggesting > to turn the option _on_ by default when DEBUG=y, not off. Okay, I am following now. Apologies for taking so long. I think that would be fine as TXT/tboot should be benign if enabled but tboot is not used to start Xen. v/r, dps
Re: [PATCH 2/3] hvm/irq: tighten check in hvm_domain_use_pirq
On 03.03.2022 11:30, Roger Pau Monne wrote:
> hvm_domain_use_pirq checking whether the passed domain is an HVM
> guests is pointless, as all calls originate from HVM only paths.
> Instead check whether the domain has PIRQ support in order to avoid
> further checks.
I agree with this, but I wonder ...
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -30,7 +30,7 @@
>
> bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq)
> {
> -return is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND;
> +return has_pirq(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND;
... whether there can be a non-NULL pirq in the first place for a
!has_pirq() domain. Judging from e.g. hvm_inject_msi() it looks like
this might be possible, but perhaps wrongly so?
Jan
Re: [PATCH 1/3] evtchn/hvm: do not allow binding PIRQs unless supported
On 03.03.2022 11:30, Roger Pau Monne wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -556,6 +556,9 @@ static int evtchn_bind_pirq(evtchn_bind_pirq_t *bind)
> intport = 0, rc;
> unsigned int pirq = bind->pirq;
>
> +if ( is_hvm_domain(d) && !has_pirq(d) )
Arm doesn't have has_pirq(), so some further conditional will be needed,
or has_pirq() needs adding there.
Doesn't this want further accompanying with adjustments to the checks in
physdev_{,un}map_pirq()?
> +return -ENOSYS;
-EOPNOTSUPP please.
Jan
[ovmf test] 168364: regressions - FAIL
flight 168364 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168364/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 22 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days2 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
Re: [PATCH] x86/tboot: adjust Kconfig default
On 03.03.2022 13:16, Daniel P. Smith wrote: > > On 3/3/22 07:03, Jan Beulich wrote: >> On 03.03.2022 12:50, Daniel P. Smith wrote: >>> On 3/3/22 04:49, Jan Beulich wrote: We shouldn't include unsupported code by default, with not even a means for its building to be disabled. Convert the dependency from merely affecting the prompt's visibility to a real one. Signed-off-by: Jan Beulich --- We could of course go further and make the default also account for DEBUG, as is done elsewhere. >>> >>> As in you would like to adjust the default based on whether DEBUG is on >>> or not? I guess my question is what motivation is there to adjust this >>> selection if DEBUG is enabled or disabled? >> >> This is to have functionality enabled unless overridden in debug builds. > > Maybe I am misunderstanding you. If I am wanting to debug either TXT or > a configuration with TXT on and I adjust my config to turn on debug, > then I would have to go turn TXT back on. Is that correct? If that is > the correct understanding, honestly that concerns me because if that is > being done for other config options, it would create the situation where > turning on debug to track down an issue would result in a different > configuration than the one I was experiencing the issue. In the scenario that you describe (aiui), the default setting wouldn't make a difference: If you alter an existing .config by turning on DEBUG, the .config's existing TBOOT setting wouldn't change. Defaults matter only for items which have no values recorded yet. Plus - I'm suggesting to turn the option _on_ by default when DEBUG=y, not off. Jan
Re: [PATCH] x86/tboot: adjust Kconfig default
On 3/3/22 07:03, Jan Beulich wrote: On 03.03.2022 12:50, Daniel P. Smith wrote: On 3/3/22 04:49, Jan Beulich wrote: We shouldn't include unsupported code by default, with not even a means for its building to be disabled. Convert the dependency from merely affecting the prompt's visibility to a real one. Signed-off-by: Jan Beulich --- We could of course go further and make the default also account for DEBUG, as is done elsewhere. As in you would like to adjust the default based on whether DEBUG is on or not? I guess my question is what motivation is there to adjust this selection if DEBUG is enabled or disabled? This is to have functionality enabled unless overridden in debug builds. Maybe I am misunderstanding you. If I am wanting to debug either TXT or a configuration with TXT on and I adjust my config to turn on debug, then I would have to go turn TXT back on. Is that correct? If that is the correct understanding, honestly that concerns me because if that is being done for other config options, it would create the situation where turning on debug to track down an issue would result in a different configuration than the one I was experiencing the issue. --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -193,14 +193,15 @@ config HVM_FEP If unsure, say N. config TBOOT - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED - default y if !PV_SHIM_EXCLUSIVE + bool "Xen tboot support (UNSUPPORTED)" + depends on UNSUPPORTED + default !PV_SHIM_EXCLUSIVE select CRYPTO ---help--- Allows support for Trusted Boot using the Intel(R) Trusted Execution Technology (TXT) - If unsure, say Y. + If unsure, stay with the default. choice prompt "Alignment of Xen image" Outside of the debug question, I think the proposed change is good. Reviewed-by: Daniel P. Smith Thanks. I guess there's an 'o' missing though in the email address? Apologies for that, correct I missed the 'o' as I was typing it out. v/r, dps
Re: [PATCH] x86/build: use --orphan-handling linker option if available
On 03.03.2022 12:19, Roger Pau Monné wrote:
> On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
>> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
>> binaries"), arbitrary sections appearing without our linker script
>> placing them explicitly can be a problem. Have the linker make us aware
>> of such sections, so we would know that the script needs adjusting.
>>
>> To deal with the resulting warnings:
>> - Retain .note.* explicitly for ELF, and discard all of them (except the
>> earlier consumed .note.gnu.build-id) for PE/COFF.
>> - Have explicit statements for .got, .plt, and alike and add assertions
>> that they're empty. No output sections will be created for these as
>> long as they remain empty (or else the assertions would cause early
>> failure anyway).
>> - Collect all .rela.* into a single section, with again an assertion
>> added for the resulting section to be empty.
>> - Extend the enumerating of .debug_* to ELF. Note that for Clang adding
>> of .debug_macinfo is necessary. Amend this by its Dwarf5 counterpart,
>> .debug_macro, then as well (albeit more may need adding for full
>> coverage).
>>
>> Suggested-by: Roger Pau Monné
>> Signed-off-by: Jan Beulich
>> ---
>> I would have wanted to make this generic (by putting it in
>> xen/Makefile), but the option cannot be added to LDFLAGS, or else
>> there'll be a flood of warnings with $(LD) -r. (Besides, adding to
>> LDFLAGS would mean use of the option on every linker pass rather than
>> just the last one.)
>>
>> Retaining of .note in xen-syms is under question. Plus if we want to
>> retain all notes, the question is whether they wouldn't better go into
>> .init.rodata. But .note.gnu.build-id shouldn't move there, and when
>> notes are discontiguous all intermediate space will also be assigned to
>> the NOTE segment, thus making the contents useless for tools going just
>> by program headers.
>>
>> Newer Clang may require yet more .debug_* to be added. I've only played
>> with versions 5 and 7 so far.
>>
>> Unless we would finally drop all mentioning of Stabs sections, we may
>> want to extend to there what is done for Dwarf here (allowing the EFI
>> conditional around the section to also go away).
>>
>> See also https://sourceware.org/pipermail/binutils/2022-March/119922.html.
>
> LLD 13.0.0 also warns about:
>
> ld: warning: :(.symtab) is being placed in '.symtab'
> ld: warning: :(.shstrtab) is being placed in '.shstrtab'
> ld: warning: :(.strtab) is being placed in '.strtab'
>
> So seeing your mail where you mention GNU ld not needing those, I
> think we would need to add them anyway for LLVM ld.
Hmm, that's ugly. How do I recognize LLVM ld? I can't simply use a
pre-processor conditional keying off of __clang__, as that used as the
compiler doesn't mean their ld is also in use (typically the case on
Linux). I also don't want to add these uniformly, for now knowing what
side effects their mentioning might have with GNU ld.
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -120,6 +120,8 @@ syms-warn-dup-y := --warn-dup
>> syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
>> syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
>>
>> +orphan-handling-$(call ld-option,--orphan-handling=warn) +=
>> --orphan-handling=warn
>
> Might be better to place in xen/Kconfig with the CC checks?
Well. I've tried to stay away from complaining if people introduce
new tool chain capability checks in Kconfig. But I'm not going to
add any myself (unless things would become really inconsistent) up
and until we have actually properly discussed the upsides and
downsides of either model. Doing this via email (see the "Kconfig
vs tool chain capabilities" thread started in August 2020) has
proven to not lead anywhere. I'm really hoping that we can finally
sort this in Bukarest.
> I'm also wondering whether we could add the flag here into XEN_LDFLAGS
> and EFI_LDFLAGS, as those options are only used together with the
> linker script in the targets on the Makefile.
Not for XEN_LDFLAGS at least, and undesirable for EFI_LDFLAGS. See
the respective post-commit message remark.
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -12,6 +12,12 @@
>> #undef __XEN_VIRT_START
>> #define __XEN_VIRT_START __image_base__
>> #define DECL_SECTION(x) x :
>> +/*
>> + * Use the NOLOAD directive, despite currently ignored by ld for PE output,
>> in
>
> Would you mind adding GNU ld here to avoid confusion?
I've done so, but I'm not sure if implicitly you mean to say that
LLVM ld does honor the directive when linking xen.efi? If that
wasn't the case, it would rather seem misleading to have "GNU"
there. Unless e.g. LLVM ld can't link xen.efi at all ...
Jan
Re: [PATCH] x86/tboot: adjust Kconfig default
On 03.03.2022 12:50, Daniel P. Smith wrote: > On 3/3/22 04:49, Jan Beulich wrote: >> We shouldn't include unsupported code by default, with not even a means >> for its building to be disabled. Convert the dependency from merely >> affecting the prompt's visibility to a real one. >> >> Signed-off-by: Jan Beulich >> --- >> We could of course go further and make the default also account for >> DEBUG, as is done elsewhere. > > As in you would like to adjust the default based on whether DEBUG is on > or not? I guess my question is what motivation is there to adjust this > selection if DEBUG is enabled or disabled? This is to have functionality enabled unless overridden in debug builds. >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -193,14 +193,15 @@ config HVM_FEP >>If unsure, say N. >> >> config TBOOT >> -bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED >> -default y if !PV_SHIM_EXCLUSIVE >> +bool "Xen tboot support (UNSUPPORTED)" >> +depends on UNSUPPORTED >> +default !PV_SHIM_EXCLUSIVE >> select CRYPTO >> ---help--- >>Allows support for Trusted Boot using the Intel(R) Trusted Execution >>Technology (TXT) >> >> - If unsure, say Y. >> + If unsure, stay with the default. >> >> choice >> prompt "Alignment of Xen image" >> > > Outside of the debug question, I think the proposed change is good. > > Reviewed-by: Daniel P. Smith Thanks. I guess there's an 'o' missing though in the email address? Jan
Re: [PATCH v4 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC
On 02.03.2022 16:00, Jane Malalane wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3344,16 +3344,11 @@ static void vmx_install_vlapic_mapping(struct vcpu *v)
>
> void vmx_vlapic_msr_changed(struct vcpu *v)
> {
> -int virtualize_x2apic_mode;
> struct vlapic *vlapic = vcpu_vlapic(v);
> unsigned int msr;
>
> -virtualize_x2apic_mode = ( (cpu_has_vmx_apic_reg_virt ||
> -cpu_has_vmx_virtual_intr_delivery) &&
> - cpu_has_vmx_virtualize_x2apic_mode );
> -
> -if ( !cpu_has_vmx_virtualize_apic_accesses &&
> - !virtualize_x2apic_mode )
> +if ( !has_assisted_xapic(v->domain) &&
> + !has_assisted_x2apic(v->domain) )
> return;
This is not an equivalent replacement: The earlier condition was not the
AND of all three sub-features. This is the reason for ...
> @@ -3363,28 +3358,24 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
> if ( !vlapic_hw_disabled(vlapic) &&
> (vlapic_base_address(vlapic) == APIC_DEFAULT_PHYS_BASE) )
> {
> -if ( virtualize_x2apic_mode && vlapic_x2apic_mode(vlapic) )
> +if ( has_assisted_x2apic(v->domain) && vlapic_x2apic_mode(vlapic) )
> {
> v->arch.hvm.vmx.secondary_exec_control |=
> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
> -if ( cpu_has_vmx_apic_reg_virt )
> -{
> -for ( msr = MSR_X2APIC_FIRST;
> - msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
> -vmx_clear_msr_intercept(v, msr, VMX_MSR_R);
>
> -vmx_set_msr_intercept(v, MSR_X2APIC_PPR, VMX_MSR_R);
> -vmx_set_msr_intercept(v, MSR_X2APIC_TMICT, VMX_MSR_R);
> -vmx_set_msr_intercept(v, MSR_X2APIC_TMCCT, VMX_MSR_R);
> -}
> -if ( cpu_has_vmx_virtual_intr_delivery )
> -{
> -vmx_clear_msr_intercept(v, MSR_X2APIC_TPR, VMX_MSR_W);
> -vmx_clear_msr_intercept(v, MSR_X2APIC_EOI, VMX_MSR_W);
> -vmx_clear_msr_intercept(v, MSR_X2APIC_SELF, VMX_MSR_W);
> -}
> +for ( msr = MSR_X2APIC_FIRST;
> + msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
> +vmx_clear_msr_intercept(v, msr, VMX_MSR_R);
> +
> +vmx_set_msr_intercept(v, MSR_X2APIC_PPR, VMX_MSR_R);
> +vmx_set_msr_intercept(v, MSR_X2APIC_TMICT, VMX_MSR_R);
> +vmx_set_msr_intercept(v, MSR_X2APIC_TMCCT, VMX_MSR_R);
> +
> +vmx_clear_msr_intercept(v, MSR_X2APIC_TPR, VMX_MSR_W);
> +vmx_clear_msr_intercept(v, MSR_X2APIC_EOI, VMX_MSR_W);
> +vmx_clear_msr_intercept(v, MSR_X2APIC_SELF, VMX_MSR_W);
> }
... you wanting to make these adjustments, but at the same time it means
with certain feature combinations we would now intercept all x2APIC MSR
accesses when some don't need intercepting, which may slow things down
for guests.
Just to be clear - the main part of the discussion imo continues to be
needed on patch 1, to sort what dependencies on features we want where.
One that's clear, what's wanted here should be mostly straightforward.
Jan
Re: [PATCH] x86/tboot: adjust Kconfig default
Jan, FYI, I just noticed that Lukasz old intel email was used for this patch. I assume your tree just hasn't picked up the patch with his new email address. Copying him now so he can see your patch. v/r, dps On 3/3/22 06:50, Daniel P. Smith wrote: On 3/3/22 04:49, Jan Beulich wrote: We shouldn't include unsupported code by default, with not even a means for its building to be disabled. Convert the dependency from merely affecting the prompt's visibility to a real one. Signed-off-by: Jan Beulich --- We could of course go further and make the default also account for DEBUG, as is done elsewhere. As in you would like to adjust the default based on whether DEBUG is on or not? I guess my question is what motivation is there to adjust this selection if DEBUG is enabled or disabled? --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -193,14 +193,15 @@ config HVM_FEP If unsure, say N. config TBOOT - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED - default y if !PV_SHIM_EXCLUSIVE + bool "Xen tboot support (UNSUPPORTED)" + depends on UNSUPPORTED + default !PV_SHIM_EXCLUSIVE select CRYPTO ---help--- Allows support for Trusted Boot using the Intel(R) Trusted Execution Technology (TXT) - If unsure, say Y. + If unsure, stay with the default. choice prompt "Alignment of Xen image" Outside of the debug question, I think the proposed change is good. Reviewed-by: Daniel P. Smith
Re: [PATCH] x86/tboot: adjust Kconfig default
On 3/3/22 04:49, Jan Beulich wrote: We shouldn't include unsupported code by default, with not even a means for its building to be disabled. Convert the dependency from merely affecting the prompt's visibility to a real one. Signed-off-by: Jan Beulich --- We could of course go further and make the default also account for DEBUG, as is done elsewhere. As in you would like to adjust the default based on whether DEBUG is on or not? I guess my question is what motivation is there to adjust this selection if DEBUG is enabled or disabled? --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -193,14 +193,15 @@ config HVM_FEP If unsure, say N. config TBOOT - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED - default y if !PV_SHIM_EXCLUSIVE + bool "Xen tboot support (UNSUPPORTED)" + depends on UNSUPPORTED + default !PV_SHIM_EXCLUSIVE select CRYPTO ---help--- Allows support for Trusted Boot using the Intel(R) Trusted Execution Technology (TXT) - If unsure, say Y. + If unsure, stay with the default. choice prompt "Alignment of Xen image" Outside of the debug question, I think the proposed change is good. Reviewed-by: Daniel P. Smith
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
On 03.03.2022 12:40, Roger Pau Monné wrote: > Or do we just require people with split control/hardware domain model > to also use a different XSM policy? I've been under the impression that this is the intended model, yes. Jan
Re: [PATCH] x86/cmdline: Interpret 'vpmu' as a positive boolean
On 03.03.2022 12:15, Andrew Cooper wrote:
> On 03/03/2022 11:04, Jan Beulich wrote:
>> On 03.03.2022 11:48, Andrew Cooper wrote:
>>> On 03/03/2022 07:44, Jan Beulich wrote:
On 02.03.2022 23:11, Andrew Cooper wrote:
> This makes it behave slightly more like a regular boolean option.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> Slightly RFC, because there is no easy way of making the opposite "normal
> boolean" case work for no-vpmu.
There's nothing to do to make this work afaict: Generic command line
handling converts "no-" to "=no" for custom params.
>>> Oh - I'd forgotten that, in which case this patch actually wants to be
>>> simply:
>>>
>>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>>> index adff2d2c77f3..2cea1da781ac 100644
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -162,6 +162,11 @@ static int parse_params(const char *cmdline, const
>>> struct kernel_param *start,
>>> safe_strcpy(opt, "no");
>>> optval = opt;
>>> }
>>> + else if ( !*optval )
>>> + {
>>> + safe_strcpy(opt, "1");
>>> + optval = opt;
>>> + }
>>> rctmp = param->par.func(optval);
>>> break;
>>> case OPT_IGNORE:
>>>
>>> to turn "option\0" into "option=1", no?
>> Iirc extending this to the positive case was deliberately not done, for
>> the risk of breaking custom handlers not expecting the standard boolean
>> forms. We could likely go this route, but only after auditing all custom
>> handlers, I'm afraid.
>
> Well - I've already audited them all once recently. What's once more...
Of course if you did an audit (for this particular property) recently,
that's definitely enough. Feel free to apply my earlier provided R-b
also to this alternative change then.
Jan
> I'll have a go in due course; I'd definitely prefer to avoid special
> casing the positive boolean form in individual handlers.
>
> ~Andrew
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
On Thu, Mar 03, 2022 at 10:45:54AM +, Andrew Cooper wrote:
> On 03/03/2022 10:30, Roger Pau Monne wrote:
> > Control domains (including domains having control over a single other
> > guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
> > bindings of interrupts from devices assigned to the controlled guest.
> >
> > As such relax the check for HVM based guests and allow the usage of
> > the hypercalls for any control domains. Note that further safety
> > checks will be performed in order to assert that the current domain
> > has the right permissions against the target of the hypercall.
> >
> > Reported-by: Alex Olson
> > Reported-by: Andrew Cooper
> > Signed-off-by: Roger Pau Monné
> > ---
> > xen/arch/x86/hvm/hypercall.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> > index 030243810e..9128e4d025 100644
> > --- a/xen/arch/x86/hvm/hypercall.c
> > +++ b/xen/arch/x86/hvm/hypercall.c
> > @@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> > {
> > case PHYSDEVOP_map_pirq:
> > case PHYSDEVOP_unmap_pirq:
> > +/*
> > + * Control domain (and domains controlling others) need to use
> > + * PHYSDEVOP_{un,}map_pirq in order to setup interrupts for
> > passthrough
> > + * devices on behalf of other guests.
> > + */
> > +if ( is_control_domain(currd) || currd->target )
> > +break;
>
> Hmm. In a split control/hardware domain model, then qemu is in the
> hardware domain rather than the control domain. I suspect this wants
> extending with || is_hardware_domain(currd).
The binding of GSIs is exclusively done by the control domain because
those are static and known at domain creation. The mapping and
binding of MSI interrupts is however done by QEMU at runtime, so it
needs extending to the hardware domain.
However just extending here won't be enough: we would also need to
modify xsm_default_action, as currently XSM_DM_PRIV will only be
allowed if src->target == target or is_control_domain(src).
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 58afc1d589..ac40a24a22 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -88,7 +88,8 @@ static always_inline int xsm_default_action(
}
/* fall through */
case XSM_DM_PRIV:
-if ( target && evaluate_nospec(src->target == target) )
+if ( is_hardware_domain(src) ||
+ (target && evaluate_nospec(src->target == target)) )
return 0;
/* fall through */
case XSM_PRIV:
That would however also give the hardware domain access to XSM_TARGET
and XSM_XS_PRIV operations that where previously forbidden.
Or do we just require people with split control/hardware domain model
to also use a different XSM policy?
> Also, the sentence about later safety checks really ought to be in this
> source comment too.
Will add.
Thanks, Roger.
Re: [PATCH v4 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86
On 02.03.2022 16:00, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
> and x2apic, on x86 hardware.
> No such features are currently implemented on AMD hardware.
>
> For that purpose, also add an arch-specific "capabilities" parameter
> to struct xen_sysctl_physinfo.
>
> Note that this interface is intended to be compatible with AMD so that
> AVIC support can be introduced in a future patch. Unlike Intel that
> has multiple controls for APIC Virtualization, AMD has one global
> 'AVIC Enable' control bit, so fine-graining of APIC virtualization
> control cannot be done on a common interface. Therefore, for xAPIC HW
> assisted virtualization support to be reported, HW must support
> virtualize_apic_accesses as well as apic_reg_virt.
Okay, here you now describe _what_ is being implemented, but I'm
afraid it still lacks justification (beyond making this re-usable for
AVIC, which imo can only be a secondary goal). You actually say ...
> For x2APIC HW
> assisted virtualization reporting, virtualize_x2apic_mode must be
> supported alongside apic_reg_virt and virtual_intr_delivery.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jane Malalane
>
> v4:
> * Fallback to the original v2/v1 conditions for setting
>assisted_xapic_available and assisted_x2apic_available so that in
>the future APIC virtualization can be exposed on AMD hardware
>since fine-graining of "AVIC" is not supported, i.e., AMD solely
>uses "AVIC Enable". This also means that sysctl mimics what's
>exposed in CPUID.
... more here: You claim similarity with CPUID. That's a possible route,
but we need to be clear that these CPUID flags are optimization hints
for the guest to use, while the new control is intended to be a functional
one. Hence it's not obvious that CPUID wants following, and not instead
the conditionals used in vmx_vlapic_msr_changed() (or yet something else).
What's worse though: What you say is true for x2APIC, but not for xAPIC.
Which effectively is in line with vmx_vlapic_msr_changed() and CPUID
handling also agreeing as far as x2APIC is concerned, but disagreeing on
the xAPIC side. I can only once again try to express that it may well be
that pre-existing code wants adjusting before actually making the changes
you're after.
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -343,6 +343,16 @@ static int vmx_init_vmcs_config(bool bsp)
> MSR_IA32_VMX_PROCBASED_CTLS2, );
> }
>
> +/* Check whether hardware supports accelerated xapic and x2apic. */
> +if ( bsp )
> +{
> +assisted_xapic_available = (cpu_has_vmx_virtualize_apic_accesses &&
> +cpu_has_vmx_apic_reg_virt);
> +assisted_x2apic_available = (cpu_has_vmx_virtualize_x2apic_mode &&
> + cpu_has_vmx_apic_reg_virt &&
> + cpu_has_vmx_virtual_intr_delivery);
> +}
If the conditions were to stay as they are, I'd like to suggest pulling
out the cpu_has_vmx_apic_reg_virt into the enclosing if()'s condition.
Additionally I think the comment wants to contain a pointer to what this
wants to remain in sync with. That other side may then want to gain a
comment pointing back here.
Jan
Re: [PATCH v3 0/7] (mainly) xz imports from Linux
On 03/03/2022 10:03, Jan Beulich wrote: > 1: xz: add fall-through comments to a switch statement > 2: xz: fix XZ_DYNALLOC to avoid useless memory reallocations > 3: decompressors: fix spelling mistakes > 4: xz: avoid overlapping memcpy() with invalid input with in-place > decompression > 5: xz: fix spelling in comments > 6: xz: move s->lzma.len = 0 initialization to lzma_reset() > 7: xz: validate the value before assigning it to an enum variable Acked-by: Andrew Cooper
Re: [PATCH] x86/build: use --orphan-handling linker option if available
On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
> binaries"), arbitrary sections appearing without our linker script
> placing them explicitly can be a problem. Have the linker make us aware
> of such sections, so we would know that the script needs adjusting.
>
> To deal with the resulting warnings:
> - Retain .note.* explicitly for ELF, and discard all of them (except the
> earlier consumed .note.gnu.build-id) for PE/COFF.
> - Have explicit statements for .got, .plt, and alike and add assertions
> that they're empty. No output sections will be created for these as
> long as they remain empty (or else the assertions would cause early
> failure anyway).
> - Collect all .rela.* into a single section, with again an assertion
> added for the resulting section to be empty.
> - Extend the enumerating of .debug_* to ELF. Note that for Clang adding
> of .debug_macinfo is necessary. Amend this by its Dwarf5 counterpart,
> .debug_macro, then as well (albeit more may need adding for full
> coverage).
>
> Suggested-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
> ---
> I would have wanted to make this generic (by putting it in
> xen/Makefile), but the option cannot be added to LDFLAGS, or else
> there'll be a flood of warnings with $(LD) -r. (Besides, adding to
> LDFLAGS would mean use of the option on every linker pass rather than
> just the last one.)
>
> Retaining of .note in xen-syms is under question. Plus if we want to
> retain all notes, the question is whether they wouldn't better go into
> .init.rodata. But .note.gnu.build-id shouldn't move there, and when
> notes are discontiguous all intermediate space will also be assigned to
> the NOTE segment, thus making the contents useless for tools going just
> by program headers.
>
> Newer Clang may require yet more .debug_* to be added. I've only played
> with versions 5 and 7 so far.
>
> Unless we would finally drop all mentioning of Stabs sections, we may
> want to extend to there what is done for Dwarf here (allowing the EFI
> conditional around the section to also go away).
>
> See also https://sourceware.org/pipermail/binutils/2022-March/119922.html.
LLD 13.0.0 also warns about:
ld: warning: :(.symtab) is being placed in '.symtab'
ld: warning: :(.shstrtab) is being placed in '.shstrtab'
ld: warning: :(.strtab) is being placed in '.strtab'
So seeing your mail where you mention GNU ld not needing those, I
think we would need to add them anyway for LLVM ld.
>
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -120,6 +120,8 @@ syms-warn-dup-y := --warn-dup
> syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
> syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
>
> +orphan-handling-$(call ld-option,--orphan-handling=warn) +=
> --orphan-handling=warn
Might be better to place in xen/Kconfig with the CC checks?
I'm also wondering whether we could add the flag here into XEN_LDFLAGS
and EFI_LDFLAGS, as those options are only used together with the
linker script in the targets on the Makefile.
> $(TARGET): TMP = $(@D)/.$(@F).elf32
> $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
> $(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP)
> $(XEN_IMG_OFFSET) \
> @@ -146,7 +148,7 @@ $(TARGET)-syms: $(BASEDIR)/prelink.o $(o
> >$(@D)/.$(@F).1.S
> $(MAKE) $(build)=$(@D) $(@D)/.$(@F).1.o
> $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
> - $(@D)/.$(@F).1.o -o $@
> + $(orphan-handling-y) $(@D)/.$(@F).1.o -o $@
> $(NM) -pa --format=sysv $(@D)/$(@F) \
> | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv
> --sort \
> >$(@D)/$(@F).map
> @@ -220,7 +222,7 @@ endif
> | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort
> >$(@D)/.$(@F).1s.S
> $(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
> $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds -N $< \
> - $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(note_file_option)
> -o $@
> + $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(orphan-handling-y)
> $(note_file_option) -o $@
> $(NM) -pa --format=sysv $(@D)/$(@F) \
> | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv
> --sort >$(@D)/$(@F).map
> rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]*
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -12,6 +12,12 @@
> #undef __XEN_VIRT_START
> #define __XEN_VIRT_START __image_base__
> #define DECL_SECTION(x) x :
> +/*
> + * Use the NOLOAD directive, despite currently ignored by ld for PE output,
> in
Would you mind adding GNU ld here to avoid confusion?
Thanks, Roger.
[ovmf test] 168359: regressions - FAIL
flight 168359 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168359/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 589d51df260465e2561979b8a988e77b0f32a6e8 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z3 days Failing since168258 2022-03-01 01:55:31 Z2 days 21 attempts Testing same since 168359 2022-03-03 10:41:39 Z0 days1 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Matt DeVillier Patrick Rudolph Sean Rhodes Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit 589d51df260465e2561979b8a988e77b0f32a6e8 Author: Sean Rhodes Date: Thu Feb 24 19:38:18 2022 +0800 MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting No need to check the interface protocol then conditionally setting, just set it to BOOT_PROTOCOL and check for error. This is what Linux does for HID devices as some don't follow the USB spec. One example is the Aspeed BMC HID keyboard device, which adds a massive boot delay without this patch as it doesn't respond to 'GetProtocolRequest'. Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Matt DeVillier Signed-off-by: Patrick Rudolph Signed-off-by: Sean Rhodes Reviewed-by: Hao A Wu commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan
Re: [PATCH] x86/cmdline: Interpret 'vpmu' as a positive boolean
On 03/03/2022 11:04, Jan Beulich wrote:
> On 03.03.2022 11:48, Andrew Cooper wrote:
>> On 03/03/2022 07:44, Jan Beulich wrote:
>>> On 02.03.2022 23:11, Andrew Cooper wrote:
This makes it behave slightly more like a regular boolean option.
Signed-off-by: Andrew Cooper
>>> Reviewed-by: Jan Beulich
>>>
Slightly RFC, because there is no easy way of making the opposite "normal
boolean" case work for no-vpmu.
>>> There's nothing to do to make this work afaict: Generic command line
>>> handling converts "no-" to "=no" for custom params.
>> Oh - I'd forgotten that, in which case this patch actually wants to be
>> simply:
>>
>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>> index adff2d2c77f3..2cea1da781ac 100644
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -162,6 +162,11 @@ static int parse_params(const char *cmdline, const
>> struct kernel_param *start,
>> safe_strcpy(opt, "no");
>> optval = opt;
>> }
>> + else if ( !*optval )
>> + {
>> + safe_strcpy(opt, "1");
>> + optval = opt;
>> + }
>> rctmp = param->par.func(optval);
>> break;
>> case OPT_IGNORE:
>>
>> to turn "option\0" into "option=1", no?
> Iirc extending this to the positive case was deliberately not done, for
> the risk of breaking custom handlers not expecting the standard boolean
> forms. We could likely go this route, but only after auditing all custom
> handlers, I'm afraid.
Well - I've already audited them all once recently. What's once more...
I'll have a go in due course; I'd definitely prefer to avoid special
casing the positive boolean form in individual handlers.
~Andrew
Re: [XEN PATCH v9 29/30] build: shuffle main Makefile
On 25.01.2022 12:01, Anthony PERARD wrote: > Reorganize a bit the Makefile ahead of patch > "build: adding out-of-tree support to the xen build" > > We are going to want to calculate all the $(*srctree) and $(*objtree) > once, when we can calculate them. This can happen within the > "$(root-make-done)" guard, in an out-of-tree build scenario, so move > those variable there. > > $(XEN_ROOT) is going to depends on the value of $(abs_srctree) so > needs to move as well. "Kbuild.include" also depends on $(srctree). > > Next, "Config.mk" depends on $(XEN_ROOT) and $(TARGET_*ARCH) depends > on "Config.mk" so those needs to move as well. > > This should only be code movement without functional changes. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich
Re: [PATCH] x86/cmdline: Interpret 'vpmu' as a positive boolean
On 03.03.2022 11:48, Andrew Cooper wrote:
> On 03/03/2022 07:44, Jan Beulich wrote:
>> On 02.03.2022 23:11, Andrew Cooper wrote:
>>> This makes it behave slightly more like a regular boolean option.
>>>
>>> Signed-off-by: Andrew Cooper
>> Reviewed-by: Jan Beulich
>>
>>> Slightly RFC, because there is no easy way of making the opposite "normal
>>> boolean" case work for no-vpmu.
>> There's nothing to do to make this work afaict: Generic command line
>> handling converts "no-" to "=no" for custom params.
>
> Oh - I'd forgotten that, in which case this patch actually wants to be
> simply:
>
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index adff2d2c77f3..2cea1da781ac 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -162,6 +162,11 @@ static int parse_params(const char *cmdline, const
> struct kernel_param *start,
> safe_strcpy(opt, "no");
> optval = opt;
> }
> + else if ( !*optval )
> + {
> + safe_strcpy(opt, "1");
> + optval = opt;
> + }
> rctmp = param->par.func(optval);
> break;
> case OPT_IGNORE:
>
> to turn "option\0" into "option=1", no?
Iirc extending this to the positive case was deliberately not done, for
the risk of breaking custom handlers not expecting the standard boolean
forms. We could likely go this route, but only after auditing all custom
handlers, I'm afraid.
Jan
Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb
On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote: > Thinking more about it we actually need to drop the xen_initial_domain() > check otherwise some cases won't be functional (Dom0 not 1:1 mapped, or > DomU 1:1 mapped). Hmm, but that would be the case even before this series, right?
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
On 03.03.2022 11:45, Andrew Cooper wrote:
> On 03/03/2022 10:30, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>> {
>> case PHYSDEVOP_map_pirq:
>> case PHYSDEVOP_unmap_pirq:
>> +/*
>> + * Control domain (and domains controlling others) need to use
>> + * PHYSDEVOP_{un,}map_pirq in order to setup interrupts for
>> passthrough
>> + * devices on behalf of other guests.
>> + */
>> +if ( is_control_domain(currd) || currd->target )
>> +break;
>
> Hmm. In a split control/hardware domain model, then qemu is in the
> hardware domain rather than the control domain.
Interesting. I would have expected it to be the other way around, with
qemu for domains with pass-through devices living in a stubdom.
Jan
> I suspect this wants
> extending with || is_hardware_domain(currd).
>
> Also, the sentence about later safety checks really ought to be in this
> source comment too.
>
> ~Andrew
Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote: > Not for me, I fail to boot with > > [ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes), > total 0 (slots), used 0 (slots) > > (this is iscsi root so I need the NIC). > > > I bisected it to "x86: remove the IOMMU table infrastructure" but haven't > actually looked at the code yet. Thanks. Looks like the sizing is going wrong. Just to confirm, this is dom0 on x86 and no special command line options?
Re: [XEN PATCH v9 28/30] build: specify source tree in include/ for prerequisite
On 25.01.2022 12:01, Anthony PERARD wrote: > When doing an out-of-tree build, and thus setting VPATH, > GNU Make 3.81 on Ubuntu Trusty complains about Circular dependency of > include/Makefile and include/xlat.lst and drop them. The build fails > later due to headers malformed. > > This might be due to bug #13529 > "Incorrect circular dependancy" > https://savannah.gnu.org/bugs/?13529 > which was fixed in 3.82. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich
Re: [PATCH] x86/cmdline: Interpret 'vpmu' as a positive boolean
On 03/03/2022 07:44, Jan Beulich wrote:
> On 02.03.2022 23:11, Andrew Cooper wrote:
>> This makes it behave slightly more like a regular boolean option.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
>> Slightly RFC, because there is no easy way of making the opposite "normal
>> boolean" case work for no-vpmu.
> There's nothing to do to make this work afaict: Generic command line
> handling converts "no-" to "=no" for custom params.
Oh - I'd forgotten that, in which case this patch actually wants to be
simply:
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index adff2d2c77f3..2cea1da781ac 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -162,6 +162,11 @@ static int parse_params(const char *cmdline, const
struct kernel_param *start,
safe_strcpy(opt, "no");
optval = opt;
}
+ else if ( !*optval )
+ {
+ safe_strcpy(opt, "1");
+ optval = opt;
+ }
rctmp = param->par.func(optval);
break;
case OPT_IGNORE:
to turn "option\0" into "option=1", no?
~Andrew
Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
On 03/03/2022 10:30, Roger Pau Monne wrote:
> Control domains (including domains having control over a single other
> guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
> bindings of interrupts from devices assigned to the controlled guest.
>
> As such relax the check for HVM based guests and allow the usage of
> the hypercalls for any control domains. Note that further safety
> checks will be performed in order to assert that the current domain
> has the right permissions against the target of the hypercall.
>
> Reported-by: Alex Olson
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/hvm/hypercall.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index 030243810e..9128e4d025 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> case PHYSDEVOP_map_pirq:
> case PHYSDEVOP_unmap_pirq:
> +/*
> + * Control domain (and domains controlling others) need to use
> + * PHYSDEVOP_{un,}map_pirq in order to setup interrupts for
> passthrough
> + * devices on behalf of other guests.
> + */
> +if ( is_control_domain(currd) || currd->target )
> +break;
Hmm. In a split control/hardware domain model, then qemu is in the
hardware domain rather than the control domain. I suspect this wants
extending with || is_hardware_domain(currd).
Also, the sentence about later safety checks really ought to be in this
source comment too.
~Andrew
Re: [XEN PATCH v9 27/30] build: rework "headers*.chk" prerequisite in include/
On 25.01.2022 12:01, Anthony PERARD wrote: > Listing public headers when out-of-tree build are involved becomes > more annoying where every path to every headers needs to start with > "$(srctree)/$(src)", or $(wildcard ) will not work. This means more > repetition. ( "$(srcdir)" is a shortcut for "$(srctree)/$(src)" ) > > This patch attempt to reduce the amount of duplication and make better > use of make's meta programming capability. The filters are now listed > in a variable and don't have to repeat the path to the headers files > as this is added later as needed. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich
Re: PIRQ handling and PVH dom0?
On Wed, Mar 02, 2022 at 05:49:14PM +, Andrew Cooper wrote:
> On 02/03/2022 17:27, Alex Olson wrote:
> > I further attempted to see how far PVH dom0 can get but had a general
> > question regarding what is not yet implemented...
> >
> > With an initial version of Roger's recent "vpci/msix: fix PBA access"
> > patches and after refreshing his earlier 2018 patchset "vpci: add support
> > for SR-IOV capability" regarding SR-IOV support for PVH dom0, I was able to
> > get both physical functions and virtual functions of an SR-IOV network card
> > to operate correctly in PVH dom0.
> >
> > However, it looks like any PCI-passthrough for HVM domUs with PVH dom0 is
> > not yet implemented. I see the "PHYSDEVOP_map_pirq" call fails since the
> > "emulation_flags" for dom0 do not include "XEN_X86_EMU_USE_PIRQ"...
> >
> > libxl: error: libxl_pci.c:1461:pci_add_dm_done: Domain
> > 1:xc_physdev_map_pirq irq=17 (error=-1): Function not implemented
> >
> >
> >
> >
> > libxl: error: libxl_pci.c:1781:device_pci_add_done: Domain
> > 1:libxl__device_pci_add failed for PCI device 0:5:0.1 (rc -3)
> >
> >
> >
> >
> > libxl: error: libxl_create.c:1895:domcreate_attach_devices: Domain
> > 1:unable to add pci devices
> >
> >
> > What is PVH dom0 missing at a conceptual level for PCI passthrough to
> > domUs? I naively assumed that an HVM domU guest wouldn't care much whether
> > dom0 was PV or PVH in terms of passthrough device IRQ handling...
> >
> > Thanks
>
> Hmm. xen/arch/x86/hvm/hypercall.c hvm_physdev_op() filters map/unmap
> pirq based on currd.
>
> But this is buggy. It should read the physdev_map_pirq_t parameter and
> look at the domid parameter. What qemu here is doing is trying to map a
> pirq on behalf of the target domain, not on behalf of dom0.
Even doing the filtering based on the domid parameter would be wrong
given the current logic. PHYSDEVOP_{un,}map_pirq are used by both
domains that have physical interrupts routed over even channels and
domains that have interrupts delivered using the emulated interrupt
controllers.
I've posted a fix that should allow you to make further progress:
https://lore.kernel.org/xen-devel/20220303103057.49181-4-roger@citrix.com/
It's likely more work will be needed, and it's unsafe to use until we
sort out the issue around locking for PCI devices when used by vPCI.
Thanks, Roger.
RE: Proposal for Porting Xen to Armv8-R64 - DraftA
Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2022年3月3日 17:15 > To: Wei Chen ; Stefano Stabellini > > Cc: xen-devel@lists.xenproject.org; Bertrand Marquis > ; Penny Zheng ; Henry Wang > ; nd > Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA > > Hi Wei, > > On 03/03/2022 01:35, Wei Chen wrote: > >>> 1. Assembly code for EL1 MPU context_switch > >> > >> This discussion reminds me when KVM decided to rewrite their context > >> switch from assembly to C. The outcome was the compiler is able to do a > >> better job than us when it comes to optimizing. > >> > >> With a C version, we could also share the save/restore code with 32-bit > >> and it is easier to read/maintain. > >> > >> So I would suggest to run some numbers to check if it really worth > >> implementing the MPU save/restore in assembly. > >> > > > > It's interesting to hear KVM guys have similar discussion. Yes, if the > > gains of assembly code is not very obvious, then reusing the code for > 32-bit > > would be more important. As our current platform (FVP) could not do very > > precise performance measurement. I want to keep current assembly code > there, > > when we have a platform that can do such measurement we can have a > thread > > to discuss it. > > I briefly looked at the code, the assembly version is not going to be > trivial to review and we don't know yet whether it has an advantage. So > I would say this should be the inverse here. > > We want the C version first until we can prove the assembly version is > better. > > My gut feeling is we will not need the assembly version. > Ok, we will rollback to C version. After we will finish the measurements, then we will discuss it again (if the assembly has enough gain). > Cheers, > > -- > Julien Grall
Re: [PATCH] xen/CET: Fix __initconst_cf_clobber
On 03.03.2022 11:29, Andrew Cooper wrote:
> On 03/03/2022 07:35, Jan Beulich wrote:
>> On 02.03.2022 23:10, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -210,6 +210,12 @@ SECTIONS
>>>DECL_SECTION(.init.data) {
>>> #endif
>>>
>>> + . = ALIGN(POINTER_ALIGN);
>>> + __initdata_cf_clobber_start = .;
>>> + *(.init.data.cf_clobber)
>>> + *(.init.rodata.cf_clobber)
>>> + __initdata_cf_clobber_end = .;
>>> +
>>> *(.init.rodata)
>>> *(.init.rodata.*)
>> I wonder if this shouldn't really be two sections. Live-patching will
>> need to supply two ranges to apply_alternatives() anyway (one for each
>> section, unless you want to start requiring to pass a linker script to
>> "$(LD) -r" when generating live patches, just to fold the two sections),
>> so in the core hypervisor we may want to follow suit.
>
> I don't see why livepatches would need two sections - they're linked in
> a similar way to Xen IIRC. Either way, if changes are needed, they
> should be part of the livepatch work.
Live patch objects being relocatable ones, their loading logic works with
section boundaries. Hence there'll be two sections of interest, the
boundaries of which are independent and hence need passing as separate
values.
Jan
Re: [XEN PATCH v9 24/30] build: grab common EFI source files in arch specific dir
On 25.01.2022 12:00, Anthony PERARD wrote: > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -77,8 +77,9 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o > obj-y += sysctl.o > endif > > -# Allows "clean" to descend into boot/ > +# Allows "clean" to descend > subdir- += boot > +subdir- += efi No similar addition is needed for Arm? > --- /dev/null > +++ b/xen/common/efi/efi-common.mk > @@ -0,0 +1,15 @@ > +EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o > +EFIOBJ-$(CONFIG_COMPAT) += compat.o > + > +CFLAGS-y += -fshort-wchar > +CFLAGS-y += -iquote $(srctree)/common/efi > + > +# Part of the command line transforms $(obj) in to a relative reverted path. > +# e.g.: It transforms "dir/foo/bar" into successively > +# "dir foo bar", ".. .. ..", "../../.." > +$(obj)/%.c: $(srctree)/common/efi/%.c FORCE > + $(Q)ln -nfs $(subst $(space),/,$(patsubst %,..,$(subst /, > ,$(obj/common/efi/$(
[ovmf test] 168356: regressions - FAIL
flight 168356 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168356/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z2 days Failing since168258 2022-03-01 01:55:31 Z2 days 20 attempts Testing same since 168356 2022-03-03 06:03:21 Z0 days1 attempts People who touched revisions under test: Guomin Jiang Jason Jason Lou Xiaolu.Jiang jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 Not pushing. commit b422b0fcf92dd4103dfc16d8d5f77fbec2d8c5b9 Author: Guomin Jiang Date: Tue Feb 22 11:29:23 2022 +0800 EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 WindowOpen will fail in some case. for example, without XServer. Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit 906242343f7a654402f6f999d447aa9d29a8f4d4 Author: Guomin Jiang Date: Sun Feb 20 14:53:01 2022 +0800 MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668 SetMode will fail in some case. for example, without XServer. Should handle these case when SetMode fail. If we don't handle it, it will Segmentation fault. Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit dc39554d58af4a50b50eca1f57c49415a12b0c98 Author: Xiaolu.Jiang Date: Tue Feb 22 22:14:05 2022 +0800 edk2/MdeModulePkg/Debuglib: Add Standalone MM support https://bugzilla.tianocore.org/show_bug.cgi?id=3844 This change added Standalone MM instance of DebugLib. Reviewd-by: Jian J Wang Reviewd-by: Liming Gao Signed-off-by: Xiaolu.Jiang commit 497ac7b6d7f9750f48f137db244931a5728b1968 Author: Guomin Jiang Date: Sat Jan 29 16:28:02 2022 +0800 UefiPayloadPkg/PayloadLoaderPeim: Use INT64 as input parameter REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3818 It will have some potential issue when memory larger than 2G because the high memory address will be fill with 0x when do the operation of INTN + INT64 but it is 32 bit normal data in fact. Should use same data type INT64 + INT64. V3: 1. Use INT64 as input parameter because all date type is 64 bit V2: 1. Force the data type to UINTN to avoid high dword be filled with 0x 2. Keep INTN because the offset may postive or negative. Reviewed-by: Guo Dong Reviewed-by: Ray Ni Signed-off-by: Guomin Jiang commit
[PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
Control domains (including domains having control over a single other
guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
bindings of interrupts from devices assigned to the controlled guest.
As such relax the check for HVM based guests and allow the usage of
the hypercalls for any control domains. Note that further safety
checks will be performed in order to assert that the current domain
has the right permissions against the target of the hypercall.
Reported-by: Alex Olson
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/hypercall.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 030243810e..9128e4d025 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
{
case PHYSDEVOP_map_pirq:
case PHYSDEVOP_unmap_pirq:
+/*
+ * Control domain (and domains controlling others) need to use
+ * PHYSDEVOP_{un,}map_pirq in order to setup interrupts for passthrough
+ * devices on behalf of other guests.
+ */
+if ( is_control_domain(currd) || currd->target )
+break;
case PHYSDEVOP_eoi:
case PHYSDEVOP_irq_status_query:
case PHYSDEVOP_get_free_pirq:
--
2.34.1
[PATCH 2/3] hvm/irq: tighten check in hvm_domain_use_pirq
hvm_domain_use_pirq checking whether the passed domain is an HVM
guests is pointless, as all calls originate from HVM only paths.
Instead check whether the domain has PIRQ support in order to avoid
further checks.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 5a7f39b54f..7c5dfd3c3a 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -30,7 +30,7 @@
bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq)
{
-return is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND;
+return has_pirq(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND;
}
/* Must be called with hvm_domain->irq_lock hold */
--
2.34.1
[PATCH 1/3] evtchn/hvm: do not allow binding PIRQs unless supported
HVM (or PVH) domain not having PIRQ support won't be allowed to map PIRQs in the first place, but would still be allowed usage of EVTCHNOP_bind_pirq. Such hypercall won't have any practical effect on the domain, as the event channels would never be bound to PIRQs. Signed-off-by: Roger Pau Monné --- xen/common/event_channel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index ffb042a241..bc4985706a 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -556,6 +556,9 @@ static int evtchn_bind_pirq(evtchn_bind_pirq_t *bind) intport = 0, rc; unsigned int pirq = bind->pirq; +if ( is_hvm_domain(d) && !has_pirq(d) ) +return -ENOSYS; + if ( pirq >= d->nr_pirqs ) return -EINVAL; -- 2.34.1
[PATCH 0/3] x86/hvm: PIRQ related cleanup and a fix
Hello,
First two patches are cleanup related to the usage of PIRQs from HVM
guests, and shouldn't result in any functional change.
Patch 3 allows the usage of PHYSDEVOP_{un,}map_pirq for HVM control
domains even when lacking support to route PIRQs over event channels.
This is done in order to allow setup of device interrupts assigned to
different guests for passthrough support. Note that using passthrough
from a PVH dom0 with vPCI in a safe way will at least require proper
locking around PCI devices, and likely other fixes.
Roger Pau Monne (3):
evtchn/hvm: do not allow binding PIRQs unless supported
hvm/irq: tighten check in hvm_domain_use_pirq
hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq
xen/arch/x86/hvm/hypercall.c | 7 +++
xen/arch/x86/hvm/irq.c | 2 +-
xen/common/event_channel.c | 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
--
2.34.1
Re: [XEN PATCH v9 23/30] build,x86: remove the need for build32.mk
On 25.01.2022 12:00, Anthony PERARD wrote: > Rework "arch/x86/boot/Makefile" to allow it to build both file > "cmdline.S" and "reloc.S" without "build32.mk". > > These will now use the main rules for "%.o: %.c", and thus generate a > dependency file. (We will not need to track the dependency manually > anymore.) > > But for that, we need to override the main CFLAGS to do a 32bit build. > We introduce XEN_TREEWIDE_CFLAGS which can be reused in boot/Makefile, > and avoid the need to reparse Config.mk with a different value for > XEN_TARGET_ARCH. From this new $(XEN_TREEWIDE_CFLAGS), we only need to > change -m64 to have the 32bit flags. Then those are applied only to > "cmdline.o" and "reloc.o". > > Specifically apply the rule "%.S: %.bin" to both cmdline.S and reloc.S > to avoid make trying to regenerate other %.S files with it. > > There is no change expected to the resulting "cmdline.S" and > "reloc.S", only the *.o file changes as their symbol for FILE goes > from "cmdline.c" to "arch/x86//cmdline.c". (No idea why "boot" is > missing from the string.) (I've only check with GCC, not clang.) > > Signed-off-by: Anthony PERARD Reviewed-by: Jan Beulich with one question, just to be sure I understand things right: > --- a/xen/arch/x86/boot/Makefile > +++ b/xen/arch/x86/boot/Makefile > @@ -1,25 +1,42 @@ > obj-bin-y += head.o > +head-srcs := cmdline.S reloc.S > > -DEFS_H_DEPS = $(abs_srctree)/$(src)/defs.h > $(abs_srctree)/include/xen/stdbool.h > +nocov-y += $(head-srcs:.S=.o) > +noubsan-y += $(head-srcs:.S=.o) > +targets += $(head-srcs:.S=.o) > > -CMDLINE_DEPS = $(DEFS_H_DEPS) $(abs_srctree)/$(src)/video.h \ > -$(BASEDIR)/include/xen/kconfig.h \ > -$(BASEDIR)/include/generated/autoconf.h > +head-srcs := $(addprefix $(obj)/, $(head-srcs)) > > -RELOC_DEPS = $(DEFS_H_DEPS) \ > - $(BASEDIR)/include/generated/autoconf.h \ > - $(BASEDIR)/include/xen/kconfig.h \ > - $(BASEDIR)/include/xen/multiboot.h \ > - $(BASEDIR)/include/xen/multiboot2.h \ > - $(BASEDIR)/include/xen/const.h \ > - $(BASEDIR)/include/public/arch-x86/hvm/start_info.h > +$(obj)/head.o: $(head-srcs) > > -$(obj)/head.o: $(obj)/cmdline.S $(obj)/reloc.S > +CFLAGS_x86_32 := $(subst -m64,-m32 -march=i686,$(XEN_TREEWIDE_CFLAGS)) > +$(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS)) > +CFLAGS_x86_32 += -Werror -fno-builtin -g0 -msoft-float > +CFLAGS_x86_32 += -I$(srctree)/include > > -$(obj)/cmdline.S: $(src)/cmdline.c $(CMDLINE_DEPS) $(src)/build32.lds > - $(MAKE) -f $(abs_srctree)/$(src)/build32.mk -C $(obj) $(@F) > CMDLINE_DEPS="$(CMDLINE_DEPS)" > +# override for 32bit binaries > +$(head-srcs:.S=.o): CFLAGS_stack_boundary := You overriding CFLAGS_stack_boundary but not object_label_flags is merely because the latter has no (unwanted) effect on the compilation? Jan
