S RAM.
Signed-off-by: Mathias Krause
---
hw/mc146818rtc.c | 62 -
1 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b91fa8..9f215e0 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818
Am 16.09.2010 18:49, Stefan Weil schrieb:
> The intention of this patch is ok. Loading CMOS with initial data
> is needed. I just want to add two questions / remarks how the
> implementation might be improved.
>
> Are there use cases where having a smaller CMOS size is better?
> For example, when
Am 16.09.2010 19:20 schrieb Anthony Liguori:
> Instead of using FILE, I'd suggest using a BlockDriver to read and write
> the data.
I'll fix that as soon as I figured how to use this interface.
> I think it would be very nice to add write support too so that writes to
> CMOS were persisted across
On 17.09.2010 12:58, Stefan Weil wrote:
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>> Am 16.09.2010 18:49, Stefan Weil schrieb:
>>> Are there use cases where having a smaller CMOS size is better?
>>> For example, when I want to emulate a system with 128 byte CMOS?
&g
Hi Kevin,
On 17.09.2010 12:44, Kevin Wolf wrote:
> Hi Mathias,
>
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>>> Using QEMU's block devices instead of a simple file would be
>>> more consistent with the rest of QEMU and allow reading the
>>> CMOS data
On 17.09.2010 15:27, Anthony Liguori wrote:
> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>
>>> Instead of using FILE, I'd suggest using a BlockDriver to read and write
>>> the data.
>>>
&
On 24.09.2010 14:47, Markus Armbruster wrote:
> Mathias Krause writes:
>
>> On 17.09.2010 15:27, Anthony Liguori wrote:
>>> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>>>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>>>
>>>>> In
the QEMU command line made the bug vanish
(as QEMU then omits adding the random seed setup_data entries) .
[1] https://github.com/qemu/qemu/commit/67f7e426e538
After digging a while I found this thread and it fixes the issue for me,
thereby:
Tested-by: Mathias Krause
Thanks,
Mathias
> [snip]
20316005538.2282772-2-oup...@google.com/
[3] https://lore.kernel.org/kvm/80e1f1d2-2d79-22b7-6665-c00e4fe9c...@redhat.com/
Cc: Oliver Upton
Cc: Sean Christopherson
Cc: Paolo Bonzini
Signed-off-by: Mathias Krause
---
include/system/kvm_int.h | 1 +
qemu-options.hx | 10 ++
targ
el.org/kvm/20250612141637.131314-1-mini...@grsecurity.net/
Fixes: 3563362ddfae ("target/i386: Introduce structures for mmu_translate")
Signed-off-by: Mathias Krause
---
target/i386/tcg/system/excp_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ta
On 12.06.25 16:21, Mathias Krause wrote:
> Commit 3563362ddfae ("target/i386: Introduce structures for mmu_translate")
> accidentally modified CR2 for non-canonical address exceptions while these
> should lead to a #GP / #SS instead -- without changing CR2.
>
> Fix that.
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 fo
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 wron
On 23.07.25 08:54, Xiaoyao Li wrote:
> On 7/23/2025 4:43 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 wron
20316005538.2282772-2-oup...@google.com/
[3] https://lore.kernel.org/kvm/80e1f1d2-2d79-22b7-6665-c00e4fe9c...@redhat.com/
Cc: Oliver Upton
Cc: Sean Christopherson
Cc: Paolo Bonzini
Signed-off-by: Mathias Krause
---
v2:
- rename hypercall_patching_enabled to hypercall_patching (Xiaoyao Li)
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
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 23.07.25 10:50, Xiaoyao Li wrote:
> On 7/23/2025 4:42 PM, Xiaoyao Li wrote:
>> On 7/23/2025 3:53 PM, Mathias Krause wrote:
>>> Bleh, I just noticed that there are KUT tests that actually rely on the
>>> feature[1]. I'll fix these but, looks like, we need to defa
ab.com/kvm-unit-tests/kvm-unit-tests/-/blob/f045ea5627a3/x86/apic.c#L644
[5]
https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/blob/f045ea5627a3/x86/vmexit.c#L36
Cc: Oliver Upton
Cc: Sean Christopherson
Cc: Paolo Bonzini
Cc: Xiaoyao Li
Signed-off-by: Mathias Krause
---
Xiaoyao, I left out your
On 23.07.25 11:26, David Woodhouse wrote:
> 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 th
On 04.08.25 05:32, Xiaoyao Li wrote:
> On 8/1/2025 9:12 PM, Mathias Krause wrote:
>> [...]
>>
>> For regular operating systems, however, the patching wouldn't be needed,
>> nor work at all. If it would, these systrems would be vulnerable to
>> memory corrupt
21 matches
Mail list logo
