qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RESEND PATCH v8 1/4] apic: map APIC's MMIO region at e


From: Igor Mammedov
Subject: Re: [Qemu-devel] [RESEND PATCH v8 1/4] apic: map APIC's MMIO region at each CPU's address space
Date: Fri, 26 Jun 2015 11:01:36 +0200

On Thu, 25 Jun 2015 19:27:47 +0200
Paolo Bonzini <address@hidden> wrote:

> 
> 
> On 25/06/2015 19:08, Andreas Färber wrote:
> > > I said "I think this patch is incorrect, because you do not install a
> > > separate address space for each CPU.  Also, the CPU address space is
> > > only used with TCG so it should be guarded by "if (tcg_enabled())"."
> > > 
> > > By the way, now TCG _is_ installing a separate address space per CPU
> > > already, so the patch can simply guard the code with "if (tcg_enabled())".
> > 
> > Is the APIC MemoryRegion not used by KVM?
> 
> It's used if the userspace LAPIC is.  It's not used together with the
> kernel LAPIC (accesses really are trapped by the kernel).
Isn't this memory region still handle MSI MMIO in case of kernel LAPIC?
kvm_apic_mem_write() -> kvm_irqchip_send_msi()

> 
> > Otherwise if we still need the
> > ugly code path for KVM, that's not much of an improvement here.
> > 
> > And is installing a separate address space per CPU for KVM difficult due
> > to kernel limitations, or is this just a few lines of QEMU code that Zhu
> > or someone would need to write? :)
> 
> It's basically impossible.  Even though support for multiple address
> spaces is going to be in Linux 4.2, there are going to be just two: SMM
> and not SMM.  You don't really want to do O(#cpus) stuff in KVM, where
> the number of CPUs can be 200 or more.
> 
> TCG is okay because the #cpus is not really going to be more than 4-ish.
> 
> Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]