flight 167940 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167940/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8542fc5f956821841154d4c11851c5484847ac0d
baseline version:
ovmf
flight 167937 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167937/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail blocked in
167917
On 28/01/2022 13:29, Andrew Cooper wrote:
> 'idle' here refers to hlt/mwait. The S3 path isn't an idle path - it is a
> platform reset.
>
> Conditionally clearing IBRS and flushing the store buffers on the way down is
> a waste of time.
>
> Furthermore, we want to load default_xen_mcu_opt_ctrl
flight 167936 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167936/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167922
Tests which did not
From: Luca Miccio
Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
---
From: Luca Miccio
When xs_introduce_domain is called, send out a notification on the
xenstore event channel so that any (dom0less) domain waiting for the
xenstore interface to be ready can continue with the initialization.
The extra notification is harmless for domains that don't require it.
From: Stefano Stabellini
Introduce a new "xen,enhanced" dom0less property to enable/disable PV
driver interfaces for dom0less guests. Currently only "enabled" and
"disabled" are supported property values (and empty). Leave the option
open to implement further possible values in the future (e.g.
From: Luca Miccio
If "xen,enhanced" is enabled, then add to dom0less domains:
- the hypervisor node in device tree
- the xenstore event channel
The xenstore event channel is also used for the first notification to
let the guest know that xenstore has become available.
Signed-off-by: Luca
From: Luca Miccio
The xenstore event channel will be allocated for dom0less domains. It is
necessary to have access to the evtchn_alloc_unbound function to do
that, so make evtchn_alloc_unbound public.
Add a skip_xsm parameter to allow disabling the XSM check in
evtchn_alloc_unbound
Hi all,
Currently dom0less guests cannot use PV drivers because they don't have
access to xenstore. Also, the hypervisor node in device tree is missing
so they don't detect that they are running on Xen (thus, they don't try
to enable PV interfaces.)
This patch series enables dom0less guests (on
On Fri, 28 Jan 2022, Ayan Kumar Halder wrote:
> Hi Julien/Stefano,
>
> Good discussion to learn about Xen (from a newbie's perspective). :)
>
> I am trying to clarify my understanding. Some queries as below :-
>
> On 28/01/2022 09:46, Julien Grall wrote:
> >
> >
> > On 28/01/2022 01:20,
On Fri, 28 Jan 2022, Julien Grall wrote:
> On 28/01/2022 01:20, Stefano Stabellini wrote:
> > On Thu, 27 Jan 2022, Julien Grall wrote:
> > > On Thu, 27 Jan 2022 at 23:05, Julien Grall
> > > wrote:
> > > >
> > > > On Thu, 27 Jan 2022 at 22:40, Stefano Stabellini
> > > > wrote:
> > > > > I am
flight 167931 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167931/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167921
Hi Julien,
Julien Grall writes:
> Hi,
>
> On 27/01/2022 19:55, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>> All IOMMU drivers on Arm perform almost the same generic actions in
>> hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
>> in order to get rid of
On Thu, Jan 27, 2022 at 04:01:32PM +, 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,
On Thu, Jan 27, 2022 at 10:07 AM Jan Beulich wrote:
>
> For higher order mappings the comparison against p2m->min_remapped_gfn
> needs to take the upper bound of the covered GFN range into account, not
> just the base GFN. Otherwise, i.e. when dropping a mapping overlapping
> the remapped range
On Tue, Jan 04, 2022 at 10:41:32AM +0100, Jan Beulich wrote:
> While it is okay for IOMMU page tables to get set up for guests starting
> in PoD mode, actual device assignment may only occur once all PoD
> entries have been removed from the P2M. So far this was enforced only
> for boot-time
On Fri, Jan 28, 2022 at 01:43:38PM +0100, Jan Beulich wrote:
> On 28.01.2022 13:03, Anthony PERARD wrote:
> > On Thu, Jan 27, 2022 at 04:57:20PM +0100, Jan Beulich wrote:
> >> On 25.01.2022 12:00, Anthony PERARD wrote:
> >>> clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
>
flight 167933 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167933/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f4b7b473b4afd0093768905529bfae09a2061d41
baseline version:
ovmf
On Fri, Jan 28, 2022 at 12:14:58PM +0100, Jan Beulich wrote:
> On 25.01.2022 12:00, Anthony PERARD wrote:
> > Exporting a variable with a dash doesn't work reliably, they may be
> > striped from the environment when calling a sub-make or sub-shell.
> >
> > CFLAGS-stack-boundary start to be
flight 167934 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167934/
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
flight 167927 linux-linus real [real]
flight 167935 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167927/
http://logs.test-lab.xenproject.org/osstest/logs/167935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 28.01.2022 14:29, Andrew Cooper wrote:
> This is a statement of hardware behaviour, and not related to controls for the
> guest kernel to use. Pass it straight through from hardware.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Hi, Jan!
On 12.01.22 16:57, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>> @@ -68,12 +84,13 @@ int vpci_add_handlers(struct pci_dev *pdev)
>> /* We should not get here twice for the same device. */
>> ASSERT(!pdev->vpci);
>>
>> -pdev->vpci =
Hi, Roger, Jan!
On 13.01.22 10:58, Roger Pau Monné wrote:
> On Wed, Jan 12, 2022 at 04:52:51PM +0100, Jan Beulich wrote:
>> On 12.01.2022 16:42, Roger Pau Monné wrote:
>>> On Wed, Jan 12, 2022 at 03:57:36PM +0100, Jan Beulich wrote:
On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>
flight 167930 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
Fixes/extensions to allow HVM guests to use AMD hardware MSR_SPEC_CTRL
facilities.
No PV support yet - that will require some substantially more careful
unpicking of the PV entry/exit asm.
Andrew Cooper (9):
x86/cpuid: Advertise SSB_NO to guests by default
x86/spec-ctrl: Drop use_spec_ctrl
Most MSR_SPEC_CTRL setup will be common between Intel and AMD. Instead of
opencoding an OR of two features everywhere, introduce has_spec_ctrl instead.
Reword the comment above the Intel specific alternatives block to highlight
that it is Intel specific, and pull the setting of
In some cases, writes to MSR_SPEC_CTRL do not have interesting side effects,
and we should implement lazy context switching like we do with other MSRs.
In the short term, this will be used by the SVM infrastructure, but I expect
to extend it to other contexts in due course.
Introduce
'idle' here refers to hlt/mwait. The S3 path isn't an idle path - it is a
platform reset.
Conditionally clearing IBRS and flushing the store buffers on the way down is
a waste of time.
Furthermore, we want to load default_xen_mcu_opt_ctrl unilaterally on the way
back up. Currently it happens
Several bugfixes have reduced the utility of this variable from it's original
purpose, and now all it does is aid in the setup of SCF_ist_wrmsr.
Simplify the logic by drop the variable, and doubling up the setting of
SCF_ist_wrmsr for the PV and HVM blocks, which will make the AMD SPEC_CTRL
This is a statement of hardware behaviour, and not related to controls for the
guest kernel to use. Pass it straight through from hardware.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
Not currently enumerated by any CPU I'm aware of.
v2:
* New
---
Currently, amd_init_ssbd() works by being the only write to MSR_SPEC_CTRL in
the system. This ceases to be true when using the common logic.
Include AMD MSR_SPEC_CTRL in has_spec_ctrl to activate the common paths, and
introduce an AMD specific block to control alternatives. Also update the
Hardware maintains both host and guest versions of MSR_SPEC_CTRL, but guests
run with the logical OR of both values. Therefore, in principle we want to
clear Xen's value before entering the guest. However, for migration
compatibility, and for performance reasons with SEV-SNP guests, we want the
With all other pieces in place, MSR_SPEC_CTRL is fully working for HVM guests.
Update the CPUID derivation logic (both PV and HVM to avoid losing subtle
changes), drop the MSR intercept, and explicitly enable the CPUID bits for HVM
guests.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
Fill in VMCB accessors for spec_ctrl in svm_{get,set}_reg(), and CPUID checks
for all supported bits in guest_{rd,wr}msr().
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/hvm/svm/svm.c | 9 +
Hello, Roger, Jan!
On 13.01.22 15:38, Jan Beulich wrote:
> On 13.01.2022 14:27, Roger Pau Monné wrote:
>> On Thu, Nov 25, 2021 at 12:17:32PM +0100, Jan Beulich wrote:
>>> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
For unprivileged guests
On 28.01.2022 13:03, Anthony PERARD wrote:
> On Thu, Jan 27, 2022 at 04:57:20PM +0100, Jan Beulich wrote:
>> On 25.01.2022 12:00, Anthony PERARD wrote:
>>> clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
>>> only the filename rather than the full path to the source file.
>>>
On 12.01.22 17:27, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a vPCI is removed for a PCI device it is possible that we have
>> scheduled a delayed work for map/unmap operations for that device.
>> For example, the
Hi Julien/Stefano,
Good discussion to learn about Xen (from a newbie's perspective). :)
I am trying to clarify my understanding. Some queries as below :-
On 28/01/2022 09:46, Julien Grall wrote:
On 28/01/2022 01:20, Stefano Stabellini wrote:
On Thu, 27 Jan 2022, Julien Grall wrote:
On Thu,
On Thu, Jan 27, 2022 at 04:57:20PM +0100, Jan Beulich wrote:
> On 25.01.2022 12:00, Anthony PERARD wrote:
> > clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
> > only the filename rather than the full path to the source file.
> >
> > clang 3.8.1-24 (in our debian:stretch
On 28.01.2022 12:32, Anthony PERARD wrote:
> On Thu, Jan 27, 2022 at 04:50:32PM +0100, Jan Beulich wrote:
>> On 25.01.2022 12:00, Anthony PERARD wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -285,6 +285,16 @@ CFLAGS += -flto
>>> LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
On Thu, Jan 27, 2022 at 04:50:32PM +0100, Jan Beulich wrote:
> On 25.01.2022 12:00, Anthony PERARD wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -285,6 +285,16 @@ CFLAGS += -flto
> > LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
> > endif
> >
> > +# Note that link order
flight 167922 qemu-mainline real [real]
flight 167932 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167922/
http://logs.test-lab.xenproject.org/osstest/logs/167932/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 25.01.2022 12:00, Anthony PERARD wrote:
> Exporting a variable with a dash doesn't work reliably, they may be
> striped from the environment when calling a sub-make or sub-shell.
>
> CFLAGS-stack-boundary start to be removed from env in patch "build:
> set ALL_OBJS in main Makefile; move
On Fri, Jan 28, 2022 at 09:48:05AM +0100, Dario Faggioli wrote:
> If we are in libxl_list_vcpu() and we are returning NULL, let's avoid
> touching the output parameter *nr_vcpus_out, which the caller should
> have initialized to 0.
>
> The current behavior could be problematic if are creating a
On 28/01/2022 10:36, Jan Beulich wrote:
> On 28.01.2022 10:28, Durrant, Paul wrote:
>> On 27/01/2022 14:47, Jan Beulich wrote:
>>> @@ -1457,24 +1462,24 @@ static int iommu_get_device_group(
>>> if ( !is_iommu_enabled(d) || !ops->get_device_group_id )
>>> return 0;
>>>
>>> -
Hi Jan,
> On 27 Jan 2022, at 2:47 pm, Jan Beulich wrote:
>
> This is, once again, to limit the number of indirect calls as much as
> possible. The only hook invocation which isn't sensible to convert is
> setup(). And of course Arm-only use sites are left alone as well.
>
> Note regarding the
On 28.01.2022 10:28, Durrant, Paul wrote:
> On 27/01/2022 14:47, Jan Beulich wrote:
>> @@ -1457,24 +1462,24 @@ static int iommu_get_device_group(
>> if ( !is_iommu_enabled(d) || !ops->get_device_group_id )
>> return 0;
>>
>> -group_id = ops->get_device_group_id(seg, bus,
Hi Oleksandr,
> On 27 Jan 2022, at 7:55 pm, Oleksandr Tyshchenko wrote:
>
> From: Oleksandr Tyshchenko
>
> All IOMMU drivers on Arm perform almost the same generic actions in
> hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
> in order to get rid of code duplication.
>
On 28/01/2022 01:20, Stefano Stabellini wrote:
On Thu, 27 Jan 2022, Julien Grall wrote:
On Thu, 27 Jan 2022 at 23:05, Julien Grall wrote:
On Thu, 27 Jan 2022 at 22:40, Stefano Stabellini wrote:
I am with you on both points.
One thing I noticed is that the code today is not able to deal
flight 167929 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167929/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a867f3a7042ae0b4c1189bececbe72aa8a8a8e27
baseline version:
ovmf
On 27/01/2022 14:49, Jan Beulich wrote:
The VT-d hook can indicate an error, which shouldn't be ignored. Convert
the hook's return value to a proper error code, and let that bubble up.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
On 27/01/2022 14:49, Jan Beulich wrote:
Let's use infrastructure we have available instead of an open-coded
wbinvd() invocation.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
On 27/01/2022 14:48, Jan Beulich wrote:
The actual function should always have lived in core x86 code; move it
there, replacing get_cache_line_size() by readily available (except very
early during boot; see the code comment) data. Also rename the function.
Drop the respective IOMMU hook,
On 27/01/2022 14:47, Jan Beulich wrote:
This is, once again, to limit the number of indirect calls as much as
possible. The only hook invocation which isn't sensible to convert is
setup(). And of course Arm-only use sites are left alone as well.
Note regarding the introduction / use of local
If we are in libxl_list_vcpu() and we are returning NULL, let's avoid
touching the output parameter *nr_vcpus_out, which the caller should
have initialized to 0.
The current behavior could be problematic if are creating a domain and,
in the meantime, an existing one is destroyed when we have
57 matches
Mail list logo
