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
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
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
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
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
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
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
> >
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
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
>>
[+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
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
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
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
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
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
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
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
[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
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
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
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:
>
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
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
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
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
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()
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
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
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
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
> -
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
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
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
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é
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
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
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:
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
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
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 @@
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:
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:
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
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
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
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
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), );
>>> }
>>>
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), );
>> }
>>
>> -pod_unlock(p2m);
>> +
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
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
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
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
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
On 10/18/2021 11:25 PM, Christoph Hellwig wrote:
> Use sync_blockdev_nowait instead of opencoding it.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good.
Reviewed-by: Chaitanya Kulkarni
On 10/18/2021 11:25 PM, Christoph Hellwig wrote:
> There is no clear benefit in having this helper vs just open coding it.
>
> Signed-off-by: Christoph Hellwig
Especially if there is only one caller.
Looks good.
Reviewed-by: Chaitanya Kulkarni
On 10/18/2021 11:25 PM, Christoph Hellwig wrote:
> Use sync_blockdev_nowait instead of opencoding it.
>
> Signed-off-by: Christoph Hellwig
Looks good.
Reviewed-by: Chaitanya Kulkarni
On 10/18/2021 11:25 PM, Christoph Hellwig wrote:
> Use sync_blockdev instead of opencoding it.
>
> Signed-off-by: Christoph Hellwig
Looks good.
Reviewed-by: Chaitanya Kulkarni
On 10/18/2021 11:25 PM, Christoph Hellwig wrote:
> Use sync_blockdev instead of opencoding it.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good.
Reviewed-by: Chaitanya Kulkarni
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 xenstored found"
>
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job test-amd64-amd64-xl-qemuu-debianhvm-amd64
testid leak-check/basis(11)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
Get rid of the indirections and just provide a sync_bdevs
helper for the generic sync code.
Signed-off-by: Christoph Hellwig
---
block/bdev.c | 17 ++---
fs/internal.h | 6 --
fs/sync.c | 23 ---
include/linux/blkdev.h | 4
Use sync_blockdev_nowait instead of opencoding it.
Signed-off-by: Christoph Hellwig
---
fs/ntfs3/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c
index 859951d785cb2..a87ab3ad3cd38 100644
--- a/fs/ntfs3/inode.c
+++
Use sync_blockdev_nowait instead of opencoding it.
Signed-off-by: Christoph Hellwig
---
fs/fat/inode.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index de0c9b013a851..2fd5bfddb6958 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@
Use sync_blockdev instead of opencoding it.
Signed-off-by: Christoph Hellwig
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 2ec3b8ac8fa35..b51e4b464103e 100644
--- a/fs/btrfs/volumes.c
+++
Use sync_blockdev instead of opencoding it.
Signed-off-by: Christoph Hellwig
---
drivers/block/xen-blkback/xenbus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 33eba3df4dd9a..914587aabca0c
Instead offer a new sync_blockdev_nowait helper for the !wait case.
This new helper is exported as it will grow modular callers in a bit.
Signed-off-by: Christoph Hellwig
---
block/bdev.c | 11 ++-
fs/internal.h | 5 -
fs/sync.c | 7 ---
Hi Jens,
this series refactors parts of the sync code so that we have and always
use proper helpers for syncing data cached in the block device inode.
Diffstat:
block/bdev.c | 28 +++-
drivers/block/xen-blkback/xenbus.c |2 -
fs/btrfs/volumes.c
There is no clear benefit in having this helper vs just open coding it.
Signed-off-by: Christoph Hellwig
---
fs/sync.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/fs/sync.c b/fs/sync.c
index 1373a610dc784..0d6cdc507cb98 100644
---
89 matches
Mail list logo
