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
|
Home