flight 167971 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 31.01.22 17:50, Jan Beulich wrote:
> On 31.01.2022 16:06, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
rom->type = VPCI_BAR_EMPTY;
}
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index ed127a08a953..0a73b14a92dc 100644
--- a/xen/inc
On 31.01.22 17:19, Randy Dunlap wrote:
Add missing ioctl "magic numbers" for various Xen interfaces
(xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h).
Signed-off-by: Randy Dunlap
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
Reviewed-by:
On 31.01.22 18:23, Demi Marie Obenour wrote:
The current implementation of gntdev guarantees that the first call to
IOCTL_GNTDEV_MAP_GRANT_REF will set @index to 0. This is required to
use gntdev for Wayland, which is a future desire of Qubes OS.
Additionally, requesting zero grants results in a
flight 167966 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167966/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167961
test-armhf-armhf-libvirt 16 save
flight 167967 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167967/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, Jan 31, 2022 at 10:16:41PM +0100, Thomas Gleixner wrote:
> Guenter,
>
> On Mon, Jan 31 2022 at 07:21, Guenter Roeck wrote:
> > Sure. Please see http://server.roeck-us.net/qemu/x86/.
> > The logs are generated with with v5.16.4.
>
> thanks for providing the data. It definitely helped me to
flight 167965 xen-4.15-testing real [real]
flight 167969 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167965/
http://logs.test-lab.xenproject.org/osstest/logs/167969/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
Hi,
On 31/01/2022 19:37, Ayan Kumar Halder wrote:
At the moment, Xen is only handling data abort with valid syndrome (i.e.
ISV=0). Unfortunately, this doesn't cover all the instructions a domain
could use to access MMIO regions.
For instance, a baremetal OS can use any of the following instruct
Guenter,
On Mon, Jan 31 2022 at 07:21, Guenter Roeck wrote:
> Sure. Please see http://server.roeck-us.net/qemu/x86/.
> The logs are generated with with v5.16.4.
thanks for providing the data. It definitely helped me to leave the
state of not seeing the wood for the trees. Fix below.
Thanks,
Hello,
I see oxenstored running at 100% CPU on a busy Xen host. This article (
https://xenproject.org/2014/05/01/9124/) says that the maximum number of
VMs supported by oxenstore is 160. What is the technical reason for this
limit? Doesn't the Xen hypervisor support more than 160 concurrent DomUs?
Hi All,
On 31/01/2022 19:37, Ayan Kumar Halder wrote:
At the moment, Xen is only handling data abort with valid syndrome (i.e.
ISV=0). Unfortunately, this doesn't cover all the instructions a domain
could use to access MMIO regions.
For instance, a baremetal OS can use any of the following inst
Hi Stefano/Julien,
On 29/01/2022 17:40, Julien Grall wrote:
Hi Stefano,
On 28/01/2022 20:23, Stefano Stabellini wrote:
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
At the moment, Xen is only handling data abort with valid syndrome (i.e.
ISV=0). Unfortunately, this doesn't cover all the instructions a domain
could use to access MMIO regions.
For instance, a baremetal OS can use any of the following instructions, where
x1 contains the address of the MMIO regio
Hi Jan,
On 27/01/2022 12:25, Jan Beulich wrote:
On 27.01.2022 11:45, Julien Grall wrote:
On 12/01/2022 08:45, Jan Beulich wrote:
From: Sergey Temerkhanov
This helps overcome problems observed with some UEFI implementations
Would it be possible to provide some details about the platform? Th
Hi,
On 27/01/2022 19:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
You can find the V1-V2 patch series at [1]-[2].
The first 8 patches (prereq work + R-Car S4 IPMMU support) have been already
committed.
These are remaining 2 patches which include misc changes.
[1]
Hi,
On 27/01/2022 14:53, Jan Beulich wrote:
Determining that behavior is correct (i.e. results in failure) for a
passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit
more obvious by checking input in generic code - both for singular
requests to not match the value and for ran
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, a
The current implementation of gntdev guarantees that the first call to
IOCTL_GNTDEV_MAP_GRANT_REF will set @index to 0. This is required to
use gntdev for Wayland, which is a future desire of Qubes OS.
Additionally, requesting zero grants results in an error, but this was
not documented either. D
flight 167964 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167964/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 167908
test-amd64-amd64-xl-qemut-win7-a
Add missing ioctl "magic numbers" for various Xen interfaces
(xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h).
Signed-off-by: Randy Dunlap
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
v2: fix copy-pasta error: change 'E' to 'G' (thanks,
Hi--
On 1/30/22 22:55, Juergen Gross wrote:
> On 30.01.22 20:23, Randy Dunlap wrote:
>> Add missing ioctl "magic numbers" for various Xen interfaces
>> (xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h).
>>
>> Signed-off-by: Randy Dunlap
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
>> Cc: Stefa
On 31.01.2022 17:05, Anthony PERARD wrote:
> On Thu, Jan 27, 2022 at 04:01:33PM +, Jane Malalane wrote:
>> --- a/tools/libs/light/libxl_x86.c
>> +++ b/tools/libs/light/libxl_x86.c
>> @@ -819,11 +825,44 @@ void
>> libxl__arch_domain_create_info_setdefault(libxl__gc *gc,
>> {
>> }
>>
>> -voi
On 1/30/22 22:46, Juergen Gross wrote:
> On 30.01.22 20:17, Randy Dunlap wrote:
>> It is better/preferred not to include file names in source files
>> because (a) they are not needed and (b) they can be incorrect,
>> so just delete this incorrect file name.
>>
>> Signed-off-by: Randy Dunlap
>>
On Thu, Jan 27, 2022 at 04:01:33PM +, Jane Malalane wrote:
> diff --git a/docs/man/xl.conf.5.pod.in b/docs/man/xl.conf.5.pod.in
> index df20c08137..2d0a59d019 100644
> --- a/docs/man/xl.conf.5.pod.in
> +++ b/docs/man/xl.conf.5.pod.in
> @@ -107,6 +107,18 @@ Sets the default value for the C
> do
Hi,
On 31/01/2022 12:05, Jan Beulich wrote:
> On 27.01.2022 17:01, Jane Malalane wrote:
>> Introduce a new per-domain creation x86 specific flag to
>> select whether hardware assisted virtualization should be used for
>> x{2}APIC.
>>
>> A per-domain option is added to xl in order to select the usag
On 28/01/2022 17:04, Anthony PERARD wrote:
> 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 impl
On 31.01.2022 16:06, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>>> rom->type = VPCI_BAR_EMPTY;
>>> }
>>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>>> index ed127a08a953..0a73b14a92dc 100644
>>> --- a/xen/include/xen/vpci.h
>>> +++ b/xen/include/xen/vpci.h
>
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
a
On 1/31/22 03:27, Thomas Gleixner wrote:
On Sun, Jan 30 2022 at 09:12, Guenter Roeck wrote:
On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
This patch results in the following runtime warning when booting x86
(32 bit) nosmp images from NVME in qemu.
[ 14.825482] nvme nvme0: 1
Hi, Roger!
>> rom->type = VPCI_BAR_EMPTY;
>> }
>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>> index ed127a08a953..0a73b14a92dc 100644
>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
>> @@ -68,7 +68,10 @@ struct vpci {
>> struct vpci_head
>>> I wonder whether we need to protect the added code with
>>> CONFIG_HAS_VPCI_GUEST_SUPPORT, this would effectively be dead code
>>> otherwise. Long term I don't think we wish to differentiate between
>>> dom0 and domU vPCI support at build time, so I'm unsure whether it's
>>> helpful to pollute
On 31/01/2022 11:23, Andrew Cooper wrote:
> On 31/01/2022 10:15, Jan Beulich wrote:
>> On 28.01.2022 14:29, Andrew Cooper wrote:
>>> Signed-off-by: Andrew Cooper
>> Preferably with the statement above softened a little:
>> Reviewed-by: Jan Beulich
> Thanks.
Commit message now reads:
---8<---
'i
On 31/01/2022 12:55, Jan Beulich wrote:
> On 28.01.2022 14:29, Andrew Cooper wrote:
>> --- a/xen/arch/x86/hvm/svm/entry.S
>> +++ b/xen/arch/x86/hvm/svm/entry.S
>> @@ -55,11 +55,12 @@ __UNLIKELY_END(nsvm_hap)
>> mov %rsp, %rdi
>> call svm_vmenter_helper
>>
>> -mov VCPU_a
On 31.01.22 15:51, Jan Beulich wrote:
> On 31.01.2022 14:41, Oleksandr Andrushchenko wrote:
>> On 31.01.22 15:36, Jan Beulich wrote:
>>> On 31.01.2022 14:30, Oleksandr Andrushchenko wrote:
On 31.01.22 13:39, Jan Beulich wrote:
> On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
>>
On 31.01.2022 14:41, Oleksandr Andrushchenko wrote:
> On 31.01.22 15:36, Jan Beulich wrote:
>> On 31.01.2022 14:30, Oleksandr Andrushchenko wrote:
>>> On 31.01.22 13:39, Jan Beulich wrote:
On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
> On 31.01.22 13:10, Roger Pau Monné wrote:
>
On 31.01.22 15:36, Jan Beulich wrote:
> On 31.01.2022 14:30, Oleksandr Andrushchenko wrote:
>>
>> On 31.01.22 13:39, Jan Beulich wrote:
>>> On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
On 31.01.22 13:10, Roger Pau Monné wrote:
> Right (see my previous reply to this comment). I thi
On 31.01.2022 14:30, Oleksandr Andrushchenko wrote:
>
>
> On 31.01.22 13:39, Jan Beulich wrote:
>> On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
>>> On 31.01.22 13:10, Roger Pau Monné wrote:
Right (see my previous reply to this comment). I think it would be
easier (and cleaner) if
On 31.01.22 13:39, Jan Beulich wrote:
> On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
>> On 31.01.22 13:10, Roger Pau Monné wrote:
>>> Right (see my previous reply to this comment). I think it would be
>>> easier (and cleaner) if you switched the default behavior regarding
>>> unhandled reg
flight 167963 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167963/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 28.01.2022 14:29, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -55,11 +55,12 @@ __UNLIKELY_END(nsvm_hap)
> mov %rsp, %rdi
> call svm_vmenter_helper
>
> -mov VCPU_arch_msrs(%rbx), %rax
> -mov VCPUMSR_spec_
On 27.01.2022 17:01, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted vitualization, a
On 31/01/2022 10:39, Jan Beulich wrote:
> On 28.01.2022 14:29, Andrew Cooper wrote:
>> 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 explicit
On 27.01.2022 17:01, Jane Malalane wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -343,6 +343,12 @@ static int vmx_init_vmcs_config(bool bsp)
> MSR_IA32_VMX_PROCBASED_CTLS2, &mismatch);
> }
>
> +/* Check whether hardware supports accelera
On 31/01/2022 10:33, Jan Beulich wrote:
> On 28.01.2022 14:29, Andrew Cooper wrote:
>> 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
On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
> On 31.01.22 13:10, Roger Pau Monné wrote:
>> Right (see my previous reply to this comment). I think it would be
>> easier (and cleaner) if you switched the default behavior regarding
>> unhandled register access for domUs at the start of the ser
On 31/01/2022 10:20, Jan Beulich wrote:
> On 28.01.2022 14:29, Andrew Cooper wrote:
>> 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 inf
On Mon, Jan 31, 2022 at 11:23:48AM +, Oleksandr Andrushchenko wrote:
>
>
> On 31.01.22 13:10, Roger Pau Monné wrote:
> > On Mon, Jan 31, 2022 at 10:40:47AM +, Oleksandr Andrushchenko wrote:
> >> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> >>> Hi, Roger!
> >>>
> >>> On 12.01.22 14:
On 31.01.22 13:27, Roger Pau Monné wrote:
> On Mon, Jan 31, 2022 at 11:04:29AM +, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 31.01.22 12:54, Jan Beulich wrote:
>>> On 31.01.2022 11:40, Oleksandr Andrushchenko wrote:
On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> Hi, Rog
On Sun, Jan 30 2022 at 09:12, Guenter Roeck wrote:
> On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
> This patch results in the following runtime warning when booting x86
> (32 bit) nosmp images from NVME in qemu.
>
> [ 14.825482] nvme nvme0: 1/0/0 default/read/poll queues
> ILL
On Mon, Jan 31, 2022 at 11:04:29AM +, Oleksandr Andrushchenko wrote:
> Hi, Jan!
>
> On 31.01.22 12:54, Jan Beulich wrote:
> > On 31.01.2022 11:40, Oleksandr Andrushchenko wrote:
> >> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> >>> Hi, Roger!
> >>>
> >>> On 12.01.22 14:35, Roger Pau Mon
On 31.01.22 13:10, Roger Pau Monné wrote:
> On Mon, Jan 31, 2022 at 10:40:47AM +, Oleksandr Andrushchenko wrote:
>> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
>>> Hi, Roger!
>>>
>>> On 12.01.22 14:35, Roger Pau Monné wrote:
> +static void guest_rom_write(const struct pci_dev *pdev,
On 31/01/2022 10:15, Jan Beulich wrote:
> On 28.01.2022 14: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.
> I can buy th
On Mon, Jan 31, 2022 at 11:15:09AM +, Andrew Cooper wrote:
> On 31/01/2022 09:41, Roger Pau Monné wrote:
> > On Fri, Jan 28, 2022 at 01:29:19PM +, Andrew Cooper wrote:
> >> This is a statement of hardware behaviour, and not related to controls for
> >> the
> >> guest kernel to use. Pass i
On 27.01.2022 17:01, 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-speci
On 31/01/2022 09:41, Roger Pau Monné wrote:
> On Fri, Jan 28, 2022 at 01:29:19PM +, 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.
>>
> Not really related to this patch p
On Mon, Jan 31, 2022 at 10:40:47AM +, Oleksandr Andrushchenko wrote:
> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> > Hi, Roger!
> >
> > On 12.01.22 14:35, Roger Pau Monné wrote:
> >>
> >>> +static void guest_rom_write(const struct pci_dev *pdev, unsigned int reg,
> >>> +
On Mon, Jan 31, 2022 at 09:47:07AM +, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 12.01.22 14:35, Roger Pau Monné wrote:
> > On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >> +static void guest_rom_write(const struct pci_de
Hi, Jan!
On 31.01.22 12:54, Jan Beulich wrote:
> On 31.01.2022 11:40, Oleksandr Andrushchenko wrote:
>> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
>>> Hi, Roger!
>>>
>>> On 12.01.22 14:35, Roger Pau Monné wrote:
> +static void guest_rom_write(const struct pci_dev *pdev, unsigned int reg
On Mon, Jan 31, 2022 at 09:53:29AM +, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 12.01.22 19:34, Roger Pau Monné wrote:
> > A couple more comments I realized while walking the dog.
> >
> > On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr And
On 31.01.2022 11:40, Oleksandr Andrushchenko wrote:
> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 12.01.22 14:35, Roger Pau Monné wrote:
>>>
+static void guest_rom_write(const struct pci_dev *pdev, unsigned int reg,
+uint32_t val, v
On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 12.01.22 14:35, Roger Pau Monné wrote:
>>
>>> +static void guest_rom_write(const struct pci_dev *pdev, unsigned int reg,
>>> +uint32_t val, void *data)
>>> +{
>>> +}
>>> +
>>> +static uint32_t guest_ro
On 28.01.2022 14:29, Andrew Cooper wrote:
> 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.
>
> S
On 28.01.2022 14:29, Andrew Cooper wrote:
> 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 perf
On 28.01.2022 14:29, Andrew Cooper wrote:
> 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 b
On 28.01.2022 14:29, Andrew Cooper wrote:
> 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 o
On 28.01.2022 14: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.
I can buy this for the flushing aspect; I'm less certain ab
On 30.01.2022 04:17, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Tuesday, January 11, 2022 12:23 AM
>>
>> In order to be able to insert/remove super-pages we need to allow
>> callers of the walking function to specify at which point to stop the
>> walk.
>>
>> For intel_iommu_lookup_page() int
On 31.01.2022 10:57, Roger Pau Monné wrote:
> On Fri, Jan 28, 2022 at 07:48:44AM +0100, Jan Beulich wrote:
>> On 26.01.2022 16:45, Roger Pau Monné wrote:
>>> On Wed, Jan 26, 2022 at 03:08:28PM +0100, Jan Beulich wrote:
On 26.01.2022 13:26, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm.c
>
On Fri, Jan 28, 2022 at 07:48:44AM +0100, Jan Beulich wrote:
> On 26.01.2022 16:45, Roger Pau Monné wrote:
> > On Wed, Jan 26, 2022 at 03:08:28PM +0100, Jan Beulich wrote:
> >> On 26.01.2022 13:26, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm.c
> >>> +++ b/xen/arch/x86/mm.c
> >>> @@ -479,6 +4
Hi, Roger!
On 12.01.22 19:34, Roger Pau Monné wrote:
> A couple more comments I realized while walking the dog.
>
> On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers when assigning PCI device to a do
Hi, Roger!
On 12.01.22 14:35, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers when assigning PCI device to a domain
>> and remove those when de-assigning. This allows havin
On Fri, Jan 28, 2022 at 01:29:19PM +, 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.
>
Not really related to this patch per se, but I think we should expose
AMD_SSBD uncondit
flight 167961 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167961/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass
in 167951
test-armhf-armhf-xl-rtd
On 28.01.2022 22:33, Stefano Stabellini wrote:
> 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
On 31/01/2022 00:37, Dmitry Osipenko wrote:
> Replace legacy pm_power_off with kernel_can_power_off() helper that
> is aware about chained power-off handlers.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/emif.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: K
On 30.01.2022 09:42, Juergen Gross wrote:
> The entries referring to tools/security have become stale more than
> 10 years ago. Remove them.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Hi, Roger!
On 31.01.22 10:56, Roger Pau Monné wrote:
> On Fri, Jan 28, 2022 at 02:15:08PM +, Oleksandr Andrushchenko wrote:
>> 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 Mo
On 28.01.2022 16:52, Anthony PERARD wrote:
> 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 l
On 28.01.2022 16:04, Anthony PERARD wrote:
> 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.
>>>
On Fri, Jan 28, 2022 at 02:15:08PM +, Oleksandr Andrushchenko wrote:
> 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,
On 28.01.2022 17:49, Tamas K Lengyel wrote:
> On Thu, Jan 27, 2022 at 10:07 AM Jan Beulich wrote:
>> @@ -2549,15 +2546,16 @@ int p2m_altp2m_propagate_change(struct d
>>
>> for ( i = 0; i < MAX_ALTP2M; i++ )
>> {
>> +p2m_type_t t;
>> +p2m_access_t a;
>> +
>> if (
Hi, Roger!
On 13.01.22 13:40, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:42PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +/* Notify vPCI that device is assigned to guest. */
>> +int vpci_assign_device(struct domai
Hi, Roger!
On 12.01.22 14:12, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:42PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a PCI device gets assigned/de-assigned some work on vPCI side needs
>> to be done for that device. Introduce a pair of hooks
84 matches
Mail list logo
