RE: [Xen-devel] [PATCh][VT] partial PIC to HV patch

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Keir Fraser wrote:
> On 22 Sep 2005, at 10:33, Dong, Eddie wrote:
> 
>> Keir:
>>      This is patch to move PIC mask/EOI access to HV for performance
>> and we saw about 5% performance increasement with this patch.
> 
> I'm not sure about this. I don't much like splitting the
> implementation of a device across both Xen and qemu -- I'd rather
> implement entirely within one or the other. Our eventual aim should
> be to move all non-Xen device models into the context of the vmx
> domain (running as a paravirt 'mini domain' in rings 1 to 3 of the
> root vmcs). This might reduce latency enough for most devices to
> avoid distasteful 'split' device-model implementations.

Yes agree, the eventual goal should move device model to mini-domain.

> 
> In the case of local APICs, I/O APICs and the legacy PIC I can accept
> that, even in the above model there will probably be a measurable
> performance improvement to implementing these devices within Xen. But

For PIC case, cpusoak saw 5% performance increasement on REL4U1.

> I think this should be done by moving their complete implementation
> into Xen and defining a clean interface to device models running in
> domain0 and/or rings 1-3. In the case of the PIC, this could be done
> by having a virtualised 'interrupt wire' for each device (e.g.,
> represent an 'interrupt edge' by a special call into Xen that runs
> the PIC device model).

Yes, moving entire PIC into HV is another good approach.

> 
> The other argument for putting the PIC and IO-APIC in Xen is that the
> PIT is already there, and having it call out into a non-Xen device
> model to send interrupts is rather gross.
> 

Understand, so you prefer to see entire PIC in HV at least for Xen3.0.
Right?
Or should we use this patch for now and do various performance tunning
in 
parallel?

>   -- Keir

Thanks,eddie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel