similar to: [PATCH] Disable PAT support when running under Xen (v1).

Hello, I find a strange behavior. When a machine is slow (or with many debug traces or a qemu vm), a interrupt can occur between the pv_irq_ops initialization and the xen_vcpu[0] initialization. This lead to a problem because some operations in xen_irq_ops use xen_vcpu. I send you a patch to fix that but I''m not quite sure that is the right solution. Regards, Anthoine From

Add pte_flags() to extract the flags from a pte. This is a special case of pte_val() which is only guaranteed to return the pte's flags correctly; the page number may be corrupted or missing. The intent is to allow paravirt implementations to return pte flags without having to do any translation of the page number (most notably, Xen). Signed-off-by: Jeremy Fitzhardinge

Add pte_flags() to extract the flags from a pte. This is a special case of pte_val() which is only guaranteed to return the pte's flags correctly; the page number may be corrupted or missing. The intent is to allow paravirt implementations to return pte flags without having to do any translation of the page number (most notably, Xen). Signed-off-by: Jeremy Fitzhardinge

2011/7/19 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: > CC''ing Tim and xen-devel > > On Mon, 18 Jul 2011, Jiageng Yu wrote: >> 2011/7/16 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: >> > On Fri, 15 Jul 2011, Jiageng Yu wrote: >> >> 2011/7/15 Jiageng Yu <yujiageng734@gmail.com>: >> >> > 2011/7/15

On 8/7/20 4:38 AM, Juergen Gross wrote: > @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) > { > pteval_t ret; > > - if (sizeof(pteval_t) > sizeof(long)) > - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); > - else > - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >

On 8/7/20 4:38 AM, Juergen Gross wrote: > @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) > { > pteval_t ret; > > - if (sizeof(pteval_t) > sizeof(long)) > - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); > - else > - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >

On 8/10/20 12:39 AM, J?rgen Gro? wrote: > On 09.08.20 04:34, Boris Ostrovsky wrote: >> On 8/7/20 4:38 AM, Juergen Gross wrote: >>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) >>> ? { >>> ????? pteval_t ret; >>> ? -??? if (sizeof(pteval_t) > sizeof(long)) >>> -??????? ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val

Hey Jeremy, Please pull from devel/pat (based off your xen/dom0/core tree) which has one patch: Konrad Rzeszutek Wilk (1): xen/pat: make pte_flags(x) a pvops function. which is neccessary for the drivers/gpu/drm/radeon driver to work properly with AGP based cards (which look to be the only ones that try to set WC on pages). Also please pull from devel/kms.fixes-05 (based off your

There are BIOSes that want to map the IO-APIC MMIO region from some ACPI method(s), and there is at least one BIOS flavor that wants to use this mapping to clear an RTE''s mask bit. While we can''t allow the latter, we can permit reads and simply drop write attempts, leveraging the already existing infrastructure introduced for dealing with AMD IOMMUs'' representation as

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 92 +++------------------ arch/x86/include/asm/paravirt_types.h | 21 ----- arch/x86/include/asm/pgtable-3level_types.h | 5 --

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 120 ++------------------ arch/x86/include/asm/paravirt_types.h | 21 ---- arch/x86/include/asm/pgtable-3level_types.h | 5 -

On 09.08.20 04:34, Boris Ostrovsky wrote: > On 8/7/20 4:38 AM, Juergen Gross wrote: >> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) >> { >> pteval_t ret; >> >> - if (sizeof(pteval_t) > sizeof(long)) >> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); >> - else >> - ret = PVOP_CALLEE1(pteval_t,

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the memory address instead of the page id let's us lookup how big the page is and what it's base address is, so that we won't get a page fault within the same page twice anymore. I don't know if I got this right though,

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

A lot of cleanup after removal of 32-bit Xen PV guest support in paravirt code. Changes in V4: - dropped patches 1-3, as already committed - addressed comments to V3 - added new patches 5+6 Changes in V3: - addressed comments to V2 - split patch 1 into 2 patches - new patches 3 and 7 Changes in V2: - rebase to 5.8 kernel - addressed comments to V1 - new patches 3 and 4 Juergen Gross (6):

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine