[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Memory API
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [RFC] Memory API |
Date: |
Wed, 18 May 2011 22:11:10 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-05-18 22:02, Alex Williamson wrote:
> On Wed, 2011-05-18 at 14:34 -0500, 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.
>>
>>> - if the range was addressed by a device (PCI or other system bus
>>> devices) => forward to MSI or other MMIO handlers
>>
>> The same is true for MSI. Other MMIO handlers can be handled as
>> appropriate. For instance, once an I/O is sent to the PCI bus, you can
>> walk each PCI device's BAR list to figure out which device owns the I/O
>> event.
>>
>> For ISA, it's a little trickier since ISA doesn't do positive decoding.
>> You need each ISA device to declare what I/O addresses it handles.
>
> Do we only need to handle CPU based I/O with this API? I would think we
> would be layering memory regions and implementing them as a hierarchy
> that reflects the actual hardware layout we're emulating. An access
> from an I/O device may get a different translation to memory than a CPU
> (IOMMU). We also might have a system with two VGA devices that both
> register 0xa0000 with a switch in the chipset that decides which one
> sees the accesses, just as real hardware does. ISTR a presentation at
> one of the first KVM forums from you that talked about this type of
> model. Thanks,
IIUC, that switch is present in every PCI bridge. It can forward legacy
VGA I/O request to its devices or ignore them.
Jan
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Peter Maydell, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Alex Williamson, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API,
Jan Kiszka <=
- Re: [Qemu-devel] [RFC] Memory API, Alex Williamson, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19