Xen devel - May 2006 - [PATCH] Multiple HVM time device model support in HV

This patch targets to support multiple HVM time device models coming
soon.
	1: Adopt an abstract layer for periodic time on top of different
HV time device models like PIT, RTC and ACPI time.
	2: Extract VMM knowledge from PIT DM code and keep close with
qemu for easy maintain in future.
	3: Use guest time (TSC) to drive PIT CLK that helps us to remove
a lot of extra logic previously introduced to convert from host time to
guest time.
	4: Some cleanup for SMP code like move cache_tsc_offset to per
VP.

Signed-off-by: Eddie Dong <eddie.dong@intel.com>


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

On 25 May 2006, at 03:51, Dong, Eddie wrote:
> This patch targets to support multiple HVM time device models coming
> soon.
> 	1: Adopt an abstract layer for periodic time on top of different
> HV time device models like PIT, RTC and ACPI time.
> 	2: Extract VMM knowledge from PIT DM code and keep close with
> qemu for easy maintain in future.
> 	3: Use guest time (TSC) to drive PIT CLK that helps us to remove
> a lot of extra logic previously introduced to convert from host time to
> guest time.
> 	4: Some cleanup for SMP code like move cache_tsc_offset to per
> VP.
This patch is very large. Most of it seems to deal with this new 
abstraction of ''periodic time''. What does that mean, and why
is it
useful?

  -- Keir


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

Keir:
	This patch is what I want to replace original 9672 patch. 
	Before 9672, actually we have an periodic time in hypervisor
although the PIT is in Qemu, but 9672 removed this periodic time and
embedded it into PIT code for some reason. After this new patch, if you
compare Qemu i8254.c with xen i8254.c, the diff is very small and very
simple (only some VMM related new APIs). Here it is for the i8254.c
diff, and we will be very easy to update to latest Qemu.
	Now we are thinking to put RTC and ACPI time into xen, they both
may generate periodic time IRQ. With the new patch, RTC & ACPI time only
need to create an instance of periodic time. The device model of RTC and
ACPI itself will be very clean. Otherwise, same code needs to be
embedded into both RTC and ACPI device model (i.e. handle timer IRQ in
device model). That makes future maintain difficult. Further more, any
time virtualization policy change needs to modify all time devices in
HV.
	1/3 of i8254.c changes is due to new PIT CLK driving mechanism
(use guest TSC instead of host NOW() ). In this way, original change in
I8254.c is no longer needed, and thus removed.
	1/6 of the patch is due to cache_tsc_offset move to per VP basis
:-)
Eddie



Keir Fraser wrote:
> On 25 May 2006, at 03:51, Dong, Eddie wrote:
> 
>> This patch targets to support multiple HVM time device models coming
>> 	soon. 1: Adopt an abstract layer for periodic time on top of
>> different 
>> HV time device models like PIT, RTC and ACPI time.
>> 	2: Extract VMM knowledge from PIT DM code and keep close with
>> qemu for easy maintain in future.
>> 	3: Use guest time (TSC) to drive PIT CLK that helps us to remove
>> a lot of extra logic previously introduced to convert from host time
>> 	to guest time. 4: Some cleanup for SMP code like move
>> cache_tsc_offset to per 
>> VP.
> 
> This patch is very large. Most of it seems to deal with this new
> abstraction of ''periodic time''. What does that mean, and
why is it
> useful?
> 
>   -- Keir


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