Status

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

 



On 03.12.2009, at 00:50, Christoffer Dall wrote:

> 
> 
> On Wed, Dec 2, 2009 at 6:42 PM, Alexander Graf <agraf at suse.de> wrote:
> 
> On 03.12.2009, at 00:29, Christoffer Dall wrote:
> 
>> Hi there.
>> 
>> Additional help is always welcome. I am actually composing a status report as we speak and will probably make it available soon. Also, I want to send something out to the KVM list and will do so soon as well. Especially since the code base matured somewhat lately.
> 
> That's good news!
> 
>> I am still stuck on calibrate_delay() in the init process, but have tracked it down to being caused by QEMU not enabling timers. I have a suspicion that I'm forgetting an endianness conversion somewhere, but anyway hope to figure it out this week.
> 
> I don't see why you'd need to convert endianness. Isn't your host == guest?
> 
> Yes, host == guest, but the emulated device in QEMU might write with a different endianness. But anyway, I might completely off. 


Sounds like it. When host == guest there's just no endianness conversion.

> 
> What exactly doesn't get triggered? Does the MMIO to enable the timer in qemu arrive (kvm)? Or does the qemu timer not fire off (signals)?
> 
> The guest kernel driver writes to a register on the PIT, which enables the timer. In QEMU that basically schedules a ptimer, but I just figured that out on a plane back from London yesterday and was too tired to make sense of it:) 

So trace the write in qemu and see if it actually arrives. Then check if the timer works :-).

When you pass by Nuremberg by any chance - feel free to tell me and say hi.

> 
>> There's also a pending review for keeping cached shadow page tables around from Michael, and he's working on protecting the guest page tables as well.
> 
> The only thing I know about ARM and MMU is that every revision has a different one :-).
> 
> So do you have x86 style hierarchical fully fledged page tables or more the powerpc like light version of them?
> I don't know anything about the specific hardware aspects of x86, so I can't do a good comparison. But basically ARM uses 2 level page tables (although you can directly map 1MB of what they call a section from the L1 tables). The 2nd level tables can take many formats (even for every version of the MMU) and pages can be 64K, 4K or 1K and even mixed. Linux only uses 4K tables though. There are access-permission bits related to different domains on both the L1 and L2 page tables also.
> 
> One cool trick we could pull on PowerPC was that we can just look up the guest PTE on a fault and get notified (TLB removal of the page) when the PTE gets changed / removed.
> 
> We  are planning to do the same by write-protecting the guest page tables and catching data aborts.

Sounds all very close to x86.

So when you do a process switch, you completely switch page tables? Then the x86 SPT approach sounds like the natural fit (write protect page table, map on the fly).

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20091202/90983a6b/attachment.html


[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux