On April 26, 2025 11:55:50 AM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> Dropping CMOV would mean dropping P5 support.
>
>Yeah, I think we should make the cutoff at the 686 level. Is there any
>strong reason not to do that? Stable kernels will still exist for a
>very long time for
On April 26, 2025 12:55:13 PM PDT, Linus Torvalds
wrote:
>On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
> wrote:
>>
>> (And yes, one use in a x86 header file that is pretty questionable
>> too: I think the reason for the cmov is actually i486-only behavior
>> and we could probably unify the 32-bit
On April 26, 2025 12:55:13 PM PDT, Linus Torvalds
wrote:
>On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
> wrote:
>>
>> (And yes, one use in a x86 header file that is pretty questionable
>> too: I think the reason for the cmov is actually i486-only behavior
>> and we could probably unify the 32-bit
On Sat, Apr 26, 2025, at 11:08, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
>
> While the simplification is nice on its face, this looks messy:
>
>>
>> config X86_PAE
>> bool "PAE (Physical Address Extension) Support"
>> -depends on X86_32 && X86_HAVE_PAE
>> +depends on X86_32 && X
From: Denis Mukhin
Move console_locks_busted handling inside conring_puts() to remove
tasklet code duplication.
Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
---
Changes v1->v2:
- added Stefano's R-b
---
xen/drivers/char/console.c | 29 ++---
1 file chang
On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote:
>
> Right. With the current set of features, CMOV is almost the
> same as 686. My reasoning was that support for CMOV has a
> very clear definition, with the instruction either being
> available or not.
Yeah, I don't think there's any reason to m
On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
wrote:
>
> (And yes, one use in a x86 header file that is pretty questionable
> too: I think the reason for the cmov is actually i486-only behavior
> and we could probably unify the 32-bit and 64-bit implementation)
Actually, what we *should* do is to
From: Denis Mukhin
Introduce conring_flush() to ensure all messages kept in the internal
console ring are sent to all physical consoles (serial, VGA (x86))
after their initialization is completed.
Resolves: https://gitlab.com/xen-project/xen/-/issues/184
Signed-off-by: Denis Mukhin
---
Changes
* Arnd Bergmann wrote:
> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
> Cyrix MII) but also newer embedded Via C3, Geode GX and
> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX (2005)
> and Vortex86DX3/EX2 (2015!) have CMOV, but the old ones were sold
* H. Peter Anvin wrote:
> Dropping CMOV would mean dropping P5 support.
Yeah, I think we should make the cutoff at the 686 level. Is there any
strong reason not to do that? Stable kernels will still exist for a
very long time for ancient boards.
Ingo
From: Denis Mukhin
guest_console_write() duplicates the code from __putstr(), eliminate code
duplication.
Introduce console_puts() for writing a buffer to console devices.
Also, introduce internal console flags to control which console devices
should be used.
Signed-off-by: Denis Mukhin
---
C
The patch series introduces a few cleanups aimed at reducing code duplication
in the console driver.
Originally, patches 2 and 3 were part of NS16550 emulator v3 series [1].
Patch 1 removes some code duplication for logging via conring facility.
Patch 2 (see [2]) removes code duplication between
On Sat, 26 Apr 2025, Xin Li wrote:
> On 4/25/2025 8:45 AM, Ilpo Järvinen wrote:
> > To me this looks really a random set of source files, maybe it helped some
> > build success but it's hard for me to review this because there are still
> > cases that depend on indirect include chains.
> >
> > Co
On April 26, 2025 2:08:17 AM PDT, Ingo Molnar wrote:
>
>* Arnd Bergmann wrote:
>
>> From: Arnd Bergmann
>>
>> With cx8 and tsc being mandatory features, the only important
>> architectural features are now cmov and pae.
>>
>> Change the large list of target CPUs to no longer pick the instructi
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With cx8 and tsc being mandatory features, the only important
> architectural features are now cmov and pae.
>
> Change the large list of target CPUs to no longer pick the instruction set
> itself but only the mtune= optimization level and in-
From: Denis Mukhin
Use vmread() instead of __vmread() as per suggestion in [1] everywhere in the
VT-x code.
Remove __vmread() and update ECLAIR configuration.
[1]
https://lore.kernel.org/xen-devel/0d01646b-83e3-4a02-b365-d149d2664...@citrix.com/
Signed-off-by: Denis Mukhin
---
docs/misra/fu
From: Denis Mukhin
The current implementation of __vmread() returns the result via pointer
argument which leads to excess code in some places.
Introduce a new vmread() function as suggested in [1].
[1]
https://lore.kernel.org/xen-devel/c452a1d7-4a57-4c5f-8a83-36a74ff22...@citrix.com/
Signed-o
On 4/25/2025 3:08 AM, Jürgen Groß wrote:
Can you please remove the two "else" instances above? With directly
returning
form the "if" clause they are no longer needed.
I thought about it but forgot to do it later.
With that you can add my:
Reviewed-by: Juergen Gross
Thanks a lot!
From: Denis Mukhin
Convert the DR7 type to `unsigned int` and fix the accesses where necessary.
[1]
https://lore.kernel.org/xen-devel/0d01646b-83e3-4a02-b365-d149d2664...@citrix.com/
Signed-off-by: Denis Mukhin
---
xen/arch/x86/hvm/vmx/vmx.c| 2 +-
xen/arch/x86/include/asm/domain.h |
The patch series reworks __vmread() by introducing a new cleaner API.
Patch 1 introduces a new vmread() call which will be a replacement for
__vmcall().
Patch 2 updates the type of arch_vcpu->dr7 field.
Patch 3 replaces __vmread() with vmread().
Link to v3:
https://lore.kernel.org/xen-devel/2025
On 4/25/2025 8:45 AM, Ilpo Järvinen wrote:
To me this looks really a random set of source files, maybe it helped some
build success but it's hard for me to review this because there are still
cases that depend on indirect include chains.
Could you just look into solving all missing msr.h include
21 matches
Mail list logo
