On 20.10.2021 01:34, Andrew Cooper wrote:
> On 22/09/2021 15:36, Jan Beulich wrote:
>> Doing this in amd_iommu_prepare() is too late for it, in particular, to
>> be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
>> to do. Moving it immediately ahead of amd_iommu_detect_acpi()
flight 165681 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165681/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165654
test-armhf-armhf-libvirt 16 save
flight 165679 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165679/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in
165636
test-amd64-amd64-xl-rtds 20 gu
On 22/09/2021 15:36, Jan Beulich wrote:
> Doing this in amd_iommu_prepare() is too late for it, in particular, to
> be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
> to do. Moving it immediately ahead of amd_iommu_detect_acpi() is
> (luckily) pretty simple, (pretty importan
On Tue, 19 Oct 2021, Bertrand Marquis wrote:
> Xen might not be able to discover at boot time all devices or some devices
> might appear after specific actions from dom0.
> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
> PCI devices to Xen.
> As those devices where not known
From: Josef Johansson
PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV
commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
functions") introduce functions pci_msi_update_mask() and
pci_msix_write_vector_ctrl() that is missing checks for
pci_msi_ignore_mask that exist
On Tue, 19 Oct 2021, Julien Grall wrote:
> On 19/10/2021 13:04, Sai Kiran Kumar Reddy Y wrote:
> > Hi,
> >
> > Thanks for your inputs. As you have mentioned, I tried to boot Xen directly
> > from EFI, thereby skipping GRUB. I made sure that kernel, xen.cfg and
> > ramdisk are on the first FAT part
On Tue, 19 Oct 2021, Juergen Gross wrote:
> On 19.10.21 01:25, Stefano Stabellini wrote:
> > Hi Juergen, Ian,
> >
> > This patch broke gitlab-ci:
> >
> > https://gitlab.com/xen-project/xen/-/jobs/1690080806
> >
> > ---
> > * Executing: /lib/rc/sh/openrc-run.sh /lib/rc/sh/openrc-run.sh
> > /etc
flight 165670 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165670/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 165640
Tests which did not succee
On Tue, Oct 19, 2021 at 10:15:05PM +0200, Josef Johansson wrote:
> On 10/19/21 21:57, Bjorn Helgaas wrote:
> > On Mon, Oct 18, 2021 at 08:22:32AM +0200, Josef Johansson wrote:
> I'll make an effort to do a better commit log. Thanks for reviewing the
> entry!
>
> What is the time frame for v5.15?
On 10/19/21 21:57, Bjorn Helgaas wrote:
> [+cc Marc]
>
> On Mon, Oct 18, 2021 at 08:22:32AM +0200, Josef Johansson wrote:
>> From: Josef Johansson
>>
>>
>> PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV
>>
>> 'commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
>> fun
[+cc Marc]
On Mon, Oct 18, 2021 at 08:22:32AM +0200, Josef Johansson wrote:
> From: Josef Johansson
>
>
> PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV
>
> 'commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> functions")' introduced functions pci_msi_update_mask
On Tue, Sep 21, 2021 at 03:40:20PM +, Peter Stuge wrote:
> Alec Brown wrote:
> > Below is how the layout of these logs would store their data.
> >
> > bf_log_header:
> >+---+
> > u32| version |
> > u32| size |
> >
On Sun, Sep 19, 2021 at 12:53:35AM +0200, Heinrich Schuchardt wrote:
>
>
> Am 18. September 2021 18:04:13 MESZ schrieb Alec Brown
> :
> >Hi everyone,
> >
> >I've been working on improving the specification for the firmware and
> >bootloader
> >log that Daniel Kiper has proposed and take into
Hi Penny,
On 15/10/2021 04:09, Penny Zheng wrote:
From: Stefano Stabellini
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domains that are direct-map memory map.
I would simply
Hi Penny,
On 15/10/2021 04:09, Penny Zheng wrote:
From: Stefano Stabellini
Cases where domU needs direct-map memory map:
* IOMMU not present in the system.
* IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few device
flight 165676 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165676/
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
flight 165658 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165658/
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
This patch serie is a follow-up after various findings on d59168dc05
("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
agreed in [1].
It does the following:
- enable vpci_add_handlers on x86 and not only on arm
- remove __hwdom_init flag for vpci_add_handlers
- add missing vpc
Xen might not be able to discover at boot time all devices or some devices
might appear after specific actions from dom0.
In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
PCI devices to Xen.
As those devices where not known from Xen before, the vpci handlers must
be properly in
flight 165671 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165671/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 90246a6d9f6fda3536d042d02867123caabe3aaa
baseline version:
ovmf 91a978ce7e0c7a327cff1
flight 165654 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165654/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165639
test-armhf-armhf-libvirt 16 save
On 19.10.2021 15:53, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 02:52:27PM +0200, Jan Beulich wrote:
>> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
>> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
>> order violation when the PoD lock is h
[adhoc play]
harness 14a279c4: osstest: explicitly enable building qemu-traditional
165675: truncated
flight 165675 xen-unstable play [play]
http://logs.test-lab.xenproject.org/osstest/logs/165675/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 16
On Tue, Oct 19, 2021 at 08:25:27AM +0200, Christoph Hellwig wrote:
> Use sync_blockdev instead of opencoding it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David Sterba
On Tue, Oct 19, 2021 at 02:52:27PM +0200, Jan Beulich wrote:
> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
> order violation when the PoD lock is held around it. Hence such flushing
> needs to be
Juergen Gross writes ("Re: [PATCH] OSStest: explicitly enable building
qemu-traditional"):
> On 19.10.21 15:04, Ian Jackson wrote:
> > OOI, have you done any kind of test on this ?
>
> No, this was a pure "lets do things in a similar way as the other
> options" approach.
Right.
> > I'm kind of
Hi,
> On 19 Oct 2021, at 14:17, Roger Pau Monné wrote:
>
> On Tue, Oct 19, 2021 at 02:39:17PM +0200, Jan Beulich wrote:
>> On 19.10.2021 12:40, Bertrand Marquis wrote:
>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -54,7 +54,7 @@ void vpci_remove_device(struct pci_dev
flight 165668 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 leak-check/basis(11) fail REGR.
vs. 165635
te
On Tue, Oct 19, 2021 at 03:14:25PM +0200, Jan Beulich wrote:
> On 19.10.2021 14:59, Roger Pau Monné wrote:
> > On Tue, Oct 19, 2021 at 01:58:38PM +0200, Jan Beulich wrote:
> >> On 19.10.2021 12:41, Roger Pau Monné wrote:
> >>> On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
> With
On 19.10.2021 15:17, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 02:39:17PM +0200, Jan Beulich wrote:
>> On 19.10.2021 12:40, Bertrand Marquis wrote:
>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -54,7 +54,7 @@ void vpci_remove_device(struct pci_dev *pdev)
>>>
On Tue, Oct 19, 2021 at 02:39:17PM +0200, Jan Beulich wrote:
> On 19.10.2021 12:40, Bertrand Marquis wrote:
> > --- a/xen/drivers/vpci/vpci.c
> > +++ b/xen/drivers/vpci/vpci.c
> > @@ -54,7 +54,7 @@ void vpci_remove_device(struct pci_dev *pdev)
> > pdev->vpci = NULL;
> > }
> >
> > -int __hwd
On 19.10.2021 14:59, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 01:58:38PM +0200, Jan Beulich wrote:
>> On 19.10.2021 12:41, Roger Pau Monné wrote:
>>> On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
>>>
> On 19 Oct 2021, at 13:26, Jan Beulich wrote:
>
> On 19.10.2021 12:40, Bertrand Marquis wrote:
>> This patch serie is a follow-up after various findings on d59168dc05
>> ("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
>> agreed in [1].
>>
>> It does the following:
>> -
On 19.10.21 15:04, Ian Jackson wrote:
Juergen Gross writes ("[PATCH] OSStest: explicitly enable building
qemu-traditional"):
It is planned to no longer build qemu-traditional per default.
In order to be able to continue running tests with ioemu-stubdom run
configure with --enable-qemu-traditio
Hi Jan,
> On 19 Oct 2021, at 13:29, Jan Beulich wrote:
>
> On 19.10.2021 12:40, Bertrand Marquis wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -756,11 +756,6 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>> if ( !pdev->domain )
>> {
>>
On 19/10/2021 13:04, Sai Kiran Kumar Reddy Y wrote:
Hi,
Hello,
Thanks for your inputs. As you have mentioned, I tried to boot Xen
directly from EFI, thereby skipping GRUB. I made sure that kernel,
xen.cfg and ramdisk are on the first FAT partition. I still get "All 128
bootinfo membank
Juergen Gross writes ("[PATCH] OSStest: explicitly enable building
qemu-traditional"):
> It is planned to no longer build qemu-traditional per default.
>
> In order to be able to continue running tests with ioemu-stubdom run
> configure with --enable-qemu-traditional.
>
> Signed-off-by: Juergen
It is planned to no longer build qemu-traditional per default.
In order to be able to continue running tests with ioemu-stubdom run
configure with --enable-qemu-traditional.
Signed-off-by: Juergen Gross
---
ts-xen-build | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ts
On Tue, Oct 19, 2021 at 01:58:38PM +0200, Jan Beulich wrote:
> On 19.10.2021 12:41, Roger Pau Monné wrote:
> > On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
> >> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
> >> write_p2m_entry() -> p2m_flush_nestedp2m() ca
With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
order violation when the PoD lock is held around it. Hence such flushing
needs to be deferred. Steal the approach from p2m_change_type_range().
(Note that
On Tue, Oct 19, 2021 at 02:08:38PM +0200, Jan Beulich wrote:
> On 19.10.2021 13:30, Roger Pau Monné wrote:
> > On Tue, Oct 19, 2021 at 09:07:39AM +0200, Jan Beulich wrote:
> >> From: Thomas Gleixner
> >>
> >> On recent Intel systems the HPET stops working when the system reaches PC10
> >> idle sta
On 19.10.2021 12:40, Bertrand Marquis wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -54,7 +54,7 @@ void vpci_remove_device(struct pci_dev *pdev)
> pdev->vpci = NULL;
> }
>
> -int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
> +int vpci_add_handlers(stru
On 19.10.2021 12:40, Bertrand Marquis wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -756,11 +756,6 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
> if ( !pdev->domain )
> {
> pdev->domain = hardware_domain;
> -#ifdef CONFIG_ARM
> -
On 19.10.2021 12:40, Bertrand Marquis wrote:
> This patch serie is a follow-up after various findings on d59168dc05
> ("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
> agreed in [1].
>
> It does the following:
> - enable vpci_add_handlers on x86 and not only on arm
> - remov
On 19.10.2021 13:30, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 09:07:39AM +0200, Jan Beulich wrote:
>> From: Thomas Gleixner
>>
>> On recent Intel systems the HPET stops working when the system reaches PC10
>> idle state.
>>
>> The approach of adding PCI ids to the early quirks to disable H
Hi,
Thanks for your inputs. As you have mentioned, I tried to boot Xen directly
from EFI, thereby skipping GRUB. I made sure that kernel, xen.cfg and
ramdisk are on the first FAT partition. I still get "All 128 bootinfo
membanks exhausted error". The following link has my grub.cfg config. file
and
On 19.10.2021 12:41, Roger Pau Monné wrote:
> On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
>> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
>> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
>> order violation when the PoD lock is h
On Tue, Oct 19, 2021 at 09:08:22AM +0200, Jan Beulich wrote:
> As of 724b55f48a6c ("x86: introduce MWAIT-based, ACPI-less CPU idle
> driver") they (also) live in asm/mwait.h; no idea how I missed the
> duplicates back at the time.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks
Hi Jan,
> On 19 Oct 2021, at 12:25, Jan Beulich wrote:
>
> On 19.10.2021 13:12, Ian Jackson wrote:
>> Bertrand Marquis writes ("[PATCH 0/3] Fixes: PCI devices passthrough on
>> Arm"):
>>> This patch serie is a follow-up after various findings on d59168dc05
>>> ("xen/arm: Enable the existing x86
On Tue, Oct 19, 2021 at 09:07:39AM +0200, Jan Beulich wrote:
> From: Thomas Gleixner
>
> On recent Intel systems the HPET stops working when the system reaches PC10
> idle state.
>
> The approach of adding PCI ids to the early quirks to disable HPET on
> these systems is a whack a mole game whic
On 19.10.2021 13:12, Ian Jackson wrote:
> Bertrand Marquis writes ("[PATCH 0/3] Fixes: PCI devices passthrough on Arm"):
>> This patch serie is a follow-up after various findings on d59168dc05
>> ("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
>> agreed in [1].
>>
>> It does
Juergen Gross writes ("[PATCH v2] tools: fix oom setting of xenstored"):
> Commit f282182af32939 ("tools/xenstore: set oom score for xenstore
> daemon on Linux") introduced a regression when not setting the oom
> value in the xencommons file. Fix that.
>
> Fixes: f282182af32939 ("tools/xenstore: s
Commit f282182af32939 ("tools/xenstore: set oom score for xenstore
daemon on Linux") introduced a regression when not setting the oom
value in the xencommons file. Fix that.
Fixes: f282182af32939 ("tools/xenstore: set oom score for xenstore daemon on
Linux")
Signed-off-by: Juergen Gross
---
V2:
Bertrand Marquis writes ("[PATCH 0/3] Fixes: PCI devices passthrough on Arm"):
> This patch serie is a follow-up after various findings on d59168dc05
> ("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
> agreed in [1].
>
> It does the following:
> - enable vpci_add_handlers on
flight 165657 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165657/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 91a978ce7e0c7a327cff1d9411b0e1c9dae8824a
baseline version:
ovmf 36b561623a4b8a6c7fea0
Jan Beulich writes ("Re: [PATCH] tools: fix oom setting of xenstored"):
> On 19.10.2021 09:31, Juergen Gross wrote:
> > I don't think set -e would have a negative effect on above line. The
> > bash man-page tells me that:
> >
> >The shell does not exit if the command that fails is part of the
On 19.10.2021 12:39, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 10:19:57AM +0200, Jan Beulich wrote:
>> On 19.10.2021 10:17, Jan Beulich wrote:
>>> On 19.10.2021 10:09, Roger Pau Monné wrote:
On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
> @@ -1229,8 +1242,9 @@ p2m_pod
On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
> order violation when the PoD lock is held around it. Hence such flushing
> needs to be
Add missing vpci handlers cleanup during pci_device_remove and in case
of error with iommu during pci_device_add.
Add empty static inline for vpci_remove_device when CONFIG_VPCI is not
defined.
Fixes: d59168dc05 ("xen/arm: Enable the existing x86 virtual PCI support
for ARM")
Signed-off-by: Bertr
vpci_add_handlers is called on during pci_device_add which can be called
at runtime through hypercall physdev_op.
Remove __hwdom_init as the call is not limited anymore to hardware
domain init.
Fixes: d59168dc05 ("xen/arm: Enable the existing x86 virtual PCI support
for ARM")
Signed-off-by: Bertra
Xen might not be able to discover at boot time all devices or some devices
might appear after specific actions from dom0.
In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
PCI devices to Xen.
As those devices where not known from Xen before, the vpci handlers must
be properly in
This patch serie is a follow-up after various findings on d59168dc05
("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
agreed in [1].
It does the following:
- enable vpci_add_handlers on x86 and not only on arm
- remove __hwdom_init flag for vpci_add_handlers
- add missing vpc
On Tue, Oct 19, 2021 at 10:19:57AM +0200, Jan Beulich wrote:
> On 19.10.2021 10:17, Jan Beulich wrote:
> > On 19.10.2021 10:09, Roger Pau Monné wrote:
> >> On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
> >>> @@ -1229,8 +1242,9 @@ p2m_pod_demand_populate(struct p2m_domai
> >>>
flight 165640 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165640/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 165576
test-amd64-amd64-qemuu-nested-amd 2
flight 165661 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165661/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 leak-check/basis(11) fail REGR.
vs. 165635
te
On 19.10.2021 10:17, Jan Beulich wrote:
> On 19.10.2021 10:09, Roger Pau Monné wrote:
>> On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
>>> @@ -1229,8 +1242,9 @@ p2m_pod_demand_populate(struct p2m_domai
>>> __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>>> }
>>>
On 19.10.2021 10:09, Roger Pau Monné wrote:
> On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
>> @@ -1229,8 +1242,9 @@ p2m_pod_demand_populate(struct p2m_domai
>> __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>> }
>>
>> -pod_unlock(p2m);
>> +pod_unlock_an
On Mon, Oct 11, 2021 at 10:17:08AM +0200, Jan Beulich wrote:
> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
> order violation when the PoD lock is held around it. Hence such flushing
> needs to be
On 19.10.2021 09:31, Juergen Gross wrote:
> On 19.10.21 08:54, Jan Beulich wrote:
>> On 19.10.2021 06:41, Juergen Gross wrote:
>>> --- a/tools/hotplug/Linux/launch-xenstore.in
>>> +++ b/tools/hotplug/Linux/launch-xenstore.in
>>> @@ -60,7 +60,7 @@ test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons &&
On Mon, Oct 18, 2021 at 09:16:30AM -0400, Tamas K Lengyel wrote:
> On Mon, Oct 18, 2021 at 4:26 AM Jan Beulich wrote:
>
> > On 25.08.2021 11:31, Jan Beulich wrote:
> > > We should not rely on guests to not use altp2m after reporting failure
> > > of HVMOP_altp2m_set_domain_state to them. Set "act
On 19.10.21 08:54, Jan Beulich wrote:
On 19.10.2021 06:41, Juergen Gross wrote:
--- a/tools/hotplug/Linux/launch-xenstore.in
+++ b/tools/hotplug/Linux/launch-xenstore.in
@@ -60,7 +60,7 @@ test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
@CONFIG_DIR@/@CONFIG_LEAF
echo "No x
As of 724b55f48a6c ("x86: introduce MWAIT-based, ACPI-less CPU idle
driver") they (also) live in asm/mwait.h; no idea how I missed the
duplicates back at the time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -24,6 +24,7 @@
#include
#include
#inc
From: Thomas Gleixner
On recent Intel systems the HPET stops working when the system reaches PC10
idle state.
The approach of adding PCI ids to the early quirks to disable HPET on
these systems is a whack a mole game which makes no sense.
Check for PC10 instead and force disable HPET if support
The workaround is a port of a recent Linux change, replacing earlier,
never accepted attempts to follow Linux in their PCI ID based working
around of the issue. The other patch is long due cleanup that I
happened to notice along the way.
1: x86/hpet: Use another crystalball to evaluate HPET usabil
75 matches
Mail list logo
