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
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: f36a74b9345aebaf5d325380df87a54720229d18
Gitweb:
https://git.kernel.org/tip/f36a74b9345aebaf5d325380df87a54720229d18
Author:David Woodhouse
AuthorDate:Tue, 03 Nov 2020 16:36:22
Committer
On Wed, 2020-10-28 at 15:35 +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2020 at 02:39:43PM +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > This allows an exclusive wait_queue_entry to be added at the head of the
> > queue, instead of the ta
From: David Woodhouse
In commit b643128b917 ("x86/ioapic: Use irq_find_matching_fwspec() to
find remapping irqdomain") the I/OAPIC code was changed to find its
parent irqdomain using irq_find_matching_fwspec(), but the key used
for the lookup was wrong. It shouldn't use 'ioa
255 APIC ID.
>
> The kdump issue can be fixed by the Extended Dest ID, which is introduced
> recently by David Woodhouse (for IOAPIC, see the field virt_destid_8_14 in
> struct IO_APIC_route_entry). Of course, the Extended Dest ID needs the
> support of the underlying hypervisor. The
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 2e008ffe426f927b1697adb4ed10c1e419927ae4
Gitweb:
https://git.kernel.org/tip/2e008ffe426f927b1697adb4ed10c1e419927ae4
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:35 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: a87fb465ffe8eacd0d69032da33455e4f6fd8b41
Gitweb:
https://git.kernel.org/tip/a87fb465ffe8eacd0d69032da33455e4f6fd8b41
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:25 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: bf27ef8a77d8da38c9f35f8f6aab013a2dcf175f
Gitweb:
https://git.kernel.org/tip/bf27ef8a77d8da38c9f35f8f6aab013a2dcf175f
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:33 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 5d5a97133887b2dfd8e2ad0347c3a02cc7aaa0cb
Gitweb:
https://git.kernel.org/tip/5d5a97133887b2dfd8e2ad0347c3a02cc7aaa0cb
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:21 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: a1a785b572425ab3ca5494a4be02ab59a796df51
Gitweb:
https://git.kernel.org/tip/a1a785b572425ab3ca5494a4be02ab59a796df51
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:24 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 51130d21881d435fad5fa7f25bea77aa0ffc9a4e
Gitweb:
https://git.kernel.org/tip/51130d21881d435fad5fa7f25bea77aa0ffc9a4e
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:31 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: b643128b917ca8f1c8b1e14af64ebdc81147b2d1
Gitweb:
https://git.kernel.org/tip/b643128b917ca8f1c8b1e14af64ebdc81147b2d1
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:28 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 6452ea2a323b80868ce5e6d3030e4ccbeab9dc30
Gitweb:
https://git.kernel.org/tip/6452ea2a323b80868ce5e6d3030e4ccbeab9dc30
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:23 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 2cbd5a45e5296b28d64224ffbbd33d427704ba1b
Gitweb:
https://git.kernel.org/tip/2cbd5a45e5296b28d64224ffbbd33d427704ba1b
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:22 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 5a169bf04cd2bfdbac967d12eb5b70915b29d7ee
Gitweb:
https://git.kernel.org/tip/5a169bf04cd2bfdbac967d12eb5b70915b29d7ee
Author:David Woodhouse
AuthorDate:Mon, 19 Oct 2020 15:55:56 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 3d7295eb3003aea9f89de35304b3a88ae4d5036b
Gitweb:
https://git.kernel.org/tip/3d7295eb3003aea9f89de35304b3a88ae4d5036b
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:10 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: f598181acfb36f67e1de138cbe80a7db497f7d8c
Gitweb:
https://git.kernel.org/tip/f598181acfb36f67e1de138cbe80a7db497f7d8c
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:09 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 47bea873cf809f490cfac0c4e88533fd7fed6064
Gitweb:
https://git.kernel.org/tip/47bea873cf809f490cfac0c4e88533fd7fed6064
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:02 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 26573a97746c7a99f394f9d398ce91a8853b3b89
Gitweb:
https://git.kernel.org/tip/26573a97746c7a99f394f9d398ce91a8853b3b89
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:01 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: c2a5881c28e5bb4cb901029423a1c7068c0afa2d
Gitweb:
https://git.kernel.org/tip/c2a5881c28e5bb4cb901029423a1c7068c0afa2d
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:27 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: ab0f59c6f135289c7ea90b0e2471674bf289d884
Gitweb:
https://git.kernel.org/tip/ab0f59c6f135289c7ea90b0e2471674bf289d884
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:32 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: a491bb19f728cdb8cc1f4734ecc57c0afa099fac
Gitweb:
https://git.kernel.org/tip/a491bb19f728cdb8cc1f4734ecc57c0afa099fac
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:26 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 79eb3581bcaae9b5677629d945e14da212aa76e2
Gitweb:
https://git.kernel.org/tip/79eb3581bcaae9b5677629d945e14da212aa76e2
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:30 +01:00
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: ed381fca47122f0787ee53b97e5f9d562eec7237
Gitweb:
https://git.kernel.org/tip/ed381fca47122f0787ee53b97e5f9d562eec7237
Author:David Woodhouse
AuthorDate:Sat, 24 Oct 2020 22:35:29 +01:00
On Tue, 2020-10-27 at 21:30 +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2020 at 07:27:59PM +0000, David Woodhouse wrote:
>
> > > While looking at this I found that weird __add_wait_queue_exclusive()
> > > which is used by fs/eventpoll.c and does something similar, exce
On Tue, 2020-10-27 at 21:30 +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2020 at 07:27:59PM +0000, David Woodhouse wrote:
>
> > > While looking at this I found that weird __add_wait_queue_exclusive()
> > > which is used by fs/eventpoll.c and does something similar, exce
On Tue, 2020-10-27 at 20:09 +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2020 at 02:39:43PM +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > This allows an exclusive wait_queue_entry to be added at the head of the
> > queue, instead of the ta
From: David Woodhouse
This allows an exclusive wait_queue_entry to be added at the head of the
queue, instead of the tail as normal. Thus, it gets to consume events
first without allowing non-exclusive waiters to be woken at all.
The (first) intended use is for KVM IRQFD, which currently has
From: David Woodhouse
When posted interrupts are available, the IRTE is modified to deliver
interrupts direclty to the vCPU and nothing ever reaches userspace, if
it's listening on the same eventfd that feeds the irqfd.
I like that behaviour. Let's do it all the time, even without posted
consume the eventfd counter too.
David Woodhouse (2):
sched/wait: Add add_wait_queue_priority()
kvm/eventfd: Use priority waitqueue to catch events before userspace
include/linux/wait.h | 12 +++-
kernel/sched/wait.c | 17 -
virt/kvm/eventfd.c | 6 --
it as they
handle their respective events.
David Woodhouse (3):
eventfd: Export eventfd_ctx_do_read()
vfio/virqfd: Drain events from eventfd in virqfd_wakeup()
kvm/eventfd: Drain events from eventfd in irqfd_wakeup()
drivers/vfio/virqfd.c | 3 +++
fs/eventfd.c| 5 -
include
From: David Woodhouse
Don't allow the events to accumulate in the eventfd counter, drain them
as they are handled.
Signed-off-by: David Woodhouse
---
drivers/vfio/virqfd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vfio/virqfd.c b/drivers/vfio/virqfd.c
index 997cb5d0a657
From: David Woodhouse
Where events are consumed in the kernel, for example by KVM's
irqfd_wakeup() and VFIO's virqfd_wakeup(), they currently lack a
mechanism to drain the eventfd's counter.
Since the wait queue is already locked while the wakeup functions are
invoked, all they really need
From: David Woodhouse
Don't allow the events to accumulate in the eventfd counter, drain them
as they are handled.
Signed-off-by: David Woodhouse
---
virt/kvm/eventfd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index d6408bb497dc
On Tue, 2020-10-27 at 09:01 +0100, Paolo Bonzini wrote:
> On 26/10/20 18:53, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > As far as I can tell, when we use posted interrupts we silently cut off
> > the events from userspace, if it's listening on the
From: David Woodhouse
As far as I can tell, when we use posted interrupts we silently cut off
the events from userspace, if it's listening on the same eventfd that
feeds the irqfd.
I like that behaviour. Let's do it all the time, even without posted
interrupts. It makes it much easier to handle
1 - 100 of 4003 matches
Mail list logo
