On Tue, 2024-03-19 at 14:47 +0100, Peter Hilber wrote:
> While the virtio-comment list is not available, now also CC'ing Parav,
> which may be interested in this virtio-rtc spec related discussion thread.
>
> On 14.03.24 15:19, David Woodhouse wrote:
> > On 14 March 2024 1
On 14 March 2024 11:13:37 CET, Peter Hilber
wrote:
>> To a certain extent, as long as the virtio-rtc device is designed to expose
>> time precisely and unambiguously, it's less important if the Linux kernel
>> *today* can use that. Although of course we should strive for that. Let's
>>
On 13 March 2024 17:50:48 GMT, Peter Hilber
wrote:
>On 13.03.24 13:45, David Woodhouse wrote:
>> Surely the whole point of this effort is to provide guests with precise
>> and *unambiguous* knowledge of what the time is?
>
>I would say, a fundamental point of thi
On Wed, 2024-03-13 at 13:58 +0100, Alexandre Belloni wrote:
> The TSC or whatever CPU counter/clock that is used to keep the system
> time is not an RTC, I don't get why it has to be exposed as such to the
> guests. PTP is fine and precise, RTC is not.
Ah, I see. But the point of the virtio_rtc
On Wed, 2024-03-13 at 10:45 +0100, Peter Hilber wrote:
> On 12.03.24 18:15, David Woodhouse wrote:
> > On Mon, 2024-03-11 at 19:24 +0100, Peter Hilber wrote:
> > > On 08.03.24 13:33, David Woodhouse wrote:
> > > > On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrot
On Wed, 2024-03-13 at 12:18 +0100, Alexandre Belloni wrote:
>
> I still don't know anything about virtio but under Linux, an RTC is
> always UTC (or localtime when dual booting but let's not care) and never
> accounts for leap seconds. Having an RTC and RTC driver behaving
> differently would be
On Mon, 2024-03-11 at 19:24 +0100, Peter Hilber wrote:
> On 08.03.24 13:33, David Woodhouse wrote:
> > On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrote:
> > > On 07.03.24 15:02, David Woodhouse wrote:
> > > > Hm, should we allow UTC? If you tell me the time in U
On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrote:
> On 07.03.24 15:02, David Woodhouse wrote:
> > On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
> > > RFC v3 updates
> > > --
> > >
> > > This series implements a driver for a v
On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
> RFC v3 updates
> --
>
> This series implements a driver for a virtio-rtc device conforming to spec
> RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to
> the PTP clock driver already present before.
>
>
On Tue, 2023-08-01 at 19:35 +0200, Christoph Hellwig wrote:
> It has recently come to my attention that nvidia is circumventing the
> protection added in 262e6ae7081d ("modules: inherit
> TAINT_PROPRIETARY_MODULE") by importing exports from their proprietary
> modules into an allegedly GPL
On Tue, 2021-03-30 at 12:59 -0400, Paolo Bonzini wrote:
> @@ -2686,13 +2688,13 @@ static int kvm_guest_time_update(struct
> kvm_vcpu *v)
> * If the host uses TSC clock, then passthrough TSC as stable
> * to the guest.
> */
> - spin_lock(>pvclock_gtod_sync_lock);
>
On 17 March 2021 13:32:35 GMT, Joerg Roedel wrote:
>On Wed, Mar 17, 2021 at 11:47:11AM +0000, David Woodhouse wrote:
>> If you've already moved the Stoney Ridge check out of the way,
>there's
>> no real reason why you can't just set
>init_state=IOMMU_CMDLINE_DISA
On Wed, 2021-03-17 at 10:10 +0100, Joerg Roedel wrote:
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index 3280e6f5b720..61dae1800b7f 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -2919,12 +2919,12 @@ static int __init state_next(void)
>
From: David Woodhouse
When the IOMMU is disabled, the driver still enumerates and initialises
the hardware in order to turn it off. Because IRQ remapping setup is
done early, the irqdomain is set up opportunistically.
In commit b34f10c2dc59 ("iommu/amd: Stop irq_remapping_select() matching
On Fri, 2021-02-26 at 05:14 -0500, Paolo Bonzini wrote:
> The Xen hypercall interface adds to the attack surface of the hypervisor
> and will be used quite rarely. Allow compiling it out.
>
> Suggested-by: Christoph Hellwig
> Cc: David Woodhouse
> Signed-off-by: Paolo Bonz
On Tue, 2021-02-16 at 15:10 +, David Woodhouse wrote:
> Actually it breaks before that, in rcu_cpu_starting(). A spinlock
> around that, an atomic_t to let the APs do their TSC sync one at a time
> (both in the above tree now), and I have a 75% saving on CPU bringup
> time for
On Tue, 2021-02-16 at 13:53 +, David Woodhouse wrote:
> I threw it into my tree at
> https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/parallel
>
> It seems to work fairly nicely. The parallel SIPI seems to win be about
> a third of the bringup time on my 28
On Fri, 2021-02-12 at 18:30 +0100, Thomas Gleixner wrote:
> On Fri, Feb 12 2021 at 01:29, Thomas Gleixner wrote:
> > On Thu, Feb 11 2021 at 22:58, David Woodhouse wrote:
> > I have no problem with making that jump based. It does not matter at
> > all. But you can't use the i
On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote:
> Don't bother mapping the Xen shinfo pages into the guest, they don't need
> to be accessed using the GVAs and passing a define with "GPA" in the name
> to addr_gva2hpa() is confusing.
>
> Cc: David Woodhou
> add test case")
> Cc: David Woodhouse
> Signed-off-by: Sean Christopherson
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote:
> Add the new Xen test binaries to KVM selftest's .gitnore.
>
> Signed-off-by: Sean Christopherson
> ---
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On 10 February 2021 07:45:54 GMT, Yang Song wrote:
>Use a customized signature service supported by openssl engine
>to sign the kernel module.
>Add command line parameters that support engine for sign-file
>to use the customized openssl engine service to sign kernel modules.
>
>Signed-off-by:
On Fri, 2021-02-05 at 14:36 +, Joao Martins wrote:
> On 2/4/21 8:18 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commit
> >
> > 79033bebf6fa ("KVM: x86/xen: Fix coexistence of Xen and Hyper-V
> > hypercalls")
> >
> > is missing a Signed-off-by from its author.
> >
>
> Except that
On Tue, 2020-12-15 at 16:42 +, Wei Liu wrote:
> On Tue, Dec 15, 2020 at 04:25:03PM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > On 03.12.20 00:22, Wei Liu wrote:
> >
> > Hi,
> >
> > > I don't follow. Do you mean reusing /dev/kvm but with a different set of
> > > APIs underneath? I
Utterly broken because the bringup uses global initial_stack and initial_gs
variables, and the TSC sync is similarly hosed (I should probably do one
at a time).
The bringup is going to be the most fun to fix, because the AP coming up
doesn't actually have a lot that it *can* use to disambiguate
splits those
phases out into separate functions so that future commits and make them
happen in parallel for all APs.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/smpboot.c | 136 +++---
1 file changed, 82 insertions(+), 54 deletions(-)
diff --git a/arch/x86
If the platform registers these states, bring all CPUs to each registered
state in parallel, before the final bringup to CPUHP_BRINGUP_CPU.
Signed-off-by: David Woodhouse
---
include/linux/cpuhotplug.h | 2 ++
kernel/cpu.c | 27 +--
2 files changed, 27
API.
Signed-off-by: David Woodhouse
---
include/linux/smpboot.h | 7 +++
kernel/smpboot.h| 2 --
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index 9d1bc65d226c..3862addcaa34 100644
--- a/include/linux/smpboot.h
+++ b
mplify cluster management")
Signed-off-by: David Woodhouse
---
arch/x86/kernel/apic/x2apic_cluster.c | 82 ---
1 file changed, 49 insertions(+), 33 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_cluster.c
b/arch/x86/kernel/apic/x2apic_cluster.c
index df6adc5674c9..
If we want to do parallel CPU bringup, we're going to need to set this up
and leave it until all CPUs are done. Might as well use the RTC spinlock
to protect the refcount, as we need to take it anyway.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/smpboot.c | 23 +++
1
nge.
So I'm relatively happy at least that far, as preparatory work...
David Woodhouse (6):
x86/apic/x2apic: Fix parallel handling of cluster_mask
cpu/hotplug: Add dynamic states before CPUHP_BRINGUP_CPU for parallel
bringup
x86/smpboot: Reference count on smpboot_setup_warm_re
From: David Woodhouse
For each CPU being brought up, the alloc_clustermask() function
allocates a new struct cluster_mask just in case it's needed. Then the
target CPU actually runs, and in init_x2apic_ldr() it either uses a
cluster_mask from a previous CPU in the same cluster, or consumes
On Thu, 2021-01-21 at 15:42 +, David Woodhouse wrote:
> [2.289283] BUG: kernel NULL pointer dereference, address:
> [2.289283] #PF: supervisor write access in kernel mode
> [2.289283] #PF: error_code(0x0002) - not-present page
> [2.289283]
On Thu, 2021-01-21 at 15:55 +0100, Thomas Gleixner wrote:
> > Testing on real hardware has been more interesting and less useful so
> > far. We started with the CPUHP_BRINGUP_KICK_CPU state being
> > *immediately* before CPUHP_BRINGUP_CPU. On my 28-thread Haswell box,
> > that didn't come up at
On Tue, 2020-12-15 at 22:20 +0100, Thomas Gleixner wrote:
> Since the rewrite of the CPU hotplug infrastructure to a state machine
> it's pretty obvious that the bringup of APs can changed from the fully
> serialized:
>
> for_each_present_cpu(cpu) {
> if (!cpu_online(cpu))
>
On Wed, 2020-12-16 at 16:31 +0100, Thomas Gleixner wrote:
> But obviously the C-state in which the APs are waiting is not really
> relevant, as you demonstrated that the cost is due to INIT/SIPI even
> with spinwait, which is what I suspected.
>
> OTOH, the advantage of INIT/SIPI is that the AP
On Tue, 2021-01-05 at 16:40 +0100, Christian König wrote:
> Am 05.01.21 um 13:20 schrieb Huang Rui:
> > On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote:
> > > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote:
> > > > Ah, this asic is a bit old and still use radeon driver.
On Tue, 2021-01-05 at 12:11 +, Joao Martins wrote:
> On 1/1/21 2:33 PM, David Woodhouse wrote:
> > What it does actually mean in the short term is that as I update your
> > KVM_IRQ_ROUTING_XEN_EVTCHN support, I probably *won't* bother to add a
> > 'prio
From: David Woodhouse
The AMD IOMMU initialisation registers the IRQ remapping domain for
each IOMMU before doing the final sanity check that every I/OAPIC is
covered.
This means that the AMD irq_remapping_select() function gets invoked
even when IRQ remapping has been disabled, eventually
From: David Woodhouse
When I made the INTCAPXT support stop gratuitously pretending to be MSI,
I missed the fact that iommu_setup_msi() also sets the ->int_enabled
flag. I missed this in the iommu_setup_intcapxt() code path, which means
that a resume from suspend will try to allocate the
On Tue, 2021-01-05 at 00:05 +0100, Johnathan Smithinovic wrote:
> commit f36a74b9345a leads to not booting system with AMD 2990WX
>
>
> When trying to boot 5.11-rc2 as usual the messages of the bootloader stay on
> my
> screen and not much appears to happen (fans run a bit slower than in GRUB,
On Tue, 2021-01-05 at 00:23 +0100, Borislav Petkov wrote:
> On Mon, Jan 04, 2021 at 02:22:50PM +0100, Borislav Petkov wrote:
> > Hi folks,
> >
> > syscore_resume() doesn't like when the AMD iommu driver enables
> > interrupts in its ->resume hook when I resume the box from suspend to
> > RAM.
> >
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
> > But if the kernel is going to short-circuit the IPIs and VIRQs, then
> > it's already going to have to handle the evtchn_pending/evtchn_mask
> > bitmaps, and actually injecting interrupts.
> >
>
> Right. I was trying to point that out in
On Tue, 2020-12-22 at 13:06 +0800, kernel test robot wrote:
>
> kern :warn : [ 86.138096] WARNING: suspicious RCU usage
> kern :warn : [ 86.142286] 5.10.0-rc5-gfdd90b978b4e #1 Tainted: G
> I
> kern :warn : [ 86.148879] -
> kern :warn : [
On Tue, 2020-12-01 at 16:40 -0800, Ankur Arora wrote:
> > How come we get to pin the page and directly dereference it every time,
> > while kvm_setup_pvclock_page() has to use kvm_write_guest_cached()
> > instead?
>
> So looking at my WIP trees from the time, this is something that
> we went back
On Thu, 2020-12-10 at 12:57 -0600, Bjorn Helgaas wrote:
> What is the point of a function called probably_on_bare_metal()?
> *Probably*? The caller can't really do anything with the fact that
> we're not 100% sure this gives the correct answer. Just call it
> "on_bare_metal()" or something and
On Thu, 2020-12-10 at 08:46 +0800, Lu Baolu wrote:
> +/*
> + * We want to figure out which context we are running in. But the hardware
> + * does not introduce a reliable way (instruction, CPUID leaf, MSR, whatever)
> + * which can be manipulated by the VMM to let the OS figure out where it
>
On 9 December 2020 13:26:55 GMT, Joao Martins wrote:
>On 12/9/20 11:39 AM, David Woodhouse wrote:
>> On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote:
>>> Isn't this what the first half of this patch was doing initially
>(minus the
>>> irq routing) ? Looks
On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote:
> Isn't this what the first half of this patch was doing initially (minus the
> irq routing) ? Looks really similar:
>
> https://lore.kernel.org/kvm/20190220201609.28290-11-joao.m.mart...@oracle.com/
Absolutely! This thread is in reply to
On Tue, 2020-12-08 at 22:35 -0800, Ankur Arora wrote:
> > It looks like Linux doesn't use the per-vCPU upcall vector that you
> > called 'KVM_XEN_CALLBACK_VIA_EVTCHN'. So I'm delivering interrupts via
> > KVM_INTERRUPT as if they were ExtINT
> >
> > ... except I'm not. Because the kernel
On Wed, 2020-12-02 at 19:02 +, David Woodhouse wrote:
>
> > I feel we could just accommodate it as subtype in
> > KVM_XEN_ATTR_TYPE_CALLBACK_VIA.
> > Don't see the adavantage in having another xen attr type.
>
> Yeah, fair enough.
>
> > But kinda
On Wed, 2020-12-02 at 12:32 -0800, Ankur Arora wrote:
> > On IRC, Paolo told me that permanent pinning causes problems for memory
> > hotplug, and pointed me at the trick we do with an MMU notifier and
> > kvm_vcpu_reload_apic_access_page().
>
> Okay that answers my question. Thanks for clearing
On Wed, 2020-12-02 at 20:12 +, Joao Martins wrote:
> > I'll do some more experiments and
> > see what I can get working, and what it looks like.
> >
> > I'm focusing on making the shinfo stuff all use kvm_map_gfn() first.
> >
>
> I was chatting with Ankur, and we can't fully 100% remember
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
> On 12/2/20 4:47 PM, David Woodhouse wrote:
> > On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
> > > On 12/2/20 11:17 AM, David Woodhouse wrote:
> > > > I might be more inclined to go for a
On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
> On 12/2/20 11:17 AM, David Woodhouse wrote:
> > I might be more inclined to go for a model where the kernel handles the
> > evtchn_pending/evtchn_mask for us. What would go into the irq routing
> > table is { vcpu, por
On Wed, 2020-12-02 at 10:44 +, Joao Martins wrote:
> [late response - was on holiday yesterday]
>
> On 12/2/20 12:40 AM, Ankur Arora wrote:
> > On 2020-12-01 5:07 a.m., David Woodhouse wrote:
> > > On Wed, 2019-02-20 at 20:15 +, Joao Martins wr
On Wed, 2020-12-02 at 11:17 +, Joao Martins wrote:
> Xen viridian mode is indeed one thing that needed fixing. And definitely a
> separate patch as you do here. Both this one and the previous is looking good.
>
> I suppose that because you switch to kvm_vcpu_write_guest() you no longer need
>
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
> @@ -176,6 +177,9 @@ int kvm_arch_set_irq_inatomic(struct
> kvm_kernel_irq_routing_entry *e,
> int r;
>
> switch (e->type) {
> + case KVM_IRQ_ROUTING_XEN_EVTCHN:
> + return kvm_xen_set_evtchn(e, kvm,
On Tue, 2020-12-01 at 21:19 -0800, Ankur Arora wrote:
> > + for (i = 0; i < PAGE_SIZE / sizeof(instructions); i++) {
> > + *(u32 *)[1] = i;
> > + if (kvm_vcpu_write_guest(vcpu,
> > + page_addr + (i *
On Tue, 2020-12-01 at 16:40 -0800, Ankur Arora wrote:
> On 2020-12-01 5:07 a.m., David Woodhouse wrote:
> > On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
> > > +static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
> > > +{
> > > +
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
> +static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
> +{
> + struct shared_info *shared_info;
> + struct page *page;
> +
> + page = gfn_to_page(kvm, gfn);
> + if (is_error_page(page))
> +
On Tue, 2020-12-01 at 09:48 +, David Woodhouse wrote:
> So I switched it to generate the hypercall page directly from the
> kernel, just like we do for the Hyper-V hypercall page.
Speaking of Hyper-V... I'll post this one now so you can start heckling
it.
I won't post the rest a
bly header")
>
> Since commit 0bddd227f3dc ("Documentation: update for gcc 4.9
> requirement") the minimum supported version of GCC is gcc-4.9. It's now
> safe to remove this code.
>
> Signed-off-by: Nick Desaulniers
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
CALL flag in the
KVM_XEN_HVM_CONFIG ioctl structure, and advertised by the same flag
being returned from the KVM_CAP_XEN_HVM check.
Add a test case and shift xen_hvm_config() to the nascent xen.c while
we're at it.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/k
On Mon, 2020-11-30 at 18:41 +, Joao Martins wrote:
> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> {
> ...
> if (kvm_hv_hypercall_enabled(vcpu->kvm))
> return kvm_hv_hypercall(...);
>
> if (kvm_xen_hypercall_enabled(vcpu->kvm))
> return
On Mon, 2020-11-30 at 17:15 +, Joao Martins wrote:
> On 11/30/20 4:48 PM, David Woodhouse wrote:
> > On Mon, 2020-11-30 at 15:08 +, Joao Martins wrote:
> > > On 11/30/20 12:55 PM, David Woodhouse wrote:
> > > > On Mon, 2020-11-30 at 12:17 +, Joao Martins
On Mon, 2020-11-30 at 15:08 +, Joao Martins wrote:
> On 11/30/20 12:55 PM, David Woodhouse wrote:
> > On Mon, 2020-11-30 at 12:17 +, Joao Martins wrote:
> > > On 11/30/20 9:41 AM, David Woodhouse wrote:
> > > > On Wed, 2019-02-20 at 20:15 +, Joao Martins w
On Mon, 2020-11-30 at 12:17 +, Joao Martins wrote:
> On 11/30/20 9:41 AM, David Woodhouse wrote:
> > On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
> > > userspace registers a @port to an @eventfd, that is bound to a
> > > @vcpu. This information is th
On Mon, 2020-11-30 at 12:03 +0100, Paolo Bonzini wrote:
> You can use CPUID too (search for Hv#1 in leaf 0x4000)?
That's leaf 0x4001. Which is also the leaf used for Xen to indicate
the Xen version. So as long as we don't pretend to be Xen version
12759.30280 I suppose that's OK.
Or we
config.msr == HV_X64_MSR_GUEST_OS_ID. But that's
basically what Joao's patch already does. It doesn't disable the
*other* Hyper-V MSRs except for the one Xen 'conflicts' with, but I
don't think that matters.
The patch stands alone to correct the *existing* functionality of
KVM_XEN_HVM_CONFIG,
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
> userspace registers a @port to an @eventfd, that is bound to a
> @vcpu. This information is then used when the guest does an
> EVTCHNOP_send with a port registered with the kernel.
Why do I want this part?
> EVTCHNOP_send short-circuiting
exception of the stray apostrophe
already noted, both:
Reviewed-by: David Woodhouse
Tested-by: David Woodhouse
There is a slight caveat that I think we're accepting ExtINT from
userspace PIC sooner than we should, and queuing it up for delivery in
the kernel.
Whereas real hardware might not issue the I
On Fri, 2020-11-27 at 06:21 -0500, Paolo Bonzini wrote:
> +* FIXME: interrupt.injected represents an interrupt that it's
You can drop the stray apostrophe from that "its" while you're moving
it...
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2020-11-24 at 17:07 +, Wei Liu wrote:
> We will soon use the same structure to handle IO-APIC interrupts as
> well. Introduce an enum to identify the source and a data structure for
> IO-APIC RTE.
>
> While at it, update pci-hyperv.c to use the enum.
>
> No functional change.
>
>
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: d1adcfbb520c43c10fc22fcdccdd4204e014fb53
Gitweb:
https://git.kernel.org/tip/d1adcfbb520c43c10fc22fcdccdd4204e014fb53
Author:David Woodhouse
AuthorDate:Wed, 11 Nov 2020 12:09:01
Committer
On Wed, 2020-11-18 at 23:51 +0700, Suravee Suthikulpanit wrote:
> Yes, this fixes the issue. Now I can receive the IOMMU event log
> interrupts for IO_PAGE_FAULT event, which is triggered
> using the injection interface via debugfs.
Thanks, Suravee.
smime.p7s
Description: S/MIME cryptographic
On Wed, 2020-11-18 at 17:29 +0700, Suravee Suthikulpanit wrote:
> I might need your help debugging this issue. I'm seeing the following error:
>
> [ 14.005937] irq 29, desc: d200500b, depth: 0, count: 0, unhandled: > 0
> [ 14.006234] ->handle_irq(): eab4b6eb,
On Tue, 2020-11-17 at 10:53 +0100, Thomas Gleixner wrote:
> But that does not solve the problem either simply because then the IOMMU
> will catch the rogue MSIs and you get an interrupt storm on the IOMMU
> error interrupt.
Not if you can tell the IOMMU to stop reporting those errors.
We can
On Fri, 2020-11-13 at 15:14 +, David Woodhouse wrote:
> On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
> > I had trouble cloning your tree for some reason, so just took the top
> > three patches and applied them to the tip tree. This all appears to be
> > workin
ee Thomas has taken the first two into the tip.git x86/apic
branch already, so we're just looking for an ack on the third. Which is
this one...
From 49ee4fa51b8c06d14b7c4c74d15a7d76f865a8ea Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Wed, 11 Nov 2020 12:09:01 +
Subject: [PATCH] iommu
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 2fb6acf3edfeb904505f9ba3fd01166866062591
Gitweb:
https://git.kernel.org/tip/2fb6acf3edfeb904505f9ba3fd01166866062591
Author:David Woodhouse
AuthorDate:Wed, 11 Nov 2020 14:43:21
Committer
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 2df985f5e44c43f5d29d8cc3aaa8e8ac697e9de6
Gitweb:
https://git.kernel.org/tip/2df985f5e44c43f5d29d8cc3aaa8e8ac697e9de6
Author:David Woodhouse
AuthorDate:Wed, 11 Nov 2020 14:43:20
Committer
On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
> On 11/11/20 6:32 AM, David Woodhouse wrote:
> > On Wed, 2020-11-11 at 10:36 +0000, David Woodhouse wrote:
> > > On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
> > > > Looking at it now with brain aw
From: David Woodhouse
The AMD IOMMU has two modes for generating its own interrupts.
The first is very much based on PCI MSI, and can be configured by Linux
precisely that way. But like legacy unmapped PCI MSI it's limited to
8 bits of APIC ID.
The second method does not use PCI MSI at all
From: David Woodhouse
All the bitfields in here are overlaid on top of each other since
they're a union. Change the second u64 to be in a struct so it does
the intended thing.
Fixes: b5c3786ee3704 ("iommu/amd: Use msi_msg shadow structs")
Signed-off-by: David Woodhouse
---
drivers
From: David Woodhouse
This was potentially allowing I/OAPIC and MSI interrupts to be parented
in the IOMMU IR domain even when IR was disabled. Don't do that.
Signed-off-by: David Woodhouse
---
drivers/iommu/amd/init.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
On Wed, 2020-11-11 at 10:36 +, David Woodhouse wrote:
> On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
> > Looking at it now with brain awake, the XTSUP stuff is pretty much
> > the same as DMAR, which I didn't realize yesterday. The affinity
> > notifier muck
On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
> Looking at it now with brain awake, the XTSUP stuff is pretty much
> the same as DMAR, which I didn't realize yesterday. The affinity
> notifier muck is not needed when we have a write_msg() function which
> twiddles the bits into those
On Tue, 2020-11-10 at 23:48 +0100, Thomas Gleixner wrote:
> + * IRQCHIP_MSI_EXTID The MSI message created for this chip
> can
> + * have an otherwise forbidden extended ID
If we're going to do that then we could ditch the separate
On 10 November 2020 21:01:17 GMT, Thomas Gleixner wrote:
>On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
>
>> On 10 November 2020 18:56:17 GMT, Thomas Gleixner
> wrote:
>>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>>>> On Tue, Nov 10
On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote:
>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>>> enabled, I'd have a go at
On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote:
> Yep. The warning started triggering with:
> 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit")
>
> Here's the backtrace:
>
> [ 15.611109] [ cut here ]
> [ 15.616274] WARNING: CPU: 184 PID:
On Tue, 2020-11-10 at 16:54 +0100, Thomas Gleixner wrote:
> On Tue, Nov 10 2020 at 08:55, Tom Lendacky wrote:
> > On 11/10/20 8:34 AM, Thomas Gleixner wrote:
> > I was about to send the dmesg output when I saw this. A quick test
> > with
> > this change resolves the boot issue, thanks!
>
> /me
> Hi David
>
> I did't follow the support for 32768 CPUs in guest without IR support.
>
> Can you tell me how that is done?
Using bits 11-5 of the MSI address bits (the other 7 bits of "Extended
Destination ID" that aren't the Remappable Format indicator).
And physical addressing mode,
On Tue, 2020-11-10 at 01:31 -0500, Qian Cai wrote:
> On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote:
> > From: Thomas Gleixner
> >
> > 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
> > the trigger type (edge/level) and the ac
On Mon, 2020-11-09 at 17:15 -0600, Tom Lendacky wrote:
> On 10/29/20 7:15 AM, tip-bot2 for Thomas Gleixner wrote:
> > The following commit has been merged into the x86/apic branch of tip:
> >
> > Commit-ID: a27dca645d2c0f31abb7858aa0e10b2fa0f2f659
> > Gitweb:
> >
> On Fri, Nov 06 2020 at 09:14, Jason Gunthorpe wrote:
>> On Fri, Nov 06, 2020 at 09:48:34AM +, Tian, Kevin wrote:
>> For instance you could put a "disable IMS" flag in the ACPI tables, in
>> the config space of the emuulated root port, or any other areas that
>> clearly belong to the
On Sun, 2020-11-08 at 19:47 +0100, Thomas Gleixner wrote:
> This only works when the guest OS actually knows that it runs in a
> VM. If the guest can't figure that out, i.e. via CPUID, this cannot be
> solved because from the guest OS view that's the same as running on bare
> metal. Obviously on
On Sun, 2020-11-08 at 10:11 -0800, Raj, Ashok wrote:
> Hi Jason
>
> Thanks, its now clear what you had mentioned earlier.
>
> I had couple questions/clarifications below. Thanks for working
> through this.
>
> On Fri, Nov 06, 2020 at 08:12:07PM -0400, Jason Gunthorpe wrote:
> > On Fri, Nov 06,
On 6 November 2020 16:32:00 GMT, Alex Williamson
wrote:
>On Fri, 6 Nov 2020 11:17:21 +0100
>Paolo Bonzini wrote:
>
>> On 04/11/20 10:35, David Woodhouse wrote:
>> > On Wed, 2020-10-28 at 15:35 +0100, Peter Zijlstra wrote:
>> >> On Tue, Oct 27, 2020
1 - 100 of 4023 matches
Mail list logo
