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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 09 Mars 2006 01:59, Tian, Kevin a écrit :
> 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.
No, I didn't add an op.

> >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.
Ok.

> >* 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.
I missed this option, thanks.

> >* 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. :-)
Both are required: one to set ip/gr, one to start vcpu.

> >* 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.
The interpolator can be done inside Xen.
I'd like to have a design note on virtualizing itc.  It seems really hard to 
do this correctly on ia64.  Para-virtualizing it is very chip.

> >* 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.
Ok.

Tristan.


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