Let's add s390_get_memory_limit(), to query what has been successfully
set via s390_set_memory_limit(). Allow setting the limit only once.
We'll remember the limit in the machine state. Move
s390_set_memory_limit() to machine code, merging it into
set_memory_limit(), because this really is a machi
Let's remember the value (successfully) set via s390_set_max_pagesize().
This will be helpful to reject hotplugged memory devices that would exceed
this initially set page size.
Handle it just like how we handle s390_get_memory_limit(), storing it in
the machine, and moving the handling to machine
Let's add our virtio-mem-ccw proxy device and wire it up. We should
be supporting everything (e.g., device unplug, "dynamic-memslots") that
we already support for the virtio-pci variant.
With a Linux guest that supports virtio-mem (and has automatic memory
onlining properly configured) the followi
Let's generalize, abstracting the virtio bits. diag500 is now a generic
hypercall to handle QEMU/KVM specific things. Explicitly specify all
already defined subcodes, including legacy ones (so we know what we can
use for new hypercalls).
Move the PGM_SPECIFICATION injection into the renamed functi
A guest OS that supports memory hotplug / memory devices must during
boot be aware of the maximum possible physical memory address that it might
have to handle at a later stage during its runtime.
For example, the maximum possible memory address might be required to
prepare the kernel virtual addr
Let's make it clearer that we are talking about general
QEMU/KVM-specific hypercalls.
Message-ID: <20241219144115.2820241-5-da...@redhat.com>
Acked-by: Michael S. Tsirkin
Reviewed-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
hw/s390x/meson.build | 2 +-
hw
Let's prepare our address space for memory devices if enabled via
"maxmem" and if we have CONFIG_MEM_DEVICE enabled at all. Note that
CONFIG_MEM_DEVICE will be selected automatically once we add support
for devices.
Just like on other architectures, the region container for memory devices
is place
With memory devices, we will have storage keys for memory that
exceeds the initial ram size.
The TODO already states that current handling is subopimal,
but we won't worry about improving that (TCG-only) thing for now.
Message-ID: <20241219144115.2820241-10-da...@redhat.com>
Acked-by: Michael S.
We recently converted from the LegacyReset to the new reset framework
in commit c009a311e939 ("virtio-mem: Use new Resettable framework instead
of LegacyReset") to be able to use the ResetType to filter out wakeup
resets.
However, this change had an undesired implications: as we override the
Reset
Let's avoid checking for the maxram_size, and instead rely on the memory
limit determined in s390_memory_init(), that might be larger than
maxram_size, for example due to alignment purposes.
This check now correctly mimics what the kernel will check in
kvm_s390_pv_set_aside(), whereby a VM <= 2 Gi
With memory devices, we will have storage attributes for memory that
exceeds the initial ram size. Further, we can easily have memory holes,
for which there (currently) are no storage attributes.
In particular, with memory holes, KVM_S390_SET_CMMA_BITS will fail to set
some storage attributes.
So
KVM is not happy when starting a VM with weird RAM sizes:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
failed, slot=0, start=0x0, size=0x244000: Invalid argument
kvm_set_phys_mem: error registering slot: I
Hi,
this is the updated pull request from 2024-12-18; gitlab-ci seems to
be happy with it (container,build,avocado tests).
The following changes since commit 9863d46a5a25bfff7d2195ad5e3127ab3bae0a2b:
Merge tag 'pull-loongarch-20241219' of https://gitlab.com/bibo-mao/qemu into
staging (2024-12
Let's implement support for abstract virtio based memory devices, using
the virtio-pci implementation as an orientation. Wire them up in the
machine hotplug handler, taking care of s390x page size limitations.
As we neither support virtio-mem or virtio-pmem yet, the code is
effectively unused. We'
Nowadays, we only have a single machine type in QEMU, everything is based
on virtio-ccw and the traditional virtio machine does no longer exist. No
need to dynamically register diag500 handlers. Move the two existing
handlers into s390-virtio-hcall.c.
Message-ID: <20241219144115.2820241-3-da...@re
Nowadays, it feels more natural to have that code located in
s390_memory_init(), where we also have direct access to the machine
object.
While at it, use the actual RAM size, not the maximum RAM size which
cannot currently be reached without support for any memory devices.
Consequently update s390
Am 20. Dezember 2024 10:42:09 UTC schrieb Paolo Bonzini :
>
>
>On Thu, Dec 19, 2024 at 12:22 PM Paolo Bonzini wrote:
>>
>> On 12/19/24 10:53, Bernhard Beschow wrote:
>> >
>> >
>> > Am 4. November 2024 17:26:51 UTC schrieb Paolo Bonzini
>> > :
>> >> Adjust the integration test to compile with
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/10.0 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/10.0 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/10.0 for any
user-visible changes.
signature.asc
Description: PGP signature
Convert all targets simultaneously, as the gen_intermediate_code
function disappears from the target. While there are possible
workarounds, they're larger than simply performing the conversion.
Signed-off-by: Richard Henderson
---
accel/tcg/cpu-exec.c | 8 +---
accel/tcg/transl
On 20.12.24 23:22, vringar wrote:
On 20/12/2024 21:59, David Hildenbrand wrote:
Good point, I suspect that will be problematic.
Looking at flatview_write_continue I see no early exit, so maybe it
would still try to get through everything and work as we are hoping,
but that's why I'd like to wr
On Fri, 20 Dec 2024 11:52:51 +,
Kashyap Chamarthy wrote:
>
> On Thu, Dec 19, 2024 at 03:41:56PM +, Marc Zyngier wrote:
> > On Thu, 19 Dec 2024 15:07:25 +,
> > Kashyap Chamarthy wrote:
> > >
> > > On Thu, Dec 19, 2024 at 12:26:29PM +, Marc Zyngier wrote:
> > > > On Thu, 19 Dec 20
On Thu, 19 Dec 2024 17:51:44 +,
Daniel "P. Berrangé" wrote:
>
> On Thu, Dec 19, 2024 at 03:41:56PM +, Marc Zyngier wrote:
> > On Thu, 19 Dec 2024 15:07:25 +,
> > Kashyap Chamarthy wrote:
> > >
> > > On Thu, Dec 19, 2024 at 12:26:29PM +, Marc Zyngier wrote:
> > > > On Thu, 19 Dec
On 2024/12/21 17:11, Nicholas Piggin wrote:
On Sat Dec 21, 2024 at 2:26 PM AEST, Akihiko Odaki wrote:
On 2024/12/21 13:14, Nicholas Piggin wrote:
On Thu Dec 19, 2024 at 6:53 PM AEST, Akihiko Odaki wrote:
On 2024/12/18 16:42, Nicholas Piggin wrote:
The e1000e and igb tests don't clear the msix
On Sat Dec 21, 2024 at 2:26 PM AEST, Akihiko Odaki wrote:
> On 2024/12/21 13:14, Nicholas Piggin wrote:
> > On Thu Dec 19, 2024 at 6:53 PM AEST, Akihiko Odaki wrote:
> >> On 2024/12/18 16:42, Nicholas Piggin wrote:
> >>> The e1000e and igb tests don't clear the msix pending bit after waiting
> >>>
26 matches
Mail list logo
