On 9/25/24 02:28, Juergen Gross wrote:
> On 16.09.24 10:44, Juergen Gross wrote:
>> x86 maintainers,
>>
>> are you going to pick this series up, or should I take it via the
>> Xen tree?
>
> I take the silence as a "its okay to go via the Xen tree".
Or, "most of us were traveling last week and in
On 8/23/24 12:36, Jason Andryuk wrote:
> The PVH entry point will need an additional set of prebuild page tables.
> Move the macros and defines to pgtable_64.h, so they can be re-used.
>
> Signed-off-by: Jason Andryuk
> Reviewed-by: Juergen Gross
Acked-by: Dave Hansen
On 10/12/23 13:12, Uros Bizjak wrote:
> The last patch introduces (%rip) suffix and uses it for x86_64 target,
> resulting in a small code size decrease: text data bss dec hex filename
> 25510677 4386685 808388 30705750 1d48856 vmlinux-new.o 25510629 4386685
> 808388 30705702 1d48826 vmlinux-old.o
On 6/9/23 08:22, Konrad Rzeszutek Wilk wrote:
> Dave, are you OK with the change in where the reserve call is made?
The move makes logical sense. I'm not 100% confident it won't regress
anything, but the blast radius should be limited to iSCSI. But, yeah,
I'm OK with it.
On 6/5/23 03:28, Ross Lagerwall wrote:
> The result of these changes is that it is possible to boot a diskless
> Xen + Dom0 running off an iSCSI disk whereas previously it would fail to
> find the iBFT and consequently, the iSCSI root disk.
Acked-by: Dave Hansen # for x86
The work in t
On 5/15/23 01:19, Hou Wenlong wrote:
> This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
> fixmap area to be movable and relocated with the kernel image in the
> x86/PIE patchset [0]. This enables the kernel image to be relocated in
> the top 512G of the address space.
What pro
On 6/1/23 09:57, Dave Hansen wrote:
> On 5/30/23 08:01, Ross Lagerwall wrote:
>> Since firmware doesn't indicate the iBFT in the E820, add a reserved
>> region so that it gets identity mapped when running as Dom 0 so that it
>> is possible to search for it. Move the c
On 5/30/23 08:01, Ross Lagerwall wrote:
> Since firmware doesn't indicate the iBFT in the E820, add a reserved
> region so that it gets identity mapped when running as Dom 0 so that it
> is possible to search for it. Move the call to reserve_ibft_region()
> later so that it is called after the Xen
On 5/24/23 08:47, Juergen Gross wrote:
>> Any other feedback on this one? This is definitely a bug but I
>> understand that
>> there might be different ways to fix it.
>
> I'd be happy to take the patch via the Xen tree, but I think x86
> maintainers should at least ack that.
Ack.
Works for me.
On 5/16/23 12:35, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This addresses all x86 specific prototype warnings. The majority of the
> patches should be straightforward, either adding an #include statement
> to get the right header, or ensuring that an unused global function is
> left out of
On 5/16/23 12:35, Arnd Bergmann wrote:
> The ones that are a bit awkward are those that just add a prototype to
> shut up the warning, but the prototypes are never used for calling the
> function because the only caller is in assembler code. I tried to come up
> with other ways to shut up the compi
On 5/16/23 12:35, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
> 'xen_start_kernel' [-Werror=missing-prototypes]
> arch/x86/xen/irq.c:22:14: error: no previous prototype for
> 'xen_force_evtchn_callback' [-Werror=missing-pr
On 12/2/22 04:24, Roger Pau Monné wrote:
> On the implementation side, is the proposed approach acceptable?
> Mostly asking because it adds Xen conditionals to otherwise generic
> ACPI code.
That's a good Rafael question.
But, how do other places in the ACPI code handle things like this?
On 11/30/22 07:53, Roger Pau Monné wrote:
> On Tue, Nov 29, 2022 at 09:43:53AM -0800, Dave Hansen wrote:
>> On 11/21/22 02:21, Roger Pau Monne wrote:
>>> When running as a Xen dom0 the number of CPUs available to Linux can
>>> be different from the number of CPUs pr
On 11/21/22 02:21, Roger Pau Monne wrote:
> When running as a Xen dom0 the number of CPUs available to Linux can
> be different from the number of CPUs present on the system, but in
> order to properly fetch processor performance related data _PDC must
> be executed on all the physical CPUs online
On 11/10/22 07:45, Ross Philipson wrote:
> dt = early_memremap(initial_dtb, map_len);
> + if (!dt) {
> + pr_warn("failed to memremap initial dtb\n");
> + return;
> + }
Are all of these new pr_warn/err()'s really adding much value? They all
look pretty generic
On 11/4/22 00:27, Juergen Gross wrote:
> Convert the remaining cases of static_cpu_has(X86_FEATURE_XENPV) and
> boot_cpu_has(X86_FEATURE_XENPV) to use cpu_feature_enabled(), allowing
> more efficient code in case the kernel is configured without
> CONFIG_XEN_PV.
As with the rest:
Ac
On 11/4/22 00:27, Juergen Gross wrote:
> Testing of X86_FEATURE_XENPV in setup_cpu_entry_area() can be removed,
> as this code path is 32-bit only, and Xen PV guests are not supporting
> 32-bit mode.
Acked-by: Dave Hansen
On 11/4/22 00:26, Juergen Gross wrote:
> Testing for Xen PV guest mode in a 32-bit only code section can be
> dropped, as Xen PV guests are supported in 64-bit mode only.
>
> While at it switch from boot_cpu_has() to cpu_feature_enabled() in the
> 64-bit part of the code.
Acked-by: Dave Hansen
onfig. It's not just some random
edict where we pronounced 32-bit PV guests unsupported.
Otherwise:
Acked-by: Dave Hansen
On 11/4/22 00:26, Juergen Gross wrote:
> Add X86_FEATURE_XENPV to the features handled specially in
> disabled-features.h.
Acked-by: Dave Hansen
On 6/20/22 03:41, Juergen Gross wrote:
>> But I'm only guessing - this needs a *lot* more elaboration and
>> explanation why exactly this is needed.
>
> I will correct the code and update the commit message.
It would also be great to cover the end-user-visible impact of the bug
and the fix. It _
On 11/19/21 7:39 AM, Juergen Gross wrote:
> The prototype of mem_map_via_hcall() is missing in its header, so add
> it.
>
> Reported-by: kernel test robot
> Fixes: a43fb7da53007e67ad ("xen/pvh: Move Xen code for getting mem map via
> hcall out of common file")
> Signed-off-by: Juergen Gross
$
On 11/12/21 12:09 PM, Lucas De Marchi wrote:
> The intention was to merge this through the tip tree. Although now I'm
> not sure. Options:
>
> 1) take the first patch through the drm-intel tree and apply the
> second patch later
> 2) take everything through the drm tree
> 3) tak
to optimize in non-virtualization
> environment.
>From an x86/mm perspective:
Acked-by: Dave Hansen
A tiny nit:
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 0bb4d9ca7a55..b3683083208a 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/
On 8/5/21 7:23 AM, Peter Zijlstra wrote:
> This is assuming any of this is actually performance critical, based off
> of this using static_call() to begin with.
This code is not performance critical.
I think I sent folks off on a wild goose chase when I asked that we make
an effort to optimize co
On 8/4/21 11:44 AM, Tianyu Lan wrote:
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool
> enc);
> +DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
> +
> #define CPA_FLUSHTLB 1
> #define CPA_ARRAY 2
> #define CPA_PAGES_ARRAY 4
> @@ -1981,6 +1985,11 @@ in
On 7/29/21 8:02 AM, Tianyu Lan wrote:
>>
>
> There is x86_hyper_type to identify hypervisor type and we may check
> this variable after checking X86_FEATURE_HYPERVISOR.
>
> static inline bool hv_is_isolation_supported(void)
> {
> if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
> ret
On 7/29/21 6:01 AM, Tianyu Lan wrote:
> On 7/29/2021 1:06 AM, Dave Hansen wrote:
>> On 7/28/21 7:52 AM, Tianyu Lan wrote:
>>> @@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long
>>> addr, int numpages, bool enc)
>>> int ret;
>>>
On 7/28/21 7:52 AM, Tianyu Lan wrote:
> @@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long addr, int
> numpages, bool enc)
> int ret;
>
> /* Nothing to do if memory encryption is not active */
> - if (!mem_encrypt_active())
> + if (hv_is_isolation_supported()
On 7/28/21 7:52 AM, Tianyu Lan wrote:
> @@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long addr, int
> numpages, bool enc)
> int ret;
>
> /* Nothing to do if memory encryption is not active */
> - if (!mem_encrypt_active())
> + if (hv_is_isolation_supported()
On 7/7/21 8:46 AM, Tianyu Lan wrote:
> @@ -598,7 +599,7 @@ void arch_kexec_unprotect_crashkres(void)
> */
> int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
> {
> - if (sev_active())
> + if (sev_active() || hv_is_isolation_supported())
> return 0
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
On 4/30/20 8:52 AM, David Hildenbrand wrote:
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
>
> I'd love to get Dan's, Dave's and M
* MHP_NO_FIRMWARE_MEMMAP ensures that future
* kexec'd kernels will not treat this as RAM.
*/
Not a biggie, though.
Acked-by: Dave Hansen
ut how the
separating out "is_lazy" compares to the "check before setting"
optimization. But, they're both sane enough on their own that I'm not
too worried.
I had some nits that I hope get covered in later revisions, if sent.
But, overall looks fine. F
hen Hemminger
> Cc: Sasha Levin
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> Cc: Juergen Gross
> Cc: Paolo Bonzini
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: Boris Ostrovsky
> Cc:
On 6/25/19 7:35 PM, Nadav Amit wrote:
>>> const struct flush_tlb_info *f = info;
>>> + enum tlb_flush_reason reason;
>>> +
>>> + reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
>>
>> Should we just add the "reason" to flush_tlb_info? It's OK-ish to imply
>> it like
On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
> It is more than just memmaps (e.g. forking udev process doing memory
> onlining also needs memory) but yes, the main idea is to make the
> onlining synchronous with hotplug.
That's a good theoretical concern.
But, is it a problem we need to solve
> How should a policy in user space look like when new memory gets added
> - on s390x? Not onlining paravirtualized memory is very wrong.
Because we're going to balloon it away in a moment anyway?
We have auto-onlining. Why isn't that being used on s390?
> So the type of memory is very importa
It's really nice if these kinds of things are broken up. First, replace
the old want_memblock parameter, then add the parameter to the
__add_page() calls.
> +/*
> + * NONE: No memory block is to be created (e.g. device memory).
> + * NORMAL: Memory block that represents normal (boot or hotp
41 matches
Mail list logo
