[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] RE: how to put kernel module in xen/ipf


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 23 Jun 2005 09:40:32 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 23 Jun 2005 01:39:34 +0000
  • List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcV2H2lMV/sz2iLUSG2pTMbU1moFDwASkl6wABeprlAAGW78cAAZL3KQ
  • Thread-topic: [Xen-ia64-devel] RE: how to put kernel module in xen/ipf

Before Anthony talks more details later, I can say some about the background.

 

1.       This kernel module is not running within Xen, but a standalone module running in Dom0.

 

2.       Since VTI domain0 is unmodified, we have to make hypercall/evtchn as a module. Most code are copied from x86 side, with major difference in privcmd_core.c due to parameter pass mechanism.

 

3.       We haven’t found a good place to contain these files. So temporarily put under xen/arch/ia64.

 

4.       It won’t be compiled into Xen. You have to manually “make” in xen/arch/ia64/km, with 2.6.11 kernel source in same directory level as xeno-unstable-ia64.

 

Then do you have any good suggestion for the place? We’d like to hear that.

 

The logic of the module also applies to para-dom0, and you guys can add more upon it if possible. Kernel module style can satisfy both sides easily.

 

Thanks,

Kevin

 


From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Magenheimer, Dan (HP Labs Fort Collins)
Sent: Wednesday, June 22, 2005 9:39 PM
To: Xu, Anthony
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-ia64-devel] RE: how to put kernel module in xen/ipf

 

This describes the mechanics for the call but there are several things I don't understand,

especially after seeing the patch:

 

1) Why would these modules be in Xen at all?  They appear to be (at least very similar to) the

    code from Domain0.  Why is the functionality duplicated from Domain0?  Are you

    trying to eliminate Domain0?

2) How do these modules get dynamically "loaded"?  Xen/ia64 currently has no disk

    access or any driver support; all bits are currently put in memory at boot time by elilo.

    (And if they are not dynamically loaded, why are they "kernel modules"?)

3) Is there any similarity between this and Xen/x86(VTx)?  I looked for similar code/mechanism

   on Xen/x86 to help me understand your intent but didn't find anything.

 

Unless I'm completely misunderstanding, this seems to be heading in the direction

of major architectural departures from the direction of Xen.  I think we should have some

more discussion before applying these "km" patches.

 

Could you provide an architectural overview of what you are trying to do here rather

than just the mechanics of how the VTLB and hypercall work?


Thanks,

Dan

 


From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
Sent: Tuesday, June 21, 2005 7:57 PM
To: Magenheimer, Dan (HP Labs Fort Collins)
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: how to put kernel module in xen/ipf

Hi, Dan,

 

We implemented VTLB infrastructure per domain on XEN/IPF, which tracked guest tlb information. VTLB has fixed size, then when using out of it, HV will desert all VTLB and recycle VTLB. We add a flag “lock” in VTLB entry, when HV recycle VTLB, the VTLB entry with “lock” flag will not be deserted, but if Guest uses instructions like “ptc” to purge tlb, the VTLB entry with “lock” flag will be deserted.

 

Before invoking hypercall,

Kernel Module pseudo read parameter once per page size to make sure the translation for this parameter has been inserted in VTLB infrastructure. Then kernel Module will call another new hypercall which don’t need pointer parameter to lock above translation in VTLB infrastructure.

 

Then invoking this hypercall,

In HV, HV will use copy_from_user() or copy_to_user() to get parameter or return result. In these functions, HV will lookup VTLB infrastructure to get corresponding guest physical address of the parameter, because this translation has been locked in VTLB, HV definitely can find it, then HV can get corresponding machine address from physical to machine address table, as we know HV use region 7 for identity mapping, HV can get identity virtual address for that machine address, at last, HV do normal copy operation using this identity virtual address.

 

After this hypercall,

Guest application definitely will unmap the memory allocated for passing hypercall parameter, and this operation definitely will purge tlb for this address, so the “lock” VTLB entry in VTLB infrastructure can be recycled.

 

We had tested this parameter passing mechanism for several hypercalls, such as GETMEMLIST, and it works well.

 

Could we check in this patch and discuss further?

 

 

 

 

-Anthony


From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
Sent: 2005
621 22:04
To: Xu, Anthony
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: how to put kernel module in xen/ipf

 

Yes, the hypercall parameter mechanism is still evolving for Xen/ia64.  Very few

hypercalls are necessary to run domain0, so experimentation with different hypercall

mechanisms has waited until multi-domain work.

 

Can you explain more about kernel modules?  I know (roughly) how they

work for Linux, but not how they are used on Xen/x86.  Others on this

list might like to learn too, so perhaps you could explain the design

in detail?


Thanks,
Dan

 


From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
Sent: Monday, June 20, 2005 11:10 PM
To: Magenheimer, Dan (HP Labs Fort Collins)
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: how to put kernel module in xen/ipf

Hi, Dan,       

XEN/IPF kernel module has a lot of difference from XEN/ia32, especially the mechanism of passing hypercall parameter. Currently we create directory “km” under xen/arch/ia64, and put kernel module code in that directory.

        Any comment?

-Anthony

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.