On Thu, 2025-06-19 at 21:42 +0200, Mathias Krause wrote:
> KVM has a weird behaviour when a guest executes VMCALL on an AMD system
> or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
> exception (#UD) as they are just the wrong instruction for the CPU
> given. But instead of for
On 22.07.25 14:21, Xiaoyao Li wrote:
> On 7/22/2025 7:15 PM, Daniel P. Berrangé wrote:
>> [...]
>>
>> Usually CSPs don't have full control over what their customers
>> are running as a guest. If their customers are running mainstream
>> modern guest OS, CONFIG_STRICT_KERNEL_RWX is pretty likely to
On 22.07.25 12:27, Xiaoyao Li wrote:
> On 7/22/2025 5:21 PM, Mathias Krause wrote:
>> IMHO, there is no valid reason for still having the patching in place as
>> the .text of non-ancient kernel's will be write-protected, making
>> patching attempts fail. And, as they fail with a #PF instead of #UD
On 7/22/2025 7:15 PM, Daniel P. Berrangé wrote:
On Tue, Jul 22, 2025 at 06:27:45PM +0800, Xiaoyao Li wrote:
On 7/22/2025 5:21 PM, Mathias Krause wrote:
On 22.07.25 05:45, Xiaoyao Li wrote:
On 6/20/2025 3:42 AM, Mathias Krause wrote:
KVM has a weird behaviour when a guest executes VMCALL on an
> On 22. Jul 2025, at 13:06, Xiaoyao Li wrote:
>
> On 7/22/2025 6:35 PM, Mohamed Mediouni wrote:
>>> On 22. Jul 2025, at 12:27, Xiaoyao Li wrote:
>>>
>>> On 7/22/2025 5:21 PM, Mathias Krause wrote:
On 22.07.25 05:45, Xiaoyao Li wrote:
> On 6/20/2025 3:42 AM, Mathias Krause wrote:
>>>
On Tue, Jul 22, 2025 at 06:27:45PM +0800, Xiaoyao Li wrote:
> On 7/22/2025 5:21 PM, Mathias Krause wrote:
> > On 22.07.25 05:45, Xiaoyao Li wrote:
> > > On 6/20/2025 3:42 AM, Mathias Krause wrote:
> > > > KVM has a weird behaviour when a guest executes VMCALL on an AMD system
> > > > or VMMCALL on
On 7/22/2025 6:35 PM, Mohamed Mediouni wrote:
On 22. Jul 2025, at 12:27, Xiaoyao Li wrote:
On 7/22/2025 5:21 PM, Mathias Krause wrote:
On 22.07.25 05:45, Xiaoyao Li wrote:
On 6/20/2025 3:42 AM, Mathias Krause wrote:
KVM has a weird behaviour when a guest executes VMCALL on an AMD system
or VM
> On 22. Jul 2025, at 12:27, Xiaoyao Li wrote:
>
> On 7/22/2025 5:21 PM, Mathias Krause wrote:
>> On 22.07.25 05:45, Xiaoyao Li wrote:
>>> On 6/20/2025 3:42 AM, Mathias Krause wrote:
KVM has a weird behaviour when a guest executes VMCALL on an AMD system
or VMMCALL on an Intel CPU. B
On 7/22/2025 5:21 PM, Mathias Krause wrote:
On 22.07.25 05:45, Xiaoyao Li wrote:
On 6/20/2025 3:42 AM, Mathias Krause wrote:
KVM has a weird behaviour when a guest executes VMCALL on an AMD system
or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
exception (#UD) as they are
On 22.07.25 05:45, Xiaoyao Li wrote:
> On 6/20/2025 3:42 AM, Mathias Krause wrote:
>> KVM has a weird behaviour when a guest executes VMCALL on an AMD system
>> or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
>> exception (#UD) as they are just the wrong instruction for the CP
On 6/20/2025 3:42 AM, Mathias Krause wrote:
KVM has a weird behaviour when a guest executes VMCALL on an AMD system
or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
exception (#UD) as they are just the wrong instruction for the CPU
given. But instead of forwarding the excepti
On 19.06.25 21:42, Mathias Krause wrote:
> KVM has a weird behaviour when a guest executes VMCALL on an AMD system
> or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
> exception (#UD) as they are just the wrong instruction for the CPU
> given. But instead of forwarding the exce
KVM has a weird behaviour when a guest executes VMCALL on an AMD system
or VMMCALL on an Intel CPU. Both naturally generate an invalid opcode
exception (#UD) as they are just the wrong instruction for the CPU
given. But instead of forwarding the exception to the guest, KVM tries
to patch the guest
13 matches
Mail list logo
