On Sat, Sep 20, 2008 at 11:38:22AM -0700, Avi Kivity wrote:
> Glauber Costa wrote:
>> By analysing phys_offset, we know whether a region is an mmio region
>> or not. If it is, register it as so. We don't reuse the same slot
>> infrastructure already existant, because there is a relationship between
>> the slot number for kvm the kernel module, and the index in the slots vector
>> for libkvm. However, we can do best in the future and use only a single data
>> structure
>> for both.
>>
>>
>
> Why is kvm interested in emulated mmio regions, at all?
We don't need to. If the region is an mmio region, we do nothing (well, later
on, I'm
coalescing the accesses). But still, we need to keep track. Otherwise, qemu can
(and it will)
try to register subsets of that memory, but without any indication that this is
part of an mmio region
Our algorithm will fail in this case, since we will then register a memory area
we should have left blank.
So think of mmio in this case as a "please leave it blank".
>
>
>> @@ -1032,11 +1042,9 @@ void kvm_mutex_lock(void)
>> int qemu_kvm_register_coalesced_mmio(target_phys_addr_t addr,
>> unsigned int size)
>> {
>> - return kvm_register_coalesced_mmio(kvm_context, addr, size);
>> }
>> int qemu_kvm_unregister_coalesced_mmio(target_phys_addr_t addr,
>> unsigned int size)
>> {
>> - return kvm_unregister_coalesced_mmio(kvm_context, addr, size);
>> }
>>
>
> Why?
Because I'm doing automatic mmio coalescing in memory registration. It's the
way I saw to remove
all the calls spread through the code, for merging purposes. Any better idea?
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
