Xenlinux uses a special architecture-dependent bit in the page table, called PG_arch_1 to indicate that a page is "foreign" (PG_foreign). It also apparently uses it to determine if a page is pinned (PG_pinned). Linux/ia64 (and apparently Linux/ppc and Linux/ppc64) use the PG_arch_1 bit for other purposes. On Linux/ia64, it is used to determine if the instruction cache needs to be flushed (e.g. if writing data into code pages). Any thought on this apparent conflict? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Magenheimer, Dan >(HP Labs Fort Collins) >Sent: 2005年12月7日 9:13 > >Xenlinux uses a special architecture-dependent bit in the page table, >called PG_arch_1 to indicate that a page is "foreign" (PG_foreign). >It also apparently uses it to determine if a page is pinned (PG_pinned). > >Linux/ia64 (and apparently Linux/ppc and Linux/ppc64) use the PG_arch_1 >bit for other purposes. On Linux/ia64, it is used to determine if >the instruction cache needs to be flushed (e.g. if writing data >into code pages). > >Any thought on this apparent conflict? > >Thanks, >DanAdd a new PG_arch_2, since there''re two level architectures within xenlinux world? Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7 Dec 2005, at 03:11, Tian, Kevin wrote:>> Any thought on this apparent conflict? >> >> Thanks, >> Dan > > Add a new PG_arch_2, since there''re two level architectures within > xenlinux world?Yes, I think this is the right answer. There are loads of spare bits available to stealing one should be no problem. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On 7 Dec 2005, at 03:11, Tian, Kevin wrote: > >> Any thought on this apparent conflict? > >> > >> Thanks, > >> Dan > > > > Add a new PG_arch_2, since there''re two level architectures within > > xenlinux world? > > Yes, I think this is the right answer. There are loads of spare bits > available to stealing one should be no problem. > > -- KeirTrue, but I''ve heard tell that these bits are jealously guarded. In any case, PG_arch_1 is used for other purposes on ia64, ppc, ppc64, sparc64, arm, mips, pa-risc, and even has semantics for linux arch-neutral code (look for PG_Arch_1 in linux/Documentation/cachetlb.txt... does Xen depend on this behavior?), and the eventual goal is to merge upstream, it might be best if Xen defines it as a new bit ("PG_foreign"? no sense being vague by calling it PG_arch_2) rather than overloads PG_arch_1? Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@hp.com] >Sent: 2005年12月8日 22:33 >> On 7 Dec 2005, at 03:11, Tian, Kevin wrote: >> >> Any thought on this apparent conflict? >> >> >> >> Thanks, >> >> Dan >> > >> > Add a new PG_arch_2, since there''re two level architectures within >> > xenlinux world? >> >> Yes, I think this is the right answer. There are loads of spare bits >> available to stealing one should be no problem. >> >> -- Keir > >True, but I''ve heard tell that these bits are jealously guarded. > >In any case, PG_arch_1 is used for other purposes on ia64, ppc, >ppc64, sparc64, arm, mips, pa-risc, and even has semantics for >linux arch-neutral code (look for PG_Arch_1 in >linux/Documentation/cachetlb.txt... does Xen depend on this >behavior?), and the eventual goal is to merge upstream, >it might be best if Xen defines it as a new bit ("PG_foreign"? >no sense being vague by calling it PG_arch_2) rather than >overloads PG_arch_1? > >DanI prefer to the "vague" name here. By using PG_foreign, how can this bit be utilized by other places when running out of virtualization world? Since these bits are *jealously* guarded, name of the new bit should encourage more usages instead of special purpose. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >In any case, PG_arch_1 is used for other purposes on ia64, ppc, > >ppc64, sparc64, arm, mips, pa-risc, and even has semantics for > >linux arch-neutral code (look for PG_Arch_1 in > >linux/Documentation/cachetlb.txt... does Xen depend on this > >behavior?), and the eventual goal is to merge upstream, > >it might be best if Xen defines it as a new bit ("PG_foreign"? > >no sense being vague by calling it PG_arch_2) rather than > >overloads PG_arch_1? > > I prefer to the "vague" name here. By using PG_foreign, how > can this bit be utilized by other places when running out of > virtualization world? Since these bits are *jealously* > guarded, name of the new bit should encourage more usages > instead of special purpose.That''s exactly the problem. If any Linux arch sees the bit as generic and decides to use it for some other purpose, then Xenlinux can''t use it anymore. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@hp.com] >Sent: 2005年12月9日 11:17 >> >In any case, PG_arch_1 is used for other purposes on ia64, ppc, >> >ppc64, sparc64, arm, mips, pa-risc, and even has semantics for >> >linux arch-neutral code (look for PG_Arch_1 in >> >linux/Documentation/cachetlb.txt... does Xen depend on this >> >behavior?), and the eventual goal is to merge upstream, >> >it might be best if Xen defines it as a new bit ("PG_foreign"? >> >no sense being vague by calling it PG_arch_2) rather than >> >overloads PG_arch_1? >> >> I prefer to the "vague" name here. By using PG_foreign, how >> can this bit be utilized by other places when running out of >> virtualization world? Since these bits are *jealously* >> guarded, name of the new bit should encourage more usages >> instead of special purpose. > >That''s exactly the problem. If any Linux arch sees the bit >as generic and decides to use it for some other purpose, then >Xenlinux can''t use it anymore. > >DanAh, you''re right. So how to balance? If suggesting to add a new flag which can only be exclusively used by one case, that''s likely to see resistance. However if introducing a generic flag, same issue upon PG_arch_1 will happen as you said. ;-( Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel