On Wed, 2024-10-02 at 13:33 +0200, Igor Mammedov wrote:
>
> It's interesting as an experiment, to prove that Windows is riddled with bugs.
> (well, and it could serve as starting point to report issue to MS)
> But I'd rather Microsoft fix bugs on their side, instead of putting hacks in
> QEMU.
Ab
nction with 'deliver_now==true'. If an IOMMU lookup *still*
fails, that's when the IOMMU will actually raise a fault.
That function allows us to collect all the various MSI format nonsense
in *once* place and handle it cleanly, converting to the KVM X2APIC MSI
format which both KV
On 30.09.24 23:49, Halil Pasic wrote:
On Fri, 27 Sep 2024 20:29:19 +0200
David Hildenbrand wrote:
On 27.09.24 20:20, Halil Pasic wrote:
On Wed, 11 Sep 2024 21:09:27 +0200
David Hildenbrand wrote:
Anyway, if we want to proceed with the gitlab project, would it make
sense to create an
r = qdict_haskey(qdict, "virt") ? &filter_addr : NULL;
> +
I'm a bit confused about the format of the parameter you're trying to use;
can you add an example in the commit message please.
> env = mon_get_cpu_env(mon);
> if (!env) {
> moni
* Peter Xu (pet...@redhat.com) wrote:
> The QMP command was added in 671326201d ("migration: Introduce interface
> query-migrationthreads", v8.0). Add the HMP version of it.
>
> Cc: Markus Armbruster
> Cc: Dr. David Alan Gilbert
> Signed-off-by: Peter Xu
&g
* Peter Xu (pet...@redhat.com) wrote:
> On Thu, Sep 19, 2024 at 02:46:25PM +0100, d...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Use the uffd_copy_page, uffd_zero_page and uffd_wakeup helpers
> > rather than calling ioctl ourselves.
>
On Sat, 2024-09-28 at 15:59 +0100, David Woodhouse wrote:
> On Tue, 2024-07-02 at 05:17 +, Sandesh Patel wrote:
> >
> > The error is due to invalid MSIX routing entry passed to KVM.
> >
> > The VM boots fine if we attach a vIOMMU but adding a vIOMMU can
&
On 30.09.24 13:37, Claudio Imbrenda wrote:
On Mon, 30 Sep 2024 13:15:52 +0200
Christian Borntraeger wrote:
Am 24.09.24 um 22:17 schrieb David Hildenbrand:
On 24.09.24 18:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:58 +0200, David Hildenbrand wrote:
We actually want to check
))
return -EOPNOTSUPP;
So 500+4 should probably not cause any harm apart from branch prediction
going wrong the first 2 or 3 notifies.
Right, it's very unlikely to be noticeable at all.
Thanks for the feedback!
--
Cheers,
David / dhildenb
On Tue, 2024-07-02 at 05:17 +, Sandesh Patel wrote:
>
> The error is due to invalid MSIX routing entry passed to KVM.
>
> The VM boots fine if we attach a vIOMMU but adding a vIOMMU can
> potentially result in IO performance loss in guest.
> I was interested to know if someone could boot a la
ould make DIAG500_STORAGE_LIMIT
8 or 16 instead of 4. Again nothing important, just an idea.
I don't see a reason to do that, but in the end I don't care as long as
people let me know what to do instead.
Thanks for taking a look!
--
Cheers,
David / dhildenb
On 27.09.24 20:20, Halil Pasic wrote:
On Wed, 11 Sep 2024 21:09:27 +0200
David Hildenbrand wrote:
Anyway, if we want to proceed with the gitlab project, would it make
sense to create an org for it, so that it doesn't look like David's
personal project?
Frankly, I would pre
On Thu, 2024-09-26 at 11:22 +0200, Paolo Abeni wrote:
>
> Please have a better run at checkpatch before your next submission,
> there are still a few ones - most relevant white-space damage.
Oops, apparently I missed one. Sorry about that.
I'll also add a MAINTAINERS entry, just to make checkpa
On 10.09.24 19:58, David Hildenbrand wrote:
Let's add a way to return the value (successfully) set via
s390_set_max_pagesize() previously. This will be helpful to reject
hotplugged memory devices that would exceed this initially set page size.
Signed-off-by: David Hildenbrand
---
I'
On 24.09.24 22:17, David Hildenbrand wrote:
On 24.09.24 18:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:58 +0200, David Hildenbrand wrote:
We actually want to check the available RAM, not the maximum RAM size.
Signed-off-by: David Hildenbrand
Reviewed-by: Nina Schoetterl
5596-1-da...@redhat.com
--
Cheers,
David / dhildenb
On 24.09.24 18:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:58 +0200, David Hildenbrand wrote:
We actually want to check the available RAM, not the maximum RAM size.
Signed-off-by: David Hildenbrand
Reviewed-by: Nina Schoetterl-Glausch
Nit below.
---
target/s390x/kvm/pv.c
virtio/PCI
people can review.
--
Cheers,
David / dhildenb
use the
ResetType instead.
Message-ID: <20240904103722.946194-2-jmar...@redhat.com>
Reviewed-by: David Hildenbrand
Reviewed-by: Peter Maydell
Signed-off-by: Juraj Marcin
Signed-off-by: David Hildenbrand
---
hw/arm/aspeed.c| 4 ++--
hw/arm/mps2-tz.c | 4 ++--
h
.
Message-ID: <20240906101658.514470-1-pbonz...@redhat.com>
Reported-by: Michael Tokarev
Reviewed-by: David Hildenbrand
Signed-off-by: Paolo Bonzini
Signed-off-by: David Hildenbrand
---
hw/virtio/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/virtio/Kconfi
methods in VirtIOMEMClass
to use the new Resettable framework and replaces
qemu_[un]register_reset() calls with qemu_[un]register_resettable().
Message-ID: <20240904103722.946194-4-jmar...@redhat.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Juraj Marcin
Signed-off-by: David Hildenbrand
-
From: Juraj Marcin
Some devices need to distinguish cold start reset from waking up from a
suspended state. This patch adds new value to the enum, and updates the
i386 wakeup method to use this new reset type.
Message-ID: <20240904103722.946194-3-jmar...@redhat.com>
Reviewed-by:
mar...@redhat.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Juraj Marcin
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 10 ++
hw/virtio/virtio-qmp.c | 3 +++
2 files changed, 13 insertions(+)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index 484d
Hi,
due to reset changes this contains a bit of churn that touches various
architectures, but it's all fairly minimal and straight-forward.
The following changes since commit 01dc65a3bc262ab1bec8fe89775e9bbfa627becb:
Merge tag 'pull-target-arm-20240919' of
https://git.linaro.org/people/pmayde
mplify the code for merge and dump properties")
Reported-by: Zhenyu Zhang
Tested-by: Zhenyu Zhang
Signed-off-by: Gavin Shan
Signed-off-by: David Hildenbrand
---
backends/hostmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/backends/hostmem.c b/backends/hostmem.c
in
On 23.09.24 17:36, Thomas Huth wrote:
On 23/09/2024 11.19, David Hildenbrand wrote:
On 10.09.24 19:57, David Hildenbrand wrote:
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
in general,
for far out benefits?
I.e. memory_limit could be a machine property instead.
Yes, I'll rework that code to simply store it in the machine, moving
that code out of cpu-sysemu.c int s390-virtio-ccw.c.
Same for patch #12, thanks!
--
Cheers,
David / dhildenb
On 10.09.24 19:57, David Hildenbrand wrote:
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
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
* Bernhard Beschow (shen...@gmail.com) wrote:
>
>
> Am 18. September 2024 00:51:32 UTC schrieb d...@treblig.org:
> >From: "Dr. David Alan Gilbert"
> >
> >mch_mcfg_base has been unused since it was added by
> > 6f1426ab0f ("ich9: APIs
; Jag
>
> > On Sep 18, 2024, at 1:00 PM, Dr. David Alan Gilbert
> > wrote:
> >
> > Hi Jag,
> > One of my scripts noticed that 'remote_iohub_finalize' in
> > hw/remote/iohub.c is unused; before I go and delete it as deadcode,
> > is that actu
* d...@treblig.org (d...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> qemu_clock_get_main_loop_timerlist has been unused since it was
> originally added in
> ff83c66ecc ("aio / timers: Split QEMUClock into QEMUClock and
> QEMUTimerList")
* Fabiano Rosas (faro...@suse.de) wrote:
> Markus Armbruster writes:
>
> > Peter Xu writes:
> >
> >> On Wed, Sep 18, 2024 at 07:52:56AM +0200, Markus Armbruster wrote:
> >>> d...@treblig.org writes:
> >>>
> >>> > From: "
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Sep 19, 2024 at 01:00:34AM +0100, d...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > qio_channel_socket_dgram_async has been unused since it was originally
> > added in 2015.
> &
I'd expect we'd need to add something to the ACPI
specification to enable this.
Virtio-mem
--
The design goals of virtio-mem [1] mean that it is not 'directly' applicable
to this case, but could perhaps be adapted with the addition of meta data
and DAX + guaranteed rem
ange
to be backported to stable branches.
Cc: qemu-stable
Reported-by: Zhiyi Guo
Tested-by: Zhiyi Guo
Signed-off-by: Peter Xu
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
Hi Jag,
One of my scripts noticed that 'remote_iohub_finalize' in
hw/remote/iohub.c is unused; before I go and delete it as deadcode,
is that actually just a missing call somewhere?
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Al
On Tue, 2024-09-03 at 15:56 +0200, Paolo Abeni wrote:
> I'm sorry for the late feedback.
No problem. I've addressed it all apart from the uint64_t part. I'll
concede the pre-C99 nonsense where it matches existing code, but we've
always also allowed code in the kernel to use the proper C language
t
ssues/2576
Can you take a look and send a fix?
--
Cheers,
David / dhildenb
On 16.09.24 15:20, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:58 +0200, David Hildenbrand wrote:
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.
Signed-off-by: David Hildenbrand
Rev
On 17.09.24 12:50, David Hildenbrand wrote:
On 17.09.24 12:45, David Hildenbrand wrote:
On 12.09.24 15:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:57 +0200, David Hildenbrand wrote:
Let's generalize, abstracting the virtio bits. diag500 is now a generic
hypercall to h
On 17.09.24 12:45, David Hildenbrand wrote:
On 12.09.24 15:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:57 +0200, David Hildenbrand wrote:
Let's generalize, abstracting the virtio bits. diag500 is now a generic
hypercall to handle QEMU/KVM specific things. Explicitly specif
On 12.09.24 15:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:57 +0200, David Hildenbrand wrote:
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 l
hatssoever
and map whatever you want in there.
Likely you would need a distinct RAMBlock/RAM memory region per mmap(),
and would end up mmaping implicitly via qemu_ram_mmap().
Then, your shared region would simply be an empty container into which
you map these RAM memory regions.
--
Cheers,
David / dhildenb
void *ptr = memory_region_get_ram_ptr(&backend->mr);
uint64_t sz = memory_region_size(&backend->mr);
Thanks, queued to
https://github.com/davidhildenbrand/qemu.git mem-next
--
Cheers,
David / dhildenb
overd from the old one.
If the backend file is MAP_SHARED, we can copy the valid data into the
Thank you David for this first reaction on this proposal.
How are you dealing with other consumers of the shared memory,
such as vhost-user processes,
In the current proposal, I don't deal w
I had that in mind as well, I can move the project.
In any case, while I'm happy to stay on, I'm not that
involved with s390 anymore, and it might make sense to add more people
to it.
Indeed!
--
Cheers,
David / dhildenb
On 11.09.24 14:46, Thomas Huth wrote:
On 11/09/2024 14.38, David Hildenbrand wrote:
On 11.09.24 13:28, Janosch Frank wrote:
On 9/10/24 7:57 PM, David Hildenbrand wrote:
KVM is not happy when starting a VM with weird RAM sizes:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
On 11.09.24 13:28, Janosch Frank wrote:
On 9/10/24 7:57 PM, David Hildenbrand wrote:
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
On 11.09.24 13:49, Janosch Frank wrote:
On 9/10/24 7:57 PM, David Hildenbrand wrote:
This series introduces a new diag(500) "STORAGE LIMIT" subcode that will
be documented at [2] once this+kernel part go upstream.
Why not in Documentation/virt/kvm/s390/?
s390-diag.rst is very simil
On 10.09.24 20:33, Michael S. Tsirkin wrote:
On Tue, Sep 10, 2024 at 07:57:55PM +0200, David Hildenbrand wrote:
This series is based on:
[PATCH v2] virtio: kconfig: memory devices are PCI only [1]
I finally found the time (IOW forced myself) to finish virtio-mem
support on s390x. The last
On 10.09.24 20:26, Michael S. Tsirkin wrote:
On Tue, Sep 10, 2024 at 06:34:33PM +0200, David Hildenbrand wrote:
If the config directory in sysfs does not exist at all, we are dealing
with a system that does not support THPs. Simply use 1 MiB block size
then, instead of warning "Could not d
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.
Signed-off-by: David Hildenbrand
---
target/s390x/cpu-sysemu.c | 19 +--
target/s390x/cpu.h| 1 +
2 files changed, 18 inser
e, and the remaining
ram_size users only care about initial RAM:
* hw/s390x/ipl.c
* hw/s390x/s390-hypercall.c
* hw/s390x/sclp.c
* target/s390x/kvm/pv.c
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-virtio-ccw.c | 25 +++--
hw/s390x/sclp.c| 6 +-
2
hat the virtio-mem driver in Linux will supports 1 MiB (pageblock)
granularity.
Note that we won't wire up virtio-mem-pci (should currently be
impossible due to lack of support for MSI-X), but we'll add a safety net
to reject plugging them.
Signed-off-by: David Hildenbrand
---
MAINT
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.
Signed-off-by: David
ot be
exposed in any firmware-provided memory map (SCLP or diag260 on s390x).
For this reason, these memory devices will be places in memory *above*
the "maximum storage increment" exposed via SCLP.
Let's provide a new diag500 subcode to query the memory limit determined in
s390_m
ned-off-by: David Hildenbrand
---
MAINTAINERS | 2 +
hw/s390x/meson.build | 1 +
hw/s390x/virtio-ccw-md.c | 153 +++
hw/s390x/virtio-ccw-md.h | 44 +++
hw/virtio/Kconfig| 1 +
5 files changed, 201 insertions(+)
create mode
ly detects the rename.
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-virtio-hcall.c | 8
hw/s390x/s390-virtio-hcall.h | 11 ++-
target/s390x/kvm/kvm.c | 10 ++
target/s390x/tcg/misc_helper.c | 4 ++--
4 files changed, 14 insertions(+), 19 deletions(-)
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.
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-skeys.c | 4 +---
1
We actually want to check the available RAM, not the maximum RAM size.
Signed-off-by: David Hildenbrand
---
target/s390x/kvm/pv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/s390x/kvm/pv.c b/target/s390x/kvm/pv.c
index dde836d21a..424cce75ca 100644
--- a/target
I'll send out the kernel driver bits soon.
[1] https://lkml.kernel.org/r/20240906101658.514470-1-pbonz...@redhat.com
[2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
Cc: Paolo Bonzini
Cc: Thomas Huth
Cc: Halil Pasic
Cc: Christian Borntraeger
Cc: Eric Farman
Cc: Richard
so not send any attributes for any memory holes, just so they
get ignored on the destination.
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-stattrib-kvm.c | 63 +++-
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/hw/s390x/s390-stattrib-kvm.c
Let's make it clearer that we are talking about general
QEMU/KVM-specific hypercalls.
Signed-off-by: David Hildenbrand
---
hw/s390x/meson.build | 2 +-
hw/s390x/{s390-virtio-hcall.c => s390-hypercall.c} | 2 +-
hw/s390x/{s390-virtio-hcall.h => s390-hyper
Let's add a way to return the value (successfully) set via
s390_set_max_pagesize() previously. This will be helpful to reject
hotplugged memory devices that would exceed this initially set page size.
Signed-off-by: David Hildenbrand
---
target/s390x/cpu-sysemu.c | 16
t
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.
Signed-off-by: David Hildenbrand
---
hw
: Invalid argument
Aborted (core dumped)
Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: ram size must be multiples of 1 MiB
Signed-off-by: David Hildenbrand
---
hw/s390x
uot;
Cc: Gavin Shan
Cc: Juraj Marcin
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index ef64bf1b4a..4075f3d4ce 100644
--- a/hw/virtio/virtio-mem.c
+++ b/hw/virtio/virtio-
y and incomplete at first.
--
Cheers,
David / dhildenb
/20240318120645.105664-1-da...@redhat.com/
Thanks, I'll queue this to
https://github.com/davidhildenbrand/qemu.git mem-next
@Peter, it would be great if you could have another look at patch #2,
thanks.
--
Cheers,
David / dhildenb
causes a
linking failure.
I'll queue this to
https://github.com/davidhildenbrand/qemu.git mem-next
and drop it if someone beats me to up-streaming it :)
--
Cheers,
David / dhildenb
83932 NIC to
> > fail
> > when using the normal -nic user,model=dp83932 command line.
> >
>
> Cc: qemu-sta...@nongnu.org # v9.0
> Fixes: e104edbb9d ("hw/mips/jazz: use qemu_find_nic_info()")
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhous
causes a
linking failure.
Cc: David Hildenbrand
Reported-by: Michael Tokarev
Signed-off-by: Paolo Bonzini
---
Reviewed-by: David Hildenbrand
Thanks!
--
Cheers,
David / dhildenb
On 06.09.24 10:18, Paolo Bonzini wrote:
On Fri, Sep 6, 2024 at 9:40 AM David Hildenbrand wrote:
On 06.09.24 09:37, Paolo Bonzini wrote:
Virtio memory devices rely on PCI BARs to expose the contents of memory.
Because of this they cannot be used with virtio-mmio or virtio-ccw. In fact
Guess
Cc: David Hildenbrand
Reported-by: Michael Tokarev
Signed-off-by: Paolo Bonzini
---
hw/virtio/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/Kconfig b/hw/virtio/Kconfig
index aa63ff7fd41..7c554d230d8 100644
--- a/hw/virtio/Kconfig
+++ b/hw
.
Cc: David Hildenbrand
Reported-by: Michael Tokarev
Signed-off-by: Paolo Bonzini
---
hw/virtio/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/Kconfig b/hw/virtio/Kconfig
index aa63ff7fd41..7c554d230d8 100644
--- a/hw/virtio/Kconfig
+++ b/hw
On Fri, Sep 6, 2024 at 12:56 AM Stefan Hajnoczi wrote:
>
> On Tue, Jul 16, 2024 at 10:21:35AM +0900, David Stevens wrote:
> > On Fri, Jul 12, 2024 at 2:47 PM Michael S. Tsirkin wrote:
> > >
> > > On Fri, Jul 12, 2024 at 11:06:49AM +0900, David Stevens wrote:
>
On 04.09.24 23:34, Peter Xu wrote:
On Wed, Sep 04, 2024 at 11:23:33PM +0200, David Hildenbrand wrote:
Then, you can remove the parameter from kvm_slots_grow() completely and just
call it
kvm_slots_double() and simplify a bit:
static bool kvm_slots_double(KVMMemoryListener *kml
r "compact".
We only have one place growing so far, which is pretty trivial to double
there, IMO. I'll wait for a second opinion, or let me know if you have
strong feelings..
I think the simplicity of kvm_slots_double() speaks for itself, but I
won't fight for it.
--
Cheers,
David / dhildenb
ath, there is
certainly
more optimization potential :)
I'm surprised this 32k loop wasn't found earlier.
--
Cheers,
David / dhildenb
On 04.09.24 22:43, David Hildenbrand wrote:
On 04.09.24 21:16, Peter Xu wrote:
Zhiyi reported an infinite loop issue in VFIO use case. The cause of that
was a separate discussion, however during that I found a regression of
dirty sync slowness when profiling.
Each KVMMemoryListerner maintains
llocated dynamically.
Wouldn't it be sufficient to limit the walk to the actually used slots?
I know, the large allocation might sound scary at first, but memory
overcommit+populate-on-demand should handle that, assuming nobody
touches the yet-unused slots.
--
Cheers,
David / dhildenb
On 04.09.24 21:16, Peter Xu wrote:
This will make all nr_slots counters to be named in the same manner.
Signed-off-by: Peter Xu
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
FAULT 32
+
Any reason for the "NUM" vs. "NR" in there?
Something that resembles KVM_CAP_NR_MEMSLOTS would be a bit ore
consistent, because the 32 is essentially the fallback if the capability
is not supported.
Apart from that makes sense
Reviewed-by: Davi
On 04.09.24 21:16, Peter Xu wrote:
This value used to reflect the maximum supported memslots from KVM kernel.
Rename it to be clearer, preparing for dynamic sized memslot allocations.
Well, it matches "KVM_CAP_NR_MEMSLOTS" :)
Reviewed-by: David Hildenbrand
-for (i = 0; i <
ample, RAM content must not be lost during wake-up, and memory
devices like virtio-mem that provide additional RAM must not reset such
state during wake-ups, but might do so during cold resets."
@Peter, WDYT?
--
Cheers,
David / dhildenb
ed cpu type returned from PDC_MODEL
PC-Offset Stack Trace (read across, top of stack is 1st):
0x0015f43c 0x001ab404 0x001ab938 0x003d4e50 0x00156f68 0x00152ae0
End Of Stack
David Bonham - IT Consultant |
dbon...@nicmangroup.com<mailto:dbon...@nicmangroup.com>
m: 850.830.6428 | f: 303.500.06
a ("memory: RCU ram_list.dirty_memory[] for safe RAM hotplug")
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Peter Xu
Tested-by: Peter Maydell
Cc: qemu-sta...@nongnu.org
Cc: Stefan Hajnoczi
Cc: Paolo Bonzini
Cc: Peter Xu
Cc: "Philippe Mathieu-Daudé"
Signed-off-by: David Hil
On 27.08.24 20:41, Peter Xu wrote:
On Tue, Aug 27, 2024 at 08:00:07PM +0200, David Hildenbrand wrote:
On 27.08.24 19:57, Peter Xu wrote:
On Tue, Aug 27, 2024 at 10:37:15AM +0200, David Hildenbrand wrote:
/* Called with ram_list.mutex held */
-static void dirty_memory_extend(ram_addr_t
On 27.08.24 19:57, Peter Xu wrote:
On Tue, Aug 27, 2024 at 10:37:15AM +0200, David Hildenbrand wrote:
/* Called with ram_list.mutex held */
-static void dirty_memory_extend(ram_addr_t old_ram_size,
-ram_addr_t new_ram_size)
+static void dirty_memory_extend
On 27.08.24 19:50, Peter Xu wrote:
On Tue, Aug 27, 2024 at 01:28:02PM -0400, Stefan Hajnoczi wrote:
On Tue, 27 Aug 2024 at 13:24, David Hildenbrand wrote:
On 27.08.24 18:52, Stefan Hajnoczi wrote:
On Tue, 27 Aug 2024 at 04:38, David Hildenbrand wrote:
As reported by Peter, we might be
On 27.08.24 18:52, Stefan Hajnoczi wrote:
On Tue, 27 Aug 2024 at 04:38, David Hildenbrand wrote:
As reported by Peter, we might be leaking memory when removing the
highest RAMBlock (in the weird ram_addr_t space), and adding a new one.
We will fail to realize that we already allocated
tplug")
Cc: qemu-sta...@nongnu.org
Cc: Stefan Hajnoczi
Cc: Paolo Bonzini
Cc: Peter Xu
Cc: "Philippe Mathieu-Daudé"
Signed-off-by: David Hildenbrand
---
include/exec/ramlist.h | 1 +
system/physmem.c | 44 ++
2 files changed, 16 in
On 26.08.24 18:25, David Hildenbrand wrote:
On 26.08.24 17:56, David Hildenbrand wrote:
On 26.08.24 17:38, David Hildenbrand wrote:
On 20.08.24 10:50, Peter Maydell wrote:
On Mon, 19 Aug 2024 at 20:07, David Hildenbrand wrote:
On 19.08.24 18:24, Peter Maydell wrote:
Hi; I'm looking
On 26.08.24 17:56, David Hildenbrand wrote:
On 26.08.24 17:38, David Hildenbrand wrote:
On 20.08.24 10:50, Peter Maydell wrote:
On Mon, 19 Aug 2024 at 20:07, David Hildenbrand wrote:
On 19.08.24 18:24, Peter Maydell wrote:
Hi; I'm looking at a memory leak apparently in the host m
On 26.08.24 17:38, David Hildenbrand wrote:
On 20.08.24 10:50, Peter Maydell wrote:
On Mon, 19 Aug 2024 at 20:07, David Hildenbrand wrote:
On 19.08.24 18:24, Peter Maydell wrote:
Hi; I'm looking at a memory leak apparently in the host memory backend
code that you can see from the qm
On 20.08.24 10:50, Peter Maydell wrote:
On Mon, 19 Aug 2024 at 20:07, David Hildenbrand wrote:
On 19.08.24 18:24, Peter Maydell wrote:
Hi; I'm looking at a memory leak apparently in the host memory backend
code that you can see from the qmp-cmd-test. Repro instructions:
Hi Peter,
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
On Thu, 2024-08-22 at 12:49 +0100, Simon Horman wrote:
> Hi David,
>
> Sorry to be always the one with the nit-pick.
> Sparse complains about the line above, I believe because the
> type of st->clk->size is __le32.
>
> .../ptp_vmclock.c:562:13: warning: restricted
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
1 - 100 of 7770 matches
Mail list logo
