qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Memory API


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Wed, 18 May 2011 15:41:09 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 05/18/2011 03:07 PM, Jan Kiszka wrote:
On 2011-05-18 21:34, Anthony Liguori wrote:
On 05/18/2011 02:27 PM, Jan Kiszka wrote:
On 2011-05-18 21:10, Anthony Liguori wrote:
On 05/18/2011 10:30 AM, Jan Kiszka wrote:
You really don't need to register 90% of the time.  In the case of a PC
with i440fx, it's really quite simple:

if an I/O is to the APIC page,
     it's handled by the APIC

That's not that simple. We need to tell apart:
   - if a cpu issued the request, and which one =>   forward to APIC

Right, but what I'm saying is that this logic lives in
kvm-all.c:kvm_run():case EXIT_MMIO.

Obviously for TCG, it's a bit more complicated but this should be
handled way before there's any kind of general dispatch.

Hmm, checking again, I think the APIC should not show up here at all. We
really need to filter it out very early at CPU level, i.e. when creating
the iotlb (or when dispatching a KVM EXIT_MMIO). It's cpu local, nothing
the chipset will ever see.

I really wonder now why I dropped the idea of handling per-cpu regions
as a special case in tlb_set_page. It looks trivial, could even be done
with a linear per-cpu list before looking at any chipset mappings.

Yup, I agree this is the right way to do it.

Regards,

Anthony Liguori


Jan





reply via email to

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