Re: [Qemu-devel] Ideas wiki for GSoC 2010

[Avi Kivity <avi@redhat.com>]

On 03/16/2010 03:21 AM, Anthony Liguori wrote:
> On 03/15/2010 10:06 AM, Avi Kivity wrote:
>> On 03/15/2010 03:23 PM, Anthony Liguori wrote:
>>> On 03/15/2010 08:11 AM, Avi Kivity wrote:
>>>> On 03/15/2010 03:03 PM, Joerg Roedel wrote:
>>>>>
>>>>>>> I will add another project - iommu emulation.  Could be very useful
>>>>>>> for doing device assignment to nested guests, which could make
>>>>>>> testing a lot easier.
>>>>>> Our experiments show that nested device assignment is pretty much
>>>>>> required for I/O performance in nested scenarios.
>>>>> Really? I did a small test with virtio-blk in a nested guest (disk 
>>>>> read
>>>>> with dd, so not a real benchmark) and got a reasonable 
>>>>> read-performance
>>>>> of around 25MB/s from the disk in the l2-guest.
>>>>>
>>>>
>>>> Your guest wasn't doing a zillion VMREADs and VMWRITEs every exit.
>>>>
>>>> I plan to reduce VMREAD/VMWRITE overhead for kvm, but not much we 
>>>> can do for other guests.
>>>
>>> VMREAD/VMWRITEs are generally optimized by hypervisors as they tend 
>>> to be costly.  KVM is a bit unusual in terms of how many times the 
>>> instructions are executed per exit.
>>
>> Do you know offhand of any unnecessary read/writes?  There's 
>> update_cr8_intercept(), but on normal exits, I don't see what else we 
>> can remove.
>
> Yeah, there are a number of examples.
>
> vmcs_clear_bits() and vmcs_set_bits() read a field of the VMCS and 
> then immediately writes it.  This is unnecessary as the same 
> information could be kept in a shadow variable.  In vmx_fpu_activate, 
> we call vmcs_clear_bits() followed immediately by vmcs_set_bits(). 
> which means we're reading GUEST_CR0 twice and writing it twice.

This should be much better these days (2.6.34-rc1) as vmx_fpu_activate() 
is called at most once per heavyweight exit (and I have evil plans to 
reduce it even further).  Still, that code should be optimized.

> vmx_get_rflags() reads from the VMCS and we frequently call 
> get_rflags() followed by a set_rflags() to update a bit.  We also 
> don't cache the value between calls and there's a few spots in the 
> code that make multiple calls.

We definitely should cache that (and segment access from the emulator as 
well).  But I'd have thought this to be relatively infrequent.  At least 
with Linux, using x2apic and virtio allows you to eliminate most 
emulator access, if you have npt or ept.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.