WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] SMP-g design notes

To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] SMP-g design notes
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 9 Mar 2006 08:59:39 +0800
Cc: jean-paul.pigache@xxxxxxxx
Delivery-date: Thu, 09 Mar 2006 01:01:28 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZCkzOVTIwVCDh7Q66NWjXM6Br7OAAe4u3A
Thread-topic: [Xen-ia64-devel] SMP-g design notes
>From: Tristan Gingold
>Sent: 2006年3月8日 17:34
>[Comments are welcome]
>
>SMP-guest (SMP-g) current design.
>
>Because it is design time, here are some note about my SMP-g work.
>The current patch is very small.  I tried only to bring-up SMP-g ASAP to catch
>more
>SMP bugs.  Also I tried to miminize Linux kernel changes.
>
>The only Linux kernel change is the way IPI are sent.  When running_on_xen,
>the write into
>LSAPIC is replaced by a physdev_op hypercall.

Talk early to xen mailing list, if there's really necessity to add a new 
physdev_op since all that type of operations is defined under public 
header directory.

>
>The xen changes are:
>
>* LID is virtualized.  In fact this was achieved with my vIOSAPIC patch.  I am
>planning
>to modify this so that SMP-g can be done without vIOSAPIC.

Glad to see that.

>The virtualized LID is ID=EID=vcpu_id.

>From the SDM, lower order bits of 'id' is a unique address of local system 
bus, and then higher order bits of 'id' together with 'eid' corresponds to an 
unique address of local system bus within entire system. Though not forced, 
will it better to conform to SDM description to keep user's convention? For 
example, only let lower order bits of 'id' equal to vcpu_id, with rest bits 
with 
same value for all VCPUs since we can simply present guest with one 
system bus.

>
>* ACPI LSAPIC entries are enabled for dom0 and added for domU.
>  For dom0, I have added a dom0_maxcpu= command line parameter to set
>the
>maximum number
>  of dom0 vcpu.

Not sure whether typo. Please keep same as x86, which is "dom0_max_vcpus=" 
option.

>
>* SAL_VECTOR_OS_BOOT_RENDEZ added to set iip and r1 of non-running
>vcpu.

Hope you are adding that emulation in sal_emulator (dom_fw.c), instead of 
the hack occurring in your last vIOSAPIC patch where it's handled within IPI 
emulation. :-)

>
>* SAL wakeup descriptor added.
>
>* physdev_op added to accept and deliver IPI as an interrupt.  It also handle
>vcpu start-up.

Once again, please consult xen mailing list if adding new physdev_op.

>
>* ITC_DRIFT feature added to SAL descriptors.  This avoids clock
>synchronizations which
>  can't be currently done since itc is not virtualized.

So I believe this is only temporary hack, which should be removed once itc
 virtualization is added. Or else xenlinux won't register the interpolator which
 may affect the accuracy because guest may assume there's another platform 
timer resource as reference. 

>
>* ptc.ga is a real problem: currently an IPI is sent in Xen to purge the VHPT.
>Performance
>  may be very bad.  We should think about this.
>
>

Yes, emulation of ptc.ga will be more complex than other emulations. However 
simply talking about the claim above, IPI is a necessity IMO, if another vcpu 
is 
running on another LP at the emulation. Though we may add some lazy flush 
later.

Thanks,
Kevin

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

<Prev in Thread] Current Thread [Next in Thread>