Re: Powerdown problem on XEN | ACPI S5

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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

On Thu, Aug 15, 2013 at 09:28:24PM +0200, Atom2 wrote:
> Hi guys,
> thanks for your further input.
> 
> Following through Ben's mail below and Konrad's later mail
> suggesting the same, I tried to get these patches in. I'd however
> require your help before I feel I can safely proceed.
> 
> Please see below:
> 
> Am 15.08.13 03:58, schrieb Ben Guthro:
> [...]
> >I admit, I don't know how the gentoo build system works, but the general
> >idea here is that you want to revert those 2 commits, and apply the third.
> >
> >If you don't have a git tree, you can download the two commits from
> >these two links
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=c79c49826270b8b0061b2fca840fc3f013c8a78a
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=8eaffa67b43e99ae581622c5133e20b0f48bcef1
> >
> >You'll want to apply them in reverse
> After consultation with the manual I decided to give it a dry-run
> before and check with you guys first. First of all, I assume I'm
> righht that this is a patch to the *linux kernel* and not the
> xen-sources as I could not find the referenced files in the xen
> tree.

Right. You also need to compile the kernel. Usually I pluck the
/boot/config-my-exisitng-kernel-vresion and put it in the linux
directory as .config.

> 
> >patch -p1 -R < c79c498.patch
> vm-host # patch --dry-run -p1 -R < c79c498.patch
> patching file arch/x86/xen/enlighten.c
> Hunk #2 succeeded at 1431 (offset 14 lines).
> 
> I am slightly worried about the last message, not so much about the
> offset, but rather only the "Hunk #2" success. Why is there no "Hunk
> #1" when there's a "Hunk #2"?
> 
> >patch -p1 -R < 8eaffa67.patch
> vm-host # patch --dry-run -p1 -R < 8eaffa67.patch
> patching file arch/x86/xen/enlighten.c
> Hunk #1 succeeded at 1367 (offset 226 lines).
> patching file arch/x86/xen/mmu.c
> Hunk #1 succeeded at 434 (offset 19 lines).
> Hunk #2 succeeded at 482 (offset 19 lines).
> Hunk #3 succeeded at 495 (offset 19 lines).
> 
> That seems to be o.k. from my understanding?
> >
> >Then apply the patch from
> >https://lkml.org/lkml/2012/2/10/229
> For this patch I copied the complete text from the https address
> above and copied it to a file named 229.patch. Then I issued the
> following command:
> vm-host # patch --dry-run -p1 -R < 229.patch
> patching file arch/x86/include/asm/pgtable.h
> Unreversed patch detected!  Ignore -R? [n]

Note that you had been using --dry-run which means that the changes
did NOT go in effect.
> 
> I am not sure what to make out of this? Could you please provide some input.

Attaching the full part thanks to Martin Cerveny <martin@c-home.cz>
doing it in another thread (about the Nvidia and CUDA).

You basically want those changes that the diff file has.

After the patching, if you run git diff you should see a similar
result to what the attached patch had.

Then just do 'make -j3141567891238901948248092840932480932; sudo make modules_install; sudo make
install;sudo grub2-mkconfig -o /boot/grub2/grub.cfg' and reboot the new
kernel.

> Thanks and sorry for those probably dumb questions. I'm new to this
> (automated) patching thing, and with a little help, the first time
> usually works out well.

P.S.
No need to do the -j31415.. It should be just the amount of CPUs
you have.
> 

[-- Attachment #2: linux-3.9.fc18-PAT.patch --]
[-- Type: text/plain, Size: 3882 bytes --]

diff -uNrp linux-3.9.11-200.fc18.x86_64/arch/x86/include/asm/pgtable.h linux-3.9.11-200.PAT.fc18.x86_64/arch/x86/include/asm/pgtable.h
--- linux-3.9.11-200.fc18.x86_64/arch/x86/include/asm/pgtable.h	2013-08-13 22:35:49.372205382 +0200
+++ linux-3.9.11-200.fc18.x86_64/arch/x86/include/asm/pgtable.h	2013-08-13 22:58:23.212956533 +0200
@@ -353,6 +353,11 @@ static inline pgprot_t pgprot_modify(pgp
 	return __pgprot(preservebits | addbits);
 }
 
+static inline pgprot_t pte_attrs(pte_t pte)
+{
+	return __pgprot(pte_val(pte) & PTE_FLAGS_MASK);
+}
+
 #define pte_pgprot(x) __pgprot(pte_flags(x) & PTE_FLAGS_MASK)
 
 #define canon_pgprot(p) __pgprot(massage_pgprot(p))
diff -uNrp linux-3.9.11-200.fc18.x86_64/arch/x86/mm/pageattr.c linux-3.9.11-200.PAT.fc18.x86_64/arch/x86/mm/pageattr.c
--- linux-3.9.11-200.fc18.x86_64/arch/x86/mm/pageattr.c	2013-08-13 22:35:49.377206198 +0200
+++ linux-3.9.11-200.fc18.x86_64/arch/x86/mm/pageattr.c	2013-08-13 22:58:23.213956696 +0200
@@ -708,7 +708,7 @@ repeat:
 
 	if (level == PG_LEVEL_4K) {
 		pte_t new_pte;
-		pgprot_t new_prot = pte_pgprot(old_pte);
+		pgprot_t new_prot = pte_attrs(old_pte);
 		unsigned long pfn = pte_pfn(old_pte);
 
 		pgprot_val(new_prot) &= ~pgprot_val(cpa->mask_clr);
diff -uNrp linux-3.9.11-200.fc18.x86_64/arch/x86/xen/enlighten.c linux-3.9.11-200.PAT.fc18.x86_64/arch/x86/xen/enlighten.c
--- linux-3.9.11-200.fc18.x86_64/arch/x86/xen/enlighten.c	2013-08-13 22:35:49.404210605 +0200
+++ linux-3.9.11-200.fc18.x86_64/arch/x86/xen/enlighten.c	2013-08-13 22:52:28.505074079 +0200
@@ -67,7 +67,6 @@
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
-#include <asm/pat.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1371,9 +1370,7 @@ asmlinkage void __init xen_start_kernel(
 
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
-#if 0
 	if (!xen_initial_domain())
-#endif
 		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
 
 	__supported_pte_mask |= _PAGE_IOMAP;
@@ -1433,14 +1430,7 @@ asmlinkage void __init xen_start_kernel(
 	 */
 	acpi_numa = -1;
 #endif
-#ifdef CONFIG_X86_PAT
-	/*
-	 * For right now disable the PAT. We should remove this once
-	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
-	 * (xen/pat: Disable PAT support for now) is reverted.
-	 */
-	pat_enabled = 0;
-#endif
+
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
diff -uNrp linux-3.9.11-200.fc18.x86_64/arch/x86/xen/mmu.c linux-3.9.11-200.PAT.fc18.x86_64/arch/x86/xen/mmu.c
--- linux-3.9.11-200.fc18.x86_64/arch/x86/xen/mmu.c	2013-08-13 22:35:49.404210605 +0200
+++ linux-3.9.11-200.fc18.x86_64/arch/x86/xen/mmu.c	2013-08-13 22:47:19.885598037 +0200
@@ -434,13 +434,13 @@ static pteval_t iomap_pte(pteval_t val)
 static pteval_t xen_pte_val(pte_t pte)
 {
 	pteval_t pteval = pte.pte;
-#if 0
+
 	/* If this is a WC pte, convert back from Xen WC to Linux WC */
 	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
 		WARN_ON(!pat_enabled);
 		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
 	}
-#endif
+
 	if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
 		return pteval;
 
@@ -482,7 +482,7 @@ void xen_set_pat(u64 pat)
 static pte_t xen_make_pte(pteval_t pte)
 {
 	phys_addr_t addr = (pte & PTE_PFN_MASK);
-#if 0
+
 	/* If Linux is trying to set a WC pte, then map to the Xen WC.
 	 * If _PAGE_PAT is set, then it probably means it is really
 	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
@@ -495,7 +495,7 @@ static pte_t xen_make_pte(pteval_t pte)
 		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
 			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
 	}
-#endif
+
 	/*
 	 * Unprivileged domains are allowed to do IOMAPpings for
 	 * PCI passthrough, but not map ISA space.  The ISA

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

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