RE: [Xen-devel] Review needed for "commonisation" ofcommon/grant_table.c

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Hi, Dan,
        Sorry that I still keeps common list as the audience, since we
may hear from difference voices to catch up common concept more
accurately, and this will definitely benefit other archs in porting xen
too. ;-)

>
>It appears to me that it probably won't be necessary to split the code
>into common and arch-dep as the differences can be abstracted
>by macros and static inlines in header files.  However, if
>the macros create difficulty for x86, either splitting the
>code -- or perhaps including an asm/grant_table.h -- would
>be OK with me.  What do you think Christopher?

Either way may be OK. The importance is that people should notice the
difference among archs to share pages between domains. Yes, my another
look shows it's not that much x86 specific. But something like shadow
mode/writable pt should be abstracted and not in common code, because
how to implement memory virtualization is arch specific. Common code
should only focus on handling pfn in the way that xen memory allocator
(buddy and xmalloc) understands. Arch specific code then deals with
properties in higher layer, that it's own wrapper understands.

>
>> We need reference counts on ia64, not for special page, but
>> page share.
>> Front end driver and VBD needs to share pages that domA owns to domB
>> where backend is running. Also shared info frame will be
>> shared between
>> domain and xen, where reference count is also necessary. We'll send a
>> patch to you after grabbing it from our local tree cleanly. :)
>
>I'm still not clear on the value of reference counts for Xen/ia64
>since unprivileged domains do not have direct access to physical
>memory.  Since this is an arch-dep discussion, let's switch this
>discussion to xen-ia64-devel.
>

Front end in Domain N may share its own page list with backend in Domain
0, to achieve maximum performance. Then backend can read/write those
shared pages directly. This doesn't mean granting unprivileged domains
direct access to physical memory. Instead, this just adds two mappings
to same machine page for different domains. Access to that machine page
is still controlled by xen for each domain, but as you can see, two
domains actually own same machine page simultaneously. This is why
reference count is necessary, since this is a common work model. You can
take a look at docs/misc/grant_tables.txt, which presents two
outstanding requirement for page sharing, thus for reference count.

I'm not sure whether your para-virtualization plan includes
frontend/backend model. Sorry for that confusion due to I suddenly
recalled a term "transparent para-virtualization" mentioned by you
sometime ago, but not exactly the details. :) 'Yes' is welcome, because
that's definitely required if people want to speed up performance. 

Thanks,
Kevin

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