On 8 November 2024 03:26:58 GMT-08:00, "H. Peter Anvin" wrote:
>On November 8, 2024 6:22:41 AM GMT+01:00, David Woodhouse
> wrote:
>>From: David Woodhouse
>>
>>Now that it's handled sanely by a linker script we can have actual data,
>>and just use %
On Fri, 2024-11-08 at 05:22 +, David Woodhouse wrote:
>
> @@ -128,7 +138,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
> /* set return address to 0 if not preserving context */
> pushq $0
> /* store the start address on the stack */
> -
From: David Woodhouse
Now that it's handled sanely by a linker script we can have actual data,
and just use %rip-relative addressing to access it.
If we could call the *copy* instead of the original relocate_kernel in
the kernel text, then we could use %rip-relative addressing every
From: David Woodhouse
---
arch/x86/include/asm/sections.h | 1 +
arch/x86/kernel/machine_kexec_64.c | 6 --
arch/x86/kernel/relocate_kernel_64.S | 6 +-
arch/x86/kernel/vmlinux.lds.S| 12 +++-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch
On Tue, 2024-11-05 at 18:47 -0800, H. Peter Anvin wrote:
>
>
> Yes, the linker script needs to happen.
How does this look? Need to do 32-bit too, and actually test the
preserve_context case. And then port the debugging bits on top...
David Woodhouse (2):
x86/kexec: Use link
On Tue, 2024-11-05 at 18:47 -0800, H. Peter Anvin wrote:
>
> Yes, the linker script needs to happen.
>
> This is a case of doing it right vs doing it quickly.
That may just tip it over the edge of how much work it's worth doing to
clean up the debug hack that I implemented for my own use, and m
On Tue, 2024-11-05 at 13:37 -0800, H. Peter Anvin wrote:
>
> Looking at your code, you have a much bigger problem here:
>
> +/*
> + * This allows other types of serial ports to be used.
> + * - %al: Character to be printed (no clobber %rax)
> + * - %rdx: MMIO address or port.
> + */
> +.macro p
On Tue, 2024-11-05 at 12:50 -0800, H. Peter Anvin wrote:
> On November 5, 2024 12:38:10 PM PST, "Woodhouse, David"
> wrote:
> > On Sun, 2024-11-03 at 05:35 +, David Woodhouse wrote:
> > >
> > > +
> > > +/* Print the byte in %bl, clobber %r
On Tue, 2024-11-05 at 10:00 +, Huang, Kai wrote:
> On Sun, 2024-11-03 at 05:35 +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Add more comments explaining what each register contains, and save the
> > preserve_context flag to a non-clobbered regi
From: David Woodhouse
There's no need to swap pages (which involves three memcopies for each
page) in the plain kexec case. Just do a single copy from source to
destination page.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 4
1 file changed, 4 inser
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 110 +++
1 file changed, 110 insertions(+)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocate_kernel_64.S
index 2af4ce593645..2a2a6e693e18 100644
from actually swapping pages
in the case of a plain kexec without preserve_context. Unless I'm missing
something, that's just a pointless waste of time.
David Woodhouse (7):
x86/kexec: Clean up and document register use in relocate_kernel_64.S
x86/kexec: Use named labels i
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocate_kernel_64.S
index 1c18cffe5229..bba37db6d437 100644
--- a/arch/x86/kernel
From: David Woodhouse
There are some failure modes which lead to triple-faults in the
relocate_kernel function, which is fairly much undebuggable for normal
mortals.
Adding a GDT in the relocate_kernel environment is step 1 towards being
able to catch faults and do something more useful
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 80 ++--
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocate_kernel_64.S
index 2a2a6e693e18
From: David Woodhouse
Add more comments explaining what each register contains, and save the
preserve_context flag to a non-clobbered register sooner, to keep things
simpler.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 17 +
1 file changed, 13
From: David Woodhouse
Make the code a little more readable.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 30 ++--
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel
From: David Woodhouse
The VMCLOCK device gives support for accurate timekeeping even across
live migration, unlike the KVM PTP clock. To help ensure that users can
always use ptp_vmclock where it's available in preference to ptp_kvm,
set it to 'default PTP_1588_CLOCK_VMCLOCK&#
From: David Woodhouse
The VMCLOCK device gives support for accurate timekeeping even across
live migration, unlike the KVM PTP clock. To help ensure that users can
always use ptp_vmclock where it's available in preference to ptp_kvm,
set it to 'default PTP_1588_CLOCK_VMCLOCK&#
On Thu, 2024-10-31 at 17:56 +, Oliver Upton wrote:
> On Sat, 19 Oct 2024 18:15:41 +0100, David Woodhouse wrote:
> > The PSCI v1.3 spec (https://developer.arm.com/documentation/den0022)
> > adds support for a SYSTEM_OFF2 function enabling a HIBERNATE_OFF state
> > which is
On Fri, 2024-10-25 at 13:40 -0700, Oliver Upton wrote:
>
> No. You're leaving the work for the reader to:
>
> (1) Figure out what you're talking about
> (2) Go dig up an "earlier version" of the spec
> (3) Realise that it means certain hypervisors only take 0x0 as an
> argument
No. There
On Thu, 2024-10-31 at 12:15 +, Catalin Marinas wrote:
> On Fri, Oct 25, 2024 at 10:12:41PM +, Oliver Upton wrote:
> > On Sat, 19 Oct 2024 18:15:41 +0100, David Woodhouse wrote:
> > > The PSCI v1.3 spec (https://developer.arm.com/documentation/den0022)
> > > add
On 28 October 2024 17:12:56 CET, Jakub Kicinski wrote:
>On Sat, 19 Oct 2024 18:49:24 +0100 David Woodhouse wrote:
>> > Yes please and thank you! We gotta straighten it out before
>> > the merge window.
>>
>> Hm, as I (finally) come to do that, I realise that
On 28 October 2024 17:12:56 CET, Jakub Kicinski wrote:
>On Sat, 19 Oct 2024 18:49:24 +0100 David Woodhouse wrote:
>> > Yes please and thank you! We gotta straighten it out before
>> > the merge window.
>>
>> Hm, as I (finally) come to do that, I realise that
On 24 October 2024 21:57:38 CEST, Oliver Upton wrote:
>On Thu, Oct 24, 2024 at 05:56:09PM +0200, David Woodhouse wrote:
>> On 24 October 2024 17:44:49 CEST, Oliver Upton
>> wrote:
>> >IIUC, you're really wanting to 0x0 because there are hypervisors out
>> >
On 24 October 2024 17:44:49 CEST, Oliver Upton wrote:
>Hi,
>
>On Thu, Oct 24, 2024 at 03:48:26PM +0200, David Woodhouse wrote:
>> On 24 October 2024 14:54:41 CEST, Miguel Luis wrote:
>> >Perhaps spec. F.b. could be accommodated by first i
On 24 October 2024 14:54:41 CEST, Miguel Luis wrote:
>Perhaps spec. F.b. could be accommodated by first invoking SYSTEM_OFF2 with
>PSCI_1_3_OFF_TYPE_HIBERNATE_OFF and checking its return value in case of a
>fallback to an invocation with 0x0 ?
I wasn't aware there was any point. Are there any hyp
On Wed, 2024-10-23 at 08:29 -0500, Kalra, Ashish wrote:
>
> On 10/23/2024 6:39 AM, David Woodhouse wrote:
> > On Wed, 2024-10-23 at 06:07 -0500, Kalra, Ashish wrote:
> > >
> > > As mentioned above, about the same 2MB page containing the end portion of
> >
On Wed, 2024-10-23 at 06:07 -0500, Kalra, Ashish wrote:
>
> As mentioned above, about the same 2MB page containing the end portion of the
> RMP table and a page allocated for kexec and
> looking at the e820 memory map dump here:
>
> > > > [ 0.00] BIOS-e820: [mem 0x00bfbe00-0x000
On Tue, 2024-10-22 at 17:06 -0500, Steve Wahl wrote:
> On Tue, Oct 22, 2024 at 07:51:38PM +0100, David Woodhouse wrote:
> > I spent all of Monday setting up a full GDT, IDT and exception handler
> > for the relocate_kernel() environment¹, and I think these reports may
> >
On Thu, 2024-03-14 at 17:25 +0800, Dave Young wrote:
> On Thu, 14 Mar 2024 at 00:18, Steve Wahl wrote:
> >
> > On Wed, Mar 13, 2024 at 07:16:23AM -0500, Eric W. Biederman wrote:
> > >
> > > Kexec happens on identity mapped page tables.
> > >
> > > The files of interest are machine_kexec_64.c an
On Mon, 2024-10-21 at 15:51 +0100, Andrew Cooper wrote:
> On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> > On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> > > On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> > > > When using AMD-VI
On Mon, 2024-10-21 at 12:53 +0100, Andrew Cooper wrote:
>
> > I don't quite follow how you need a sentinel value. How could you ever
> > *not* know it, given that you have to write it to the RTE?
> >
> > (And you should *also* just use the pin# like Linux does, as I said).
>
> Because Xen is ins
On Mon, 2024-10-21 at 12:38 +0100, Andrew Cooper wrote:
> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> > On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> >
> > >
> > > +/*
> > > + * Store the EOI handle when using interrupt remapping.
> > > + *
> > > + * If using AMD-Vi interrupt remapping the I
rictly it would
> only be required for AMD-Vi.
>
> Reported-by: Willi Junga
> Suggested-by: David Woodhouse
> Fixes: 2ca9fbd739b8 ('AMD IOMMU: allocate IRTE entries instead of using a
> static mapping')
> Signed-off-by: Roger Pau Monné
Hm, couldn't we just have used
On Mon, 2024-10-21 at 10:55 +0100, Alejandro Vallejo wrote:
> On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previous to
>
> For
On Mon, 2024-10-14 at 13:12 -0700, Jakub Kicinski wrote:
> On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote:
> > On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> > > On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> > > >
On Mon, 2024-10-14 at 13:12 -0700, Jakub Kicinski wrote:
> On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote:
> > On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> > > On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> > > >
From: David Woodhouse
The v1.3 PSCI spec (https://developer.arm.com/documentation/den0022) adds
the SYSTEM_OFF2 function. Add definitions for it and its hibernation type
parameter.
Signed-off-by: David Woodhouse
---
include/uapi/linux/psci.h | 5 +
1 file changed, 5 insertions(+)
diff
From: David Woodhouse
The PSCI v1.3 specification adds support for a SYSTEM_OFF2 function
which is analogous to ACPI S4 state. This will allow hosting
environments to determine that a guest is hibernated rather than just
powered off, and handle that state appropriately on subsequent launches
From: David Woodhouse
Signed-off-by: David Woodhouse
---
.../testing/selftests/kvm/aarch64/psci_test.c | 93 +++
1 file changed, 93 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/psci_test.c
b/tools/testing/selftests/kvm/aarch64/psci_test.c
index 61731a950def
in the final
version of the spec, and expands the test to cover both forms as well as
checking that a non-zero second argument is correctly rejected.
David Woodhouse (6):
firmware/psci: Add definitions for PSCI v1.3 specification
KVM: arm64: Add PSCI v1.3 SYSTEM_OFF2 function for
From: David Woodhouse
As with PSCI v1.1 in commit 512865d83fd9 ("KVM: arm64: Bump guest PSCI
version to 1.1"), expose v1.3 to the guest by default. The SYSTEM_OFF2
call which is exposed by doing so is compatible for userspace because
it's just a new flag in the event that
From: David Woodhouse
Pass through the SYSTEM_OFF2 function for hibernation, just like SYSTEM_OFF.
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
b/arch/arm64/kvm/hyp/nvhe/psci
From: David Woodhouse
The PSCI v1.3 specification adds support for a SYSTEM_OFF2 function
which is analogous to ACPI S4 state. This will allow hosting
environments to determine that a guest is hibernated rather than just
powered off, and ensure that they preserve the virtual environment
On Tue, 2024-10-15 at 10:16 -0700, Oliver Upton wrote:
>
> > After looking at this again, I think we should do one of the following:
> >
> > - TEST_REQUIRE() that the PSCI version is at least v1.3, making the
> > dependency clear on older kernels.
> >
> > - TEST_REQUIRE() for v1.3, which
On Fri, 2024-10-11 at 17:21 -0700, Sean Christopherson wrote:
>
> > +
> > + /* We should never reach this point */
>
> No pronouns. Yes, it's nitpicky, but "we" gets _very_ ambiguous when "we"
> could
> mean the admin, the user, the VMM, KVM, the guest, etc.
>
> > + GUEST_ASSERT(0)
On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> > +config PTP_1588_CLOCK_VMCLOCK
> > + tristate "Virtual machine PTP clock"
> > + depends on X86_TSC || ARM_ARCH_TIMER
> > +
On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> > +config PTP_1588_CLOCK_VMCLOCK
> > + tristate "Virtual machine PTP clock"
> > + depends on X86_TSC || ARM_ARCH_TIMER
> > +
On Tue, 2024-10-01 at 08:33 -0700, Oliver Upton wrote:
> On Thu, Sep 26, 2024 at 07:37:59PM +0100, David Woodhouse wrote:
> > +static void guest_test_system_off2(void)
> > +{
> > + uint64_t ret;
> > +
> > + /* assert that SYSTEM_OFF2 is discove
On Thu, 2024-03-07 at 09:39 +0100, Jan Beulich wrote:
> On 06.03.2024 18:28, Sébastien Chaumat wrote:
> > Reasoning backward (using a kernel without the pinctrl_amd driver to
> > > ensure xen only is at stake) :
> > > checking the diff in IOAPIC between bare metal and xen (IRQ7 is on
> > > pin
On Tue, 2024-10-08 at 12:04 +0100, Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 14:53:54 +0100
> David Woodhouse wrote:
>
> >
> > + aml_append(dev, aml_name_decl("_HID",
> > aml_string("AMZNC10C")));
>
> Nice _HID :)
Can't take
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
On Wed, 2024-10-02 at 13:33 +0200, Igor Mammedov wrote:
>
> It's interesting as an experiment, to prove that Windows is riddled with bugs.
> (well, and it could serve as starting point to report issue to MS)
> But I'd rather Microsoft fix bugs on their side, instead of putting hacks in
> QEMU.
Ab
nction with 'deliver_now==true'. If an IOMMU lookup *still*
fails, that's when the IOMMU will actually raise a fault.
That function allows us to collect all the various MSI format nonsense
in *once* place and handle it cleanly, converting to the KVM X2APIC MSI
format which both KV
On Sat, 2024-09-28 at 15:59 +0100, David Woodhouse wrote:
> On Tue, 2024-07-02 at 05:17 +, Sandesh Patel wrote:
> >
> > The error is due to invalid MSIX routing entry passed to KVM.
> >
> > The VM boots fine if we attach a vIOMMU but adding a vIOMMU can
&
On Tue, 2024-07-02 at 05:17 +, Sandesh Patel wrote:
>
> The error is due to invalid MSIX routing entry passed to KVM.
>
> The VM boots fine if we attach a vIOMMU but adding a vIOMMU can
> potentially result in IO performance loss in guest.
> I was interested to know if someone could boot a la
On Fri, 2024-09-27 at 12:43 +, Miguel Luis wrote:
>
> The common factor being the bit offset in the bitmap for SYSTEM_OFF2 discovery
> and argument to call SYSTEM_OFF2 as well. Would it be clearer something like:
>
> #define PSCI_1_3_HIBERNATE_TYPE_OFF BIT(0)
I've updated the tree at
https:
On Fri, 2024-09-27 at 12:43 +, Miguel Luis wrote:
> Hi David,
>
> > On 26 Sep 2024, at 16:30, David Woodhouse wrote:
> >
> > On Thu, 2024-09-26 at 09:56 +, Miguel Luis wrote:
> > >
> > > > +/* PSCI v1.3 hibernate type for SYSTEM_OFF2 */
&
From: David Woodhouse
Signed-off-by: David Woodhouse
---
.../testing/selftests/kvm/aarch64/psci_test.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/psci_test.c
b/tools/testing/selftests/kvm/aarch64/psci_test.c
index 61731a950def
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/hypercalls.c | 2 ++
arch/arm64/kvm/psci.c | 6 +-
include/kvm/arm_psci.h | 4 +++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
From: David Woodhouse
The v1.3 PSCI spec (https://developer.arm.com/documentation/den0022) adds
the SYSTEM_OFF2 function. Add definitions for it and its hibernation type
parameter.
Signed-off-by: David Woodhouse
---
include/uapi/linux/psci.h | 5 +
1 file changed, 5 insertions(+)
diff
From: David Woodhouse
The PSCI v1.3 specification adds support for a SYSTEM_OFF2 function
which is analogous to ACPI S4 state. This will allow hosting
environments to determine that a guest is hibernated rather than just
powered off, and ensure that they preserve the virtual environment
From: David Woodhouse
Pass through the SYSTEM_OFF2 function for hibernation, just like SYSTEM_OFF.
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
b/arch/arm64/kvm/hyp/nvhe/psci
rgument; that's for userspace
to worry about.
David Woodhouse (5):
firmware/psci: Add definitions for PSCI v1.3 specification
KVM: arm64: Add PSCI v1.3 SYSTEM_OFF2 function for hibernation
KVM: arm64: Add support for PSCI v1.2 and v1.3
KVM: selftests: Add test for PSCI SYS
On Thu, 2024-09-26 at 09:56 +, Miguel Luis wrote:
>
> > +/* PSCI v1.3 hibernate type for SYSTEM_OFF2 */
> > +#define PSCI_1_3_HIBERNATE_TYPE_OFF 0
>
> Should it be 1 as hibernate type?
It is in discovery, as BIT(PSCI_1_3_HIBERNATE_TYPE_OFF) == 1<<0 == 1.
But using a bitmask was only suppose
On Thu, 2024-09-26 at 11:22 +0200, Paolo Abeni wrote:
>
> Please have a better run at checkpatch before your next submission,
> there are still a few ones - most relevant white-space damage.
Oops, apparently I missed one. Sorry about that.
I'll also add a MAINTAINERS entry, just to make checkpa
On Thu, 2024-09-26 at 11:22 +0200, Paolo Abeni wrote:
>
> Please have a better run at checkpatch before your next submission,
> there are still a few ones - most relevant white-space damage.
Oops, apparently I missed one. Sorry about that.
I'll also add a MAINTAINERS entry, just to make checkpa
On Thu, 2024-09-26 at 10:55 +0200, Francesco Lavra wrote:
> On Tue, 2024-09-24 at 17:05 +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The v1.3 PSCI spec (https://developer.arm.com/documentation/den0022)
> > adds
> > SYS
SPEND, and makes it depend only
on PSCI v1.3 being exposed to the guest.
Version 4 is no longer RFC, as the PSCI v1.3 spec is finally published.
Minor fixes from the last round of review, and an added KVM self test.
David Woodhouse (6):
firmware/psci: Add definitions for PSCI v1.3 spe
From: David Woodhouse
Pass through the SYSTEM_OFF2 function for hibernation, just like SYSTEM_OFF.
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
b/arch/arm64/kvm/hyp/nvhe/psci
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/hypercalls.c | 2 ++
arch/arm64/kvm/psci.c | 6 +-
include/kvm/arm_psci.h | 4 +++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
From: David Woodhouse
Signed-off-by: David Woodhouse
---
.../testing/selftests/kvm/aarch64/psci_test.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/psci_test.c
b/tools/testing/selftests/kvm/aarch64/psci_test.c
index 61731a950def
From: David Woodhouse
The PSCI v1.3 specification (alpha) adds support for a SYSTEM_OFF2 function
which is analogous to ACPI S4 state. This will allow hosting environments
to determine that a guest is hibernated rather than just powered off, and
ensure that they preserve the virtual environment
From: David Woodhouse
The PSCI v1.3 specification (alpha) adds support for a SYSTEM_OFF2
function which is analogous to ACPI S4 state. This will allow hosting
environments to determine that a guest is hibernated rather than just
powered off, and handle that state appropriately on subsequent
From: David Woodhouse
The v1.3 PSCI spec (https://developer.arm.com/documentation/den0022) adds
SYSTEM_OFF2, CLEAN_INV_MEMREGION and CLEAN_INV_MEMREGION_ATTRIBUTES
functions. Add definitions for them and their parameters, along with the
new TIMEOUT, RATE_LIMITED and BUSY error values.
Signed
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
On Tue, 2024-09-03 at 15:56 +0200, Paolo Abeni wrote:
> I'm sorry for the late feedback.
No problem. I've addressed it all apart from the uint64_t part. I'll
concede the pre-C99 nonsense where it matches existing code, but we've
always also allowed code in the kernel to use the proper C language
t
On Tue, 2024-09-03 at 15:56 +0200, Paolo Abeni wrote:
> I'm sorry for the late feedback.
No problem. I've addressed it all apart from the uint64_t part. I'll
concede the pre-C99 nonsense where it matches existing code, but we've
always also allowed code in the kernel to use the proper C language
t
On 11 September 2024 18:22:51 BST, Martin Pauly
wrote:
>Am 11.09.24 um 05:29 schrieb Daniel Lenski:
>> But as an end user of eduroam, why should I actually be concerned if
>> I've connected to a "counterfeit" eduroam access point, as long as it
>> gives me real internet connectivity? The eduroam
83932 NIC to
> > fail
> > when using the normal -nic user,model=dp83932 command line.
> >
>
> Cc: qemu-sta...@nongnu.org # v9.0
> Fixes: e104edbb9d ("hw/mips/jazz: use qemu_find_nic_info()")
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhous
On Fri, 2024-09-06 at 22:14 -0700, Daniel Lenski wrote:
> On Mon, Sep 2, 2024 at 4:56 AM Martin Pauly wrote:
> >
> > Am 01.09.24 um 06:32 schrieb Daniel Lenski:
> >
> > Actually, the original question came from the GUI side, i.e. Network
> > Manager.
> > A colleague of mine recently stumbled on
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
On Thu, 2024-08-22 at 12:49 +0100, Simon Horman wrote:
> Hi David,
>
> Sorry to be always the one with the nit-pick.
> Sparse complains about the line above, I believe because the
> type of st->clk->size is __le32.
>
> .../ptp_vmclock.c:562:13: warning: restricted __le32 degrades to integer
Oops
On Thu, 2024-08-22 at 12:49 +0100, Simon Horman wrote:
> Hi David,
>
> Sorry to be always the one with the nit-pick.
> Sparse complains about the line above, I believe because the
> type of st->clk->size is __le32.
>
> .../ptp_vmclock.c:562:13: warning: restricted __le32 degrades to integer
Oops
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The vmclock "device" provides a shared memory region with precision clock
information. By using shared memory, it is safe across Live Migration.
Like the KVM PTP clock, this can convert TSC-based cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
From: David Woodhouse
The vmclock "device" provides a shared memory region with precision clock
information. By using shared memory, it is safe across Live Migration.
Like the KVM PTP clock, this can convert TSC-based cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On 13 August 2024 00:59:40 BST, Sean Christopherson wrote:
>On Fri, Aug 02, 2024, David Woodhouse wrote:
>> On Fri, 2024-08-02 at 07:55 -0700, Sean Christopherson wrote:
>> > On Fri, Aug 02, 2024, David Woodhouse wrote:
>> > > On Thu, 2024-08-01 at 20:54 +0200, Thom
On Mon, 2024-08-12 at 11:25 +0100, Peter Maydell wrote:
>
> Will this also fix
> https://gitlab.com/qemu-project/qemu/-/issues/2496 ?
Almost certainly, yes.
smime.p7s
Description: S/MIME cryptographic signature
From: David Woodhouse
Oops, don't *delete* the model option when checking for 'help'.
Fixes: 64f75f57f9d2 ("net: Reinstate '-net nic, model=help' output as
documented in man page")
Reported-by: Hans
Signed-off-by: David Woodhouse
Cc: qemu-sta...@nongnu.org
On Fri, 2024-08-02 at 15:44 +, Michael Kelley wrote:
> Did a basic smoke test of this two-patch series on a Hyper-V Gen 1
> VM and on a Gen 2 VM. All looks good and behaves as expected.
>
> On the Gen 1 VM, the PIT is used briefly at boot (takes ~35 interrupts)
> before the Hyper-V synthetic t
On Fri, 2024-08-02 at 07:55 -0700, Sean Christopherson wrote:
> On Fri, Aug 02, 2024, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 20:54 +0200, Thomas Gleixner wrote:
> > > On Thu, Aug 01 2024 at 16:14, Michael Kelley wrote:
> > > > I don't have a conven
From: David Woodhouse
Leaving the PIT interrupt running can cause noticeable steal time for
virtual guests. The VMM generally has a timer which toggles the IRQ input
to the PIC and I/O APIC, which takes CPU time away from the guest. Even
on real hardware, running the counter may use power
From: David Woodhouse
According to the data sheet, writing the MODE register should stop the
counter (and thus the interrupts). This appears to work on real hardware,
at least modern Intel and AMD systems. It should also work on Hyper-V.
However, on some buggy virtual machines the mode change
On Fri, 2024-08-02 at 15:27 +0200, Thomas Gleixner wrote:
> > Top two commits of
> > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/clocks
> >
> > I'll repost properly if you're happy with them?
>
> Just make the disable unconditional.
Oops, thought I'd done that too. Turns
1 - 100 of 4136 matches
Mail list logo
