Xen's use of PAT and PV guests

Xen's use of PAT and PV guests

[Jeremy Fitzhardinge]

I'm looking again at what it will take to reconcile Xen's PAT setup with 
the standard Linux one so that we can enable PAT use in pvops kernels.

Just for reference, this is the Linux vs Xen vs default PAT setups:

Index	PTE flags	Linux	Xen	Default
0			WB	WB	WB
1	        PWT	WC	WT	WT
2	    PCD	   	UC-	UC-	UC-
3	    PCD PWT	UC	UC	UC
4	PAT        	WB	WC	WB
5	PAT     PWT	WC	WP	WT
6	PAT PCD	   	UC-	UC	UC-
7	PAT PCD PWT	UC	UC	UC


Originally I was thinking of a moderately complex scheme in which an ELF 
node on the dom0 kernel could determine the system-wide Xen PAT MSR, and 
then the kernel ELF notes on subsequent domains would determine whether 
the PAT CPU feature flag is enabled or not.

However this has several problems:

   1. it is fairly complex
   2. if dom0 sets the PAT configuration to something strange, it may
      completely break other PV guests entirely (since it might
      effectively change the meaning of PCD+PWT globally)
   3. disabling the PAT CPU feature flag is meaningless, as its only
      effect is to say "there's no PAT, so PCD/PWT have their default
      behaviours", which is definitely not true in general

Linux only uses the first 4 PAT entries, and repeats it, effectively 
making the PAT pte flag a don't-care.  In those 4 entries, the Linux, 
Xen and Default configurations are identical aside from Linux using WC 
rather than WT.

It therefore seems to me that if I make Linux:

   1. never set the PAT flag (which it won't anyway),
   2. check that the value written to IA32_PAT is as expected, but
      otherwise ignore it, and
   3. use WT rather than WC

then it all should just work.  I'm not completely confident in the third 
point though, since I'm not quite sure about the full set of differences 
between WT and WC, and their respective interactions with the MTRR, and 
whether that would break anything.  At first glance it seems pretty safe 
though...

Thoughts?

     J

Re: Xen's use of PAT and PV guests

[Jan Beulich]

>>> Jeremy Fitzhardinge <jeremy@goop.org> 30.03.10 02:35 >>>
>It therefore seems to me that if I make Linux:
>
>   1. never set the PAT flag (which it won't anyway),
>   2. check that the value written to IA32_PAT is as expected, but
>      otherwise ignore it, and
>   3. use WT rather than WC
>
>then it all should just work.  I'm not completely confident in the third 
>point though, since I'm not quite sure about the full set of differences 
>between WT and WC, and their respective interactions with the MTRR, and 
>whether that would break anything.  At first glance it seems pretty safe 
>though...

No. For one, while WT is cachable (for reads), WC isn't.

Second, when the MTRRs indicate WC, using WT from PAT is not
recommended (and was earlier documented as undefined behavior).

Third, performance would likely suffer (MTRR-{WC,UC} + PAT-WT -> UC
whereas MTRR-{WC,UC} + PAT-WC -> WC).

Plus all of this would need revisiting once Linux decides to use WT
or WP.

Jan

Re: Xen's use of PAT and PV guests

[Konrad Rzeszutek Wilk]

On Mon, Mar 29, 2010 at 05:35:57PM -0700, Jeremy Fitzhardinge wrote:
> I'm looking again at what it will take to reconcile Xen's PAT setup with  
> the standard Linux one so that we can enable PAT use in pvops kernels.
>
> Just for reference, this is the Linux vs Xen vs default PAT setups:

And this LKML is good a primer:

http://www.linuxsymposium.org/archives/OLS/Reprints-2008/pallipadi-reprint.pdf

>
> Index	PTE flags	Linux	Xen	Default
> 0			WB	WB	WB
> 1	        PWT	WC	WT	WT
> 2	    PCD	   	UC-	UC-	UC-
> 3	    PCD PWT	UC	UC	UC
> 4	PAT        	WB	WC	WB
> 5	PAT     PWT	WC	WP	WT
> 6	PAT PCD	   	UC-	UC	UC-
> 7	PAT PCD PWT	UC	UC	UC
>
>
> Originally I was thinking of a moderately complex scheme in which an ELF  
> node on the dom0 kernel could determine the system-wide Xen PAT MSR, and  
> then the kernel ELF notes on subsequent domains would determine whether  
> the PAT CPU feature flag is enabled or not.
>
> However this has several problems:
>
>   1. it is fairly complex
>   2. if dom0 sets the PAT configuration to something strange, it may
>      completely break other PV guests entirely (since it might
>      effectively change the meaning of PCD+PWT globally)

How does this work on pages shared across domains? Say Guest A makes the
page WC,Dom0 makes it WB and Xen puts it in WC, and Dom0 reads does a
Write/Read/Write, but in actuallity it is a Read/Write/Write. Or is
there no danger there since the grant table pages have UC set on them?

>   3. disabling the PAT CPU feature flag is meaningless, as its only
>      effect is to say "there's no PAT, so PCD/PWT have their default
>      behaviours", which is definitely not true in general
>
> Linux only uses the first 4 PAT entries, and repeats it, effectively  
> making the PAT pte flag a don't-care.  In those 4 entries, the Linux,  
> Xen and Default configurations are identical aside from Linux using WC  
> rather than WT.
>
> It therefore seems to me that if I make Linux:
>
>   1. never set the PAT flag (which it won't anyway),
>   2. check that the value written to IA32_PAT is as expected, but
>      otherwise ignore it, and
>   3. use WT rather than WC

That would make all writes synchronous. Why not write back?
>
> then it all should just work.  I'm not completely confident in the third  
> point though, since I'm not quite sure about the full set of differences  
> between WT and WC, and their respective interactions with the MTRR, and  
> whether that would break anything.  At first glance it seems pretty safe  
> though...

The graphics cards (and the XServer) are the ones that come in my mind
as heavy users of having this "just right".  But in most (all?) cases
they want it to be UC or better UC- so that shouldn't affect this.

http://lkml.indiana.edu/hypermail/linux/kernel/9904.1/0306.html

Ah, but of course, there is an exception:

(i915_dma.c): gtt = ioremap_wc(pci_resource_start(dev->pdev, gtt_bar) + gtt_offset, gtt_size);

and then 'ttm_bo_ioremap' which does the ioremap_wc if  TTM_PL_FLAG_WC is set.

And it looks to be is set by the Radeon (if card is an AGP) and nouveau
on their first memory BAR.  Also the vmwgfx (VMWare) driver sets this, but we don't have
to worry about that.


So I think setting it to WC->WT would mean that graphics performance
would go down the drain. But then, there are some lingering issues with the
TTM/DRM infrastructure that need to tracked down and I believe 
Arvind and Michael are actively looking at that.

Re: Xen's use of PAT and PV guests

[Jeremy Fitzhardinge]

On 03/30/2010 12:44 AM, Jan Beulich wrote:
>>>> Jeremy Fitzhardinge<jeremy@goop.org>  30.03.10 02:35>>>
>>>>          
>> It therefore seems to me that if I make Linux:
>>
>>    1. never set the PAT flag (which it won't anyway),
>>    2. check that the value written to IA32_PAT is as expected, but
>>       otherwise ignore it, and
>>    3. use WT rather than WC
>>
>> then it all should just work.  I'm not completely confident in the third
>> point though, since I'm not quite sure about the full set of differences
>> between WT and WC, and their respective interactions with the MTRR, and
>> whether that would break anything.  At first glance it seems pretty safe
>> though...
>>      
> No. For one, while WT is cachable (for reads), WC isn't.
>
> Second, when the MTRRs indicate WC, using WT from PAT is not
> recommended (and was earlier documented as undefined behavior).
>    

Yes, I noticed that, and I wondered if that was why Linux is using WC, 
for max compatibility.  But presumably since it is now defined 
unconditionally, it means that all older (Intel, at least) 
implementations have that defined behaviour.

> Third, performance would likely suffer (MTRR-{WC,UC} + PAT-WT ->  UC
> whereas MTRR-{WC,UC} + PAT-WC ->  WC).
>    

Yeah.  If !pat_enabled, Linux will map a WC pte into UC-.

> Plus all of this would need revisiting once Linux decides to use WT
> or WP.
>    

Yes.

Ah, I think I know how to do it now: when constructing a PTE, remap 
Linux's PWT to Xen's PAT to end up with a WC PTE.

Does Xen guarantee that PAT is always available to vcpus as part of its 
ABI  (ie, do we support any pre-PAT cpus?).

Also, I'm assuming Xen's PAT entries 6 and 7 are reserved, in case Intel 
defines 2 and 3?

     J

Re: Xen's use of PAT and PV guests

[Ian Campbell]

On Tue, 2010-03-30 at 01:35 +0100, Jeremy Fitzhardinge wrote:

> It therefore seems to me that if I make Linux:
> 
>    1. never set the PAT flag (which it won't anyway),
>    2. check that the value written to IA32_PAT is as expected, but
>       otherwise ignore it, and
>    3. use WT rather than WC
> 
> then it all should just work.

I had a patch ages ago (which I have now lost) that caused the kernel to
read back the PAT MSR after writing it and try and locate a suitable
entry for each cache setting it was interested in (with fallbacks as
appropriate) to use dynamically thereafter.

This has the nice property that Linux could write what it really wanted
to the PAT register but it would then read and use whatever it actually
ended up with.

I'm not sure that this scheme is at all upstreamable though.

Ian.

Re: Xen's use of PAT and PV guests

[Keir Fraser]

On 30/03/2010 18:39, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

> Does Xen guarantee that PAT is always available to vcpus as part of its
> ABI  (ie, do we support any pre-PAT cpus?).

As it happens I think we do only support CPUs that have PAT. But you can
always check CPUID, just like running natively.

 -- Keir

Re: Re: Xen's use of PAT and PV guests

[Jeremy Fitzhardinge]

On 03/30/2010 10:59 AM, Keir Fraser wrote:
> As it happens I think we do only support CPUs that have PAT. But you can
> always check CPUID, just like running natively.
>    

Yeah, I wasn't going to remove any of the tests, but I was wondering if 
the guest can always assume that it can set the pat flags in the pte.  I 
guess that since Xen uses the same settings for the default pat (=no pat 
at all), then so long as the guest doesn't try to set _PAGE_PAT, then it 
doesn't matter.

Unfortunately hugetlbfs adds a wart, since it appears to end up going 
down to the make_pte/pte_val path, but we can't tell whether its a page 
with _PAGE_PSE or _PAGE_PAT set...

     J

Re: Re: Xen's use of PAT and PV guests

[Jeremy Fitzhardinge]

On 03/30/2010 09:57 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 29, 2010 at 05:35:57PM -0700, Jeremy Fitzhardinge wrote:
>    
>> I'm looking again at what it will take to reconcile Xen's PAT setup with
>> the standard Linux one so that we can enable PAT use in pvops kernels.
>>
>> Just for reference, this is the Linux vs Xen vs default PAT setups:
>>      
> And this LKML is good a primer:
>
> http://www.linuxsymposium.org/archives/OLS/Reprints-2008/pallipadi-reprint.pdf
>    

Thanks, just what I was looking for.

>> Index	PTE flags	Linux	Xen	Default
>> 0			WB	WB	WB
>> 1	        PWT	WC	WT	WT
>> 2	    PCD	   	UC-	UC-	UC-
>> 3	    PCD PWT	UC	UC	UC
>> 4	PAT        	WB	WC	WB
>> 5	PAT     PWT	WC	WP	WT
>> 6	PAT PCD	   	UC-	UC	UC-
>> 7	PAT PCD PWT	UC	UC	UC
>>
>>
>> Originally I was thinking of a moderately complex scheme in which an ELF
>> node on the dom0 kernel could determine the system-wide Xen PAT MSR, and
>> then the kernel ELF notes on subsequent domains would determine whether
>> the PAT CPU feature flag is enabled or not.
>>
>> However this has several problems:
>>
>>    1. it is fairly complex
>>    2. if dom0 sets the PAT configuration to something strange, it may
>>       completely break other PV guests entirely (since it might
>>       effectively change the meaning of PCD+PWT globally)
>>      
> How does this work on pages shared across domains? Say Guest A makes the
> page WC,Dom0 makes it WB and Xen puts it in WC, and Dom0 reads does a
> Write/Read/Write, but in actuallity it is a Read/Write/Write. Or is
> there no danger there since the grant table pages have UC set on them?
>    

Not sure.  That would invoke undefined behaviour, I'd assume.  Does Xen 
keep track of memory type aliases?  Grant pages don't have to be UC do 
they?  Pages between front and backends don't need to be (and shouldn't 
be) UC.

> The graphics cards (and the XServer) are the ones that come in my mind
> as heavy users of having this "just right".  But in most (all?) cases
> they want it to be UC or better UC- so that shouldn't affect this.
>    

Hm, I don't want to try out-guessing Linux's use of all these modes; we 
need to either get it right or not try.

     J

Re: Xen's use of PAT and PV guests

[Jeremy Fitzhardinge]

On 03/30/2010 10:56 AM, Ian Campbell wrote:
> I had a patch ages ago (which I have now lost) that caused the kernel to
> read back the PAT MSR after writing it and try and locate a suitable
> entry for each cache setting it was interested in (with fallbacks as
> appropriate) to use dynamically thereafter.
>
> This has the nice property that Linux could write what it really wanted
> to the PAT register but it would then read and use whatever it actually
> ended up with.
>

I started to implement something like that, but stopped and decided to 
do a much simpler hack.  I wanted to make sure that make_pte and pte_val 
are proper inverses of each other, so pte_val needs to do the reverse 
mapping from xen pte pat flags -> linux pte pat flags.  Given that the 
only difference between Xen and Linux is whether _PAGE_PWT means WT or 
WC, it is easy to do the mapping forward and back.

But hugetlbfs adds the complication that it ends up constructing ptes 
via the pte operations (which makes logical sense), but on x86 that's a 
mess because the meaning of _PAGE_PAT changes to _PAGE_PSE on level 
2/3/4 entries, and there's no way of knowing what level we're looking at.

At the moment I'm winging it by ignoring _PAGE_PAT in make_pte, and hope 
that nobody wants to do pte_val on a hugetlbfs pte...

Looks like the proper fix is to stop hugetlbfs from using mk_pte, and 
add a mk_huge_tlb instead, and have the x86 version use the pmd operations.

> I'm not sure that this scheme is at all upstreamable though.
>

I don't see why not; it would all be hidden away in the Xen code, and 
maintains the normal x86 illusion.   It's just a matter of hooking 
wrmsr, make_pte and pte_val, which we do already.

     J

Re: Re: Xen's use of PAT and PV guests

[Jan Beulich]

>>> Jeremy Fitzhardinge <jeremy@goop.org> 30.03.10 20:43 >>>
>On 03/30/2010 09:57 AM, Konrad Rzeszutek Wilk wrote:
>> How does this work on pages shared across domains? Say Guest A makes the
>> page WC,Dom0 makes it WB and Xen puts it in WC, and Dom0 reads does a
>> Write/Read/Write, but in actuallity it is a Read/Write/Write. Or is
>> there no danger there since the grant table pages have UC set on them?
>>    
>
>Not sure.  That would invoke undefined behaviour, I'd assume.  Does Xen 
>keep track of memory type aliases?  Grant pages don't have to be UC do 
>they?  Pages between front and backends don't need to be (and shouldn't 
>be) UC.

Granted pages are RAM pages, and hence should always be WB
everywhere.

As to Xen's memory type handling - iirc the most recent memory type
used in a page table entry determines what Xen uses in its 1:1 mapping,
but I don't think global consistency is being enforced.

Jan

Re: Xen's use of PAT and PV guests

[Ian Campbell]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Tue, 2010-03-30 at 22:47 +0100, Jeremy Fitzhardinge wrote:
> 
> > I'm not sure that this scheme is at all upstreamable though.
> >
> 
> I don't see why not; it would all be hidden away in the Xen code, and 
> maintains the normal x86 illusion.   It's just a matter of hooking 
> wrmsr, make_pte and pte_val, which we do already. 

I was referring to my patch which wasn't at all hidden away in the Xen
code. Anyway I've found and attached it for your amusement, it's not
nearly as fully baked as I remembered ;-) In my defence the date stamp
on the patch file is May 2009...

Ian.


[-- Attachment #2: pat --]
[-- Type: text/x-patch, Size: 9467 bytes --]

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 54cb697..ef947d8 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -68,14 +68,22 @@
 			 _PAGE_DIRTY)
 
 /* Set of bits not changed in pte_modify */
-#define _PAGE_CHG_MASK	(PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT |		\
+#define _PAGE_CHG_MASK	(PTE_PFN_MASK | _PAGE_PAT | _PAGE_PCD | _PAGE_PWT | \
 			 _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY)
 
-#define _PAGE_CACHE_MASK	(_PAGE_PCD | _PAGE_PWT)
-#define _PAGE_CACHE_WB		(0)
-#define _PAGE_CACHE_WC		(_PAGE_PWT)
-#define _PAGE_CACHE_UC_MINUS	(_PAGE_PCD)
-#define _PAGE_CACHE_UC		(_PAGE_PCD | _PAGE_PWT)
+#define _PAGE_CACHE_MASK	(_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)
+
+#ifndef __ASSEMBLY__
+extern unsigned __page_cache_wb;
+extern unsigned __page_cache_wc;
+extern unsigned __page_cache_uc_minus;
+extern unsigned __page_cache_uc;
+#endif
+
+#define _PAGE_CACHE_WB		__page_cache_wb
+#define _PAGE_CACHE_WC		__page_cache_wc
+#define _PAGE_CACHE_UC_MINUS	__page_cache_uc_minus
+#define _PAGE_CACHE_UC		__page_cache_uc
 
 #define PAGE_NONE	__pgprot(_PAGE_PROTNONE | _PAGE_ACCESSED)
 #define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | \
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index c66dda1..0137c05 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -304,6 +304,8 @@ void __init get_mtrr_state(void)
 	unsigned lo, dummy;
 	unsigned long flags;
 
+	printk(KERN_CRIT "pat: made it to get_mtrr_state\n");
+
 	vrs = mtrr_state.var_ranges;
 
 	rdmsr(MTRRcap_MSR, lo, dummy);
@@ -336,6 +338,7 @@ void __init get_mtrr_state(void)
 	local_irq_save(flags);
 	prepare_set();
 
+	printk(KERN_CRIT "pat: get_mtrr_state calling pat_init()\n");
 	pat_init();
 
 	post_set();
@@ -614,6 +617,7 @@ static void generic_set_all(void)
 	mask = set_mtrr_state();
 
 	/* also set PAT */
+	printk(KERN_CRIT "pat: generic_set_all() calling pat_init()\n");
 	pat_init();
 
 	post_set();
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index fd5ac04..6eee754 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -623,6 +623,8 @@ void __init mtrr_bp_init(void)
 {
 	u32 phys_addr;
 
+	printk(KERN_CRIT "pat: made it to mtrr_bp_init\n");
+
 	init_ifs();
 
 	phys_addr = 32;
@@ -690,16 +692,22 @@ void __init mtrr_bp_init(void)
 	}
 
 	if (mtrr_if) {
+		printk(KERN_CRIT "pat: in mtrr_bp_init and mtrr_if is true\n");
+
 		num_var_ranges = mtrr_if->num_var_ranges();
 		init_table();
 		if (use_intel()) {
+			printk(KERN_CRIT "pat: mtrr_bp_init calling get_mtrr_state\n");
 			get_mtrr_state();
 
 			if (mtrr_cleanup(phys_addr)) {
 				changed_by_mtrr_cleanup = 1;
+				printk(KERN_CRIT "pat: mtrr_bp_init calling %pF via set_all hook\n", &mtrr_if->set_all);
 				mtrr_if->set_all();
 			}
 
+		} else {
+			printk(KERN_CRIT "pat: in mtrr_bp_init but not use_intel()\n");
 		}
 	}
 }
@@ -720,6 +728,7 @@ void mtrr_ap_init(void)
 	 */
 	local_irq_save(flags);
 
+	printk(KERN_CRIT "pat: mtrr_ap_init calling %pF via set_all hook\n", &mtrr_if->set_all);
 	mtrr_if->set_all();
 
 	local_irq_restore(flags);
diff --git a/arch/x86/kernel/cpu/mtrr/xen.c b/arch/x86/kernel/cpu/mtrr/xen.c
index 50a45db..63f86aa 100644
--- a/arch/x86/kernel/cpu/mtrr/xen.c
+++ b/arch/x86/kernel/cpu/mtrr/xen.c
@@ -15,6 +15,8 @@ static void xen_set_mtrr(unsigned int reg, unsigned long base,
 	struct xen_platform_op op;
 	int error;
 
+	printk(KERN_CRIT "pat: xen_set_mtrr\n");
+
 	/* mtrr_ops->set() is called once per CPU,
 	 * but Xen's ops apply to all CPUs.
 	 */
@@ -87,7 +89,7 @@ static struct mtrr_ops xen_mtrr_ops = {
 	.get_free_region   = xen_get_free_region,
 	.validate_add_page = generic_validate_add_page,
 	.have_wrcomb       = positive_have_wrcomb,
-	.use_intel_if	   = 0,
+	.use_intel_if	   = 1/*0*/,
 	.num_var_ranges	   = xen_num_var_ranges,
 };
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1b1c851..f704078 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -834,6 +834,7 @@ void __init setup_arch(char **cmdline_p)
 	/* preallocate 4k for mptable mpc */
 	early_reserve_e820_mpc_new();
 	/* update e820 for memory not covered by WB MTRRs */
+	printk(KERN_CRIT "pat: calling mtrr_bp_init from setup_arch()\n");
 	mtrr_bp_init();
 	if (mtrr_trim_uncached_memory(max_pfn))
 		max_pfn = e820_end_of_ram_pfn();
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 8a45093..3c13d64 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -141,18 +141,12 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long size,
 	unsigned long nrpages = size >> PAGE_SHIFT;
 	int err;
 
-	switch (prot_val) {
-	case _PAGE_CACHE_UC:
-	default:
-		err = _set_memory_uc(vaddr, nrpages);
-		break;
-	case _PAGE_CACHE_WC:
+	if (prot_val == _PAGE_CACHE_WC)
 		err = _set_memory_wc(vaddr, nrpages);
-		break;
-	case _PAGE_CACHE_WB:
+	else if (prot_val == _PAGE_CACHE_WB)
 		err = _set_memory_wb(vaddr, nrpages);
-		break;
-	}
+	else /* _PAGE_CACHE_UC or "other" */
+		err = _set_memory_uc(vaddr, nrpages);
 
 	return err;
 }
@@ -256,21 +250,14 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 		prot_val = new_prot_val;
 	}
 
-	switch (prot_val) {
-	case _PAGE_CACHE_UC:
-	default:
-		prot = PAGE_KERNEL_IO_NOCACHE;
-		break;
-	case _PAGE_CACHE_UC_MINUS:
-		prot = PAGE_KERNEL_IO_UC_MINUS;
-		break;
-	case _PAGE_CACHE_WC:
+	if (prot_val == _PAGE_CACHE_WC)
 		prot = PAGE_KERNEL_IO_WC;
-		break;
-	case _PAGE_CACHE_WB:
+	else if (prot_val == _PAGE_CACHE_WB)
 		prot = PAGE_KERNEL_IO;
-		break;
-	}
+	else if (prot_val == _PAGE_CACHE_UC_MINUS)
+		prot = PAGE_KERNEL_IO_UC_MINUS;
+	else /* _PAGE_CACHE_UC or "other" */
+		prot = PAGE_KERNEL_IO_NOCACHE;
 
 	/*
 	 * Ok, go for it..
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 3f7886f..f85a273 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -61,6 +61,11 @@ __setup("debugpat", pat_debug_setup);
 
 static u64 __read_mostly boot_pat_state;
 
+unsigned __page_cache_wb;
+unsigned __page_cache_wc;
+unsigned __page_cache_uc_minus;
+unsigned __page_cache_uc;
+
 enum {
 	PAT_UC = 0,		/* uncached */
 	PAT_WC = 1,		/* Write combining */
@@ -70,15 +75,43 @@ enum {
 	PAT_UC_MINUS = 7,	/* UC, but can be overriden by MTRR */
 };
 
+const char *pat_labels[8] = {
+	"broken",
+	"broken",
+	"broken",
+	"broken",
+	"broken",
+	"broken",
+	"broken",
+	"broken"
+};
+
 #define PAT(x, y)	((u64)PAT_ ## y << ((x)*8))
 
+static unsigned find_pat_index(const u64 pat, int mode)
+{
+	u64 mask;
+	int i;
+
+	for (mask = 0x7, i = 0; i < 8; mask <<= 8, i++) {
+		if (((pat & mask)>>(i*8)) == mode)
+			return i;
+	}
+	return -1; /* OR??? */
+}
+
 void pat_init(void)
 {
 	u64 pat;
 
-	if (!pat_enabled)
+	printk(KERN_CRIT "%s\n", __func__);
+	dump_stack();
+	if (!pat_enabled) {
+		printk(KERN_CRIT "%s pat not enabled\n", __func__);
 		return;
+	}
 
+	printk(KERN_CRIT "%s:%d\n", __func__, __LINE__);
 	if (!cpu_has_pat) {
 		if (!boot_pat_state) {
 			pat_disable("PAT not supported by CPU.");
@@ -95,6 +128,8 @@ void pat_init(void)
 		}
 	}
 
+	printk(KERN_CRIT "%s:%d\n", __func__, __LINE__);
+
 	/* Set PWT to Write-Combining. All other bits stay the same */
 	/*
 	 * PTE encoding used in Linux:
@@ -105,32 +140,41 @@ void pat_init(void)
 	 *      000 WB		_PAGE_CACHE_WB
 	 *      001 WC		_PAGE_CACHE_WC
 	 *      010 UC-		_PAGE_CACHE_UC_MINUS
-	 *      011 UC		_PAGE_CACHE_UC
-	 * PAT bit unused
+	 *      011 UC		_PAGE_CACHE_UC PAT bit unused
 	 */
 	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
-	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+		PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
 
 	/* Boot CPU check */
 	if (!boot_pat_state)
 		rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
 
 	wrmsrl(MSR_IA32_CR_PAT, pat);
+
+
+	/* Now see what we actually got */
+	rdmsrl(MSR_IA32_CR_PAT, pat);
+	__page_cache_wb = find_pat_index(pat, PAT_WB);
+	__page_cache_wc = find_pat_index(pat, PAT_WC);
+	__page_cache_uc_minus = find_pat_index(pat, PAT_UC_MINUS);
+	__page_cache_uc = find_pat_index(pat, PAT_UC);
+
+	pat_labels[__page_cache_wb] = "write-back";
+	pat_labels[__page_cache_wc] = "write-combining";
+	pat_labels[__page_cache_uc_minus] = "uncached-minus";
+	pat_labels[__page_cache_uc] = "uncached";
+
 	printk(KERN_INFO "x86 PAT enabled: cpu %d, old 0x%Lx, new 0x%Lx\n",
 	       smp_processor_id(), boot_pat_state, pat);
+	printk(KERN_INFO "Indexes: WB:%d; WC:%d; UC-:%d; UC:%d\n",
+	       __page_cache_wb, __page_cache_wc, __page_cache_uc_minus, __page_cache_uc);
 }
 
 #undef PAT
 
 static char *cattr_name(unsigned long flags)
 {
-	switch (flags & _PAGE_CACHE_MASK) {
-	case _PAGE_CACHE_UC:		return "uncached";
-	case _PAGE_CACHE_UC_MINUS:	return "uncached-minus";
-	case _PAGE_CACHE_WB:		return "write-back";
-	case _PAGE_CACHE_WC:		return "write-combining";
-	default:			return "broken";
-	}
+	return pat_labels[flags & _PAGE_CACHE_MASK];
 }
 
 /*
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e099e44..232ed3e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1121,7 +1121,7 @@ asmlinkage void __init xen_start_kernel(void)
 		xen_start_info->console.domU.evtchn = 0;
 	}
 
-	pat_disable("PAT disabled on Xen");
+	//pat_disable("PAT disabled on Xen");
 
 	xen_raw_console_write("about to get started...\n");
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: Xen's use of PAT and PV guests

[Jeremy Fitzhardinge]

On 03/31/2010 01:31 AM, Ian Campbell wrote:
> I was referring to my patch which wasn't at all hidden away in the Xen
> code. Anyway I've found and attached it for your amusement, it's not
> nearly as fully baked as I remembered ;-) In my defence the date stamp
> on the patch file is May 2009...
>    

Urk, yeah, that's going to be much harder to make fly.  Conversion at 
the make_pte/pte_val level gets us most of way there with less intrusion.

     J