Re: Question about TCG backend correctness
On 10/18/22 01:27, LIU Zhiwei wrote: Maybe I can run RISU on qemu-aarch64(x86) and qemu-aarch64(risc-v) to check the RISC-V backend. This is a good start for debugging a tcg backend. It's not comprehensive, because RISU executes one instruction at a time then raises an exception to check the results. This means that the tcg optimizer doesn't have much to work with, which means that the tcg backend is not as stressed as it could be. I've long wanted to have the ability to have TCG unit tests where a virtual processor could be defined for the purpose of directly exercising TCG. We already have many ISAs as the front end of TCG. Will the virtual processor here be some different? It wouldn't. This is my argument against creating a new virtual processor. I do think we should be better about creating regression tests for bugs fixed, in the form of small focused assembly test cases which get run via check-tcg. r~
[PATCH] qga: Fix memory leak in split_list
We should use g_strfreev to free the memory allocated by g_strsplit().
Use g_free() will cause a memory leak.
Signed-off-by: Miaoqian Lin
---
qga/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qga/main.c b/qga/main.c
index 5a9d8252e075..04902076b25d 100644
--- a/qga/main.c
+++ b/qga/main.c
@@ -934,7 +934,7 @@ static GList *split_list(const gchar *str, const gchar
*delim)
for (i = 0; strv[i]; i++) {
list = g_list_prepend(list, strv[i]);
}
-g_free(strv);
+g_strfreev(strv);
return list;
}
--
2.25.1
Re: [PATCH v4 01/10] acpi/tests/avocado/bits: initial commit of test scripts that are run by biosbits
On Tue, Oct 18, 2022 at 2:43 AM Philippe Mathieu-Daudé wrote: > > On 14/10/22 19:34, Ani Sinha wrote: > > This is initial commit of cpuid, acpi and smbios python test scripts for > > biosbits to execute. No change has been made to them from the original code > > written by the biosbits author Josh Triplett. They are required to be > > installed > > into the bits iso file and then run from within the virtual machine booted > > off > > with biosbits iso. > > > > The test scripts have a ".py2" extension in order to prevent avocado from > > loading them. They are written in python 2.7 and are run from within bios > > bits. > > There is no need for avocado to try to load them and call out errors on > > python3 > > specific syntaxes. > > > > The original location of these tests are here: > > https://github.com/biosbits/bits/blob/master/python/testacpi.py > > https://github.com/biosbits/bits/blob/master/python/smbios.py > > https://github.com/biosbits/bits/blob/master/python/testcpuid.py > > > > For QEMU, we maintain a fork of the above repo here with numerious fixes: > > https://gitlab.com/qemu-project/biosbits-bits > > > > The acpi test for example is maintained here in the fork: > > https://gitlab.com/qemu-project/biosbits-bits/-/raw/master/python/testacpi.py > > I missed the previous iterations of this series, and wonder why copy > these files in QEMU repository if they already are in a forked > repository. Why not add the fork as a submodule? Check the thread "Why we should avoid new submodules if possible" in the mailing list.
Re: [BUG] hw/i386/pc.c: CXL Fixed Memory Window should not reserve e820 in bios
Early-boot e820 records will be inserted by the bios/efi/early boot
software and be reported to the kernel via insert_resource. Later, when
CXL drivers iterate through the regions again, they will insert another
resource and make the RESERVED memory area a child.
This RESERVED memory area causes the memory region to become unusable,
and as a result attempting to create memory regions with
`cxl create-region ...`
Will fail due to the RESERVED area intersecting with the CXL window.
During boot the following traceback is observed:
0x81101650 in insert_resource_expand_to_fit ()
0x83d964c5 in e820__reserve_resources_late ()
0x83e03210 in pcibios_resource_survey ()
0x83e04f4a in pcibios_init ()
Which produces a call to reserve the CFMWS area:
(gdb) p *new
$54 = {start = 0x29000, end = 0x2cfff, name = "Reserved",
flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0,
child = 0x0}
Later the Kernel parses ACPI tables and reserves the exact same area as
the CXL Fixed Memory Window. The use of `insert_resource_conflict`
retains the RESERVED region and makes it a child of the new region.
0x811016a4 in insert_resource_conflict ()
insert_resource ()
0x81a81389 in cxl_parse_cfmws ()
0x818c4a81 in call_handler ()
acpi_parse_entries_array ()
(gdb) p/x *new
$59 = {start = 0x29000, end = 0x2cfff, name = "CXL Window 0",
flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0,
child = 0x0}
This produces the following output in /proc/iomem:
59000-68fff : CXL Window 0
59000-68fff : Reserved
This reserved area causes `get_free_mem_region()` to fail due to a check
against `__region_intersects()`. Due to this reserved area, the
intersect check will only ever return REGION_INTERSECTS, which causes
`cxl create-region` to always fail.
Signed-off-by: Gregory Price
---
hw/i386/pc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 566accf7e6..5bf5465a21 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms,
hwaddr cxl_size = MiB;
cxl_base = pc_get_cxl_range_start(pcms);
-e820_add_entry(cxl_base, cxl_size, E820_RESERVED);
memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size);
memory_region_add_subregion(system_memory, cxl_base, mr);
cxl_resv_end = cxl_base + cxl_size;
@@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms,
memory_region_init_io(>mr, OBJECT(machine), _ops,
fw,
"cxl-fixed-memory-region", fw->size);
memory_region_add_subregion(system_memory, fw->base, >mr);
Or will this be subregion of cxl_base?
Thanks,
Pankaj
-e820_add_entry(fw->base, fw->size, E820_RESERVED);
cxl_fmw_base += fw->size;
cxl_resv_end = cxl_fmw_base;
}
RE: [PATCH] vfio/migration: Fix wrong enum usage
> -Original Message-
> From: Qemu-devel
> On Behalf Of Avihai Horon
> Sent: Sunday, October 16, 2022 4:58 PM
> To: qemu-devel@nongnu.org; Alex Williamson
> ; Kunkun Jiang
> Cc: Avihai Horon
> Subject: [PATCH] vfio/migration: Fix wrong enum usage
>
> vfio_migration_init() initializes VFIOMigration->device_state using enum of
> VFIO migration protocol v2. Current implemented protocol is v1 so v1 enum
> should be used. Fix it.
>
> Fixes: 429c72800654 ("vfio/migration: Fix incorrect initialization value for
> parameters in VFIOMigration")
> Signed-off-by: Avihai Horon
Looks good to me.
Reviewed-by: Zhang Chen
But I found nowhere using the enum of VFIO migration protocol v2
(vfio_device_mig_state).
I don't know more about the background, should we remove the redundancy
definition or add full support for
the VFIO migration protocol v2 ?
Thanks
Chen
> ---
> hw/vfio/migration.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c index
> d9598ce070..8dbbfa2c56 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -803,7 +803,7 @@ static int vfio_migration_init(VFIODevice *vbasedev,
> }
>
> vbasedev->migration = g_new0(VFIOMigration, 1);
> -vbasedev->migration->device_state = VFIO_DEVICE_STATE_RUNNING;
> +vbasedev->migration->device_state = VFIO_DEVICE_STATE_V1_RUNNING;
> vbasedev->migration->vm_running = runstate_is_running();
>
> ret = vfio_region_setup(obj, vbasedev, >migration->region,
> --
> 2.21.3
>
[PATCH] vhost-user: Fix out of order vring host notification handling
vhost backend sends host notification for every VQ. If backend creates
VQs in parallel, the VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG may
arrive to QEMU in different order than incremental queue index order.
For example VQ 1's message arrive earlier than VQ 0's:
After alloc VhostUserHostNotifier for VQ 1. GPtrArray becomes
[ nil, VQ1 pointer ]
After alloc VhostUserHostNotifier for VQ 0. GPtrArray becomes
[ VQ0 pointer, nil, VQ1 pointer ]
This is wrong. fetch_notifier will return NULL for VQ 1 in
vhost_user_get_vring_base, causes host notifier miss removal(leak).
The fix is to remove current element from GPtrArray, make the right
position for element to insert.
Fixes: 503e355465 ("virtio/vhost-user: dynamically assign
VhostUserHostNotifiers")
Signed-off-by: Yajun Wu
Acked-by: Parav Pandit
---
hw/virtio/vhost-user.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 03415b6c95..d256ce589b 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -1543,6 +1543,11 @@ static VhostUserHostNotifier
*fetch_or_create_notifier(VhostUserState *u,
n = g_ptr_array_index(u->notifiers, idx);
if (!n) {
+/*
+ * In case notification arrive out-of-order,
+ * make room for current index.
+ */
+g_ptr_array_remove_index(u->notifiers, idx);
n = g_new0(VhostUserHostNotifier, 1);
n->idx = idx;
g_ptr_array_insert(u->notifiers, idx, n);
--
2.27.0
Re: [PATCH v1] vhost-vdpa : add support for vIOMMU
On Sat, 8 Oct 2022 at 01:11, Eugenio Perez Martin wrote:
>
> On Thu, Oct 6, 2022 at 7:44 AM Cindy Lu wrote:
> >
> > Add support for vIOMMU. Register a memory listener to dma_as in
> > vhost_vdpa_dev_start
> > - during region_add register a specific IOMMU notifier, and store all
> > notifiers in a list.
> > - during region_del, compare and delete the IOMMU notifier from the list
> > - also change the IOTLB batch flag to support IOMMU batch send
> >
> > Verified in vp_vdpa and vdpa_sim_net driver
> >
> > Signed-off-by: Cindy Lu
> > ---
> > hw/virtio/vhost-vdpa.c | 253 +++--
> > include/hw/virtio/vhost-vdpa.h | 26 +++-
> > 2 files changed, 267 insertions(+), 12 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> > index 3ff9ce3501..d2ac40c261 100644
> > --- a/hw/virtio/vhost-vdpa.c
> > +++ b/hw/virtio/vhost-vdpa.c
> > @@ -26,6 +26,7 @@
> > #include "cpu.h"
> > #include "trace.h"
> > #include "qapi/error.h"
> > +#include "hw/virtio/virtio-access.h"
> >
> > /*
> > * Return one past the end of the end of section. Be careful with uint64_t
> > @@ -136,14 +137,15 @@ static void vhost_vdpa_listener_begin_batch(struct
> > vhost_vdpa *v)
> > }
> > }
> >
> > -static void vhost_vdpa_iotlb_batch_begin_once(struct vhost_vdpa *v)
> > +static void vhost_vdpa_iotlb_batch_begin_once(struct vhost_vdpa *v,
> > + enum iotlb_batch_flag flag)
> > {
> > if (v->dev->backend_cap & (0x1ULL << VHOST_BACKEND_F_IOTLB_BATCH) &&
> > !v->iotlb_batch_begin_sent) {
> > vhost_vdpa_listener_begin_batch(v);
> > }
> >
> > -v->iotlb_batch_begin_sent = true;
> > +v->iotlb_batch_begin_sent |= flag;
> > }
> >
> > static void vhost_vdpa_listener_commit(MemoryListener *listener)
> > @@ -157,7 +159,7 @@ static void vhost_vdpa_listener_commit(MemoryListener
> > *listener)
> > return;
> > }
> >
> > -if (!v->iotlb_batch_begin_sent) {
> > +if (!(v->iotlb_batch_begin_sent & VDPA_IOTLB_BATCH_SEND)) {
> > return;
> > }
> >
> > @@ -169,8 +171,7 @@ static void vhost_vdpa_listener_commit(MemoryListener
> > *listener)
> > error_report("failed to write, fd=%d, errno=%d (%s)",
> > fd, errno, strerror(errno));
> > }
> > -
> > -v->iotlb_batch_begin_sent = false;
> > +v->iotlb_batch_begin_sent &= ~VDPA_IOTLB_BATCH_SEND;
> > }
> >
> > static void vhost_vdpa_listener_region_add(MemoryListener *listener,
> > @@ -186,6 +187,9 @@ static void
> > vhost_vdpa_listener_region_add(MemoryListener *listener,
> > v->iova_range.last)) {
> > return;
> > }
> > +if (memory_region_is_iommu(section->mr)) {
> > +return;
> > +}
> >
> > if (unlikely((section->offset_within_address_space &
> > ~TARGET_PAGE_MASK) !=
> > (section->offset_within_region & ~TARGET_PAGE_MASK))) {
> > @@ -227,9 +231,9 @@ static void
> > vhost_vdpa_listener_region_add(MemoryListener *listener,
> > iova = mem_region.iova;
> > }
> >
> > -vhost_vdpa_iotlb_batch_begin_once(v);
> > -ret = vhost_vdpa_dma_map(v, iova, int128_get64(llsize),
> > - vaddr, section->readonly);
> > +vhost_vdpa_iotlb_batch_begin_once(v, VDPA_IOTLB_BATCH_SEND);
> > +ret = vhost_vdpa_dma_map(v, iova, int128_get64(llsize), vaddr,
> > + section->readonly);
> > if (ret) {
> > error_report("vhost vdpa map fail!");
> > goto fail;
> > @@ -260,6 +264,9 @@ static void
> > vhost_vdpa_listener_region_del(MemoryListener *listener,
> > v->iova_range.last)) {
> > return;
> > }
> > +if (memory_region_is_iommu(section->mr)) {
> > +return;
> > +}
> >
> > if (unlikely((section->offset_within_address_space &
> > ~TARGET_PAGE_MASK) !=
> > (section->offset_within_region & ~TARGET_PAGE_MASK))) {
> > @@ -292,7 +299,7 @@ static void
> > vhost_vdpa_listener_region_del(MemoryListener *listener,
> > iova = result->iova;
> > vhost_iova_tree_remove(v->iova_tree, result);
> > }
> > -vhost_vdpa_iotlb_batch_begin_once(v);
> > +vhost_vdpa_iotlb_batch_begin_once(v, VDPA_IOTLB_BATCH_SEND);
> > ret = vhost_vdpa_dma_unmap(v, iova, int128_get64(llsize));
> > if (ret) {
> > error_report("vhost_vdpa dma unmap error!");
> > @@ -312,6 +319,212 @@ static const MemoryListener
> > vhost_vdpa_memory_listener = {
> > .region_del = vhost_vdpa_listener_region_del,
> > };
> >
> > +static void vhost_vdpa_listener_iommu_commit(MemoryListener *listener)
> > +{
> > +struct vhost_vdpa *v =
> > +container_of(listener, struct vhost_vdpa, iommu_listener);
> > +struct vhost_dev *dev = v->dev;
> > +struct vhost_msg_v2 msg = {};
> > +int fd = v->device_fd;
> > +
> > +
Re: [PATCH 1/1] tcg: add perfmap and jitdump
On Fri, 2022-10-14 at 07:35 +1100, Richard Henderson wrote:
> On 10/12/22 22:18, Ilya Leoshkevich wrote:
> > Add ability to dump /tmp/perf-.map and jit-.dump.
> > The first one allows the perf tool to map samples to each
> > individual
> > translation block. The second one adds the ability to resolve
> > symbol
> > names, line numbers and inspect JITed code.
> >
> > Example of use:
> >
> > perf record qemu-x86_64 -perfmap ./a.out
> > perf report
> >
> > or
> >
> > perf record -k 1 qemu-x86_64 -jitdump ./a.out
> > perf inject -j -i perf.data -o perf.data.jitted
> > perf report -i perf.data.jitted
> >
> > Co-developed-by: Vanderson M. do Rosario
> > Co-developed-by: Alex Bennée
> > Signed-off-by: Ilya Leoshkevich
>
> I think I remember this, and the question that was never answered
> was:
>
> > @@ -1492,6 +1493,8 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
> > }
> > tb->tc.size = gen_code_size;
> >
> > + perf_report_code(gen_code_buf, gen_code_size, tb->icount, tb-
> > >pc);
>
> When do_tb_flush is called, everything that is recorded in perfmap is
> invalidated.
> How do you tell perf about that?
>
>
> r~
>
I don't think we should handle this altogether. Perf already knows how
to handle overlapping addresses:
$ cat main.c
#include
#include
int main()
{
void *d = dlopen("./lib1.so", RTLD_NOW);
void (*f)(void) = dlsym(d, "f");
printf("%p\n", f);
f();
dlclose(d);
d = dlopen("./lib2.so", RTLD_NOW);
f = dlsym(d, "f");
printf("%p\n", f);
f();
dlclose(d);
}
$ cat 1.c
static volatile int i = 0;
void f(void) {
while (i < 10) {
i++;
}
}
$ gcc -o main -O3 -g main.c -ldl
$ gcc -o lib1.so -shared -fPIC -O3 -g 1.c
$ cp 1.c 2.c
$ gcc -o lib2.so -shared -fPIC -O3 -g 2.c
$ perf record ./main
0x7f47925eb100
0x7f47925eb100
$ perf report
49.96% main lib1.so [.] f
49.92% main lib2.so [.] f
Note that there is "load" event - PERF_RECORD_MMAP2, but no "unload"
event. The old mappings are simply discarded by
maps__fixup_overlappings() when something new is mapped.
In our case this means that as soon as we JIT new code, perf will see
that it replaced the one that was flushed. Until then it will live with
stale mappings, but there is no harm in that, since they are not
executed.
Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
On Sun, 16 Oct 2022, Julien Grall wrote: > Hi, > > There seem to be some missing patches on xen-devel (including the cover > letter). Is that expected? > > On 15/10/2022 06:07, Vikram Garhwal wrote: > > Add a new machine xenpv which creates a IOREQ server to register/connect > > with > > Xen Hypervisor. > > I don't like the name 'xenpv' because it doesn't convey the fact that some of > the HW may be emulated rather than para-virtualized. In fact one may only want > to use for emulating devices. > > Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen' to > select a Xen layout. The benefit of 'xenpv' is that it doesn't require any changes to libxl. It is even backward compatible so it could be used with an older version of Xen/libxl. Backward compatibility aside, if we come up with a different name then we'll need changes to libxl and to manage those changes. For instance, if we use 'xen-arm' that would mean we would need to handle per-arch QEMU machine names.
Re: [PATCH] MAINTAINERS: Replace my amsat.org email address
On Tue, Oct 18, 2022 at 4:15 AM Philippe Mathieu-Daudé wrote: > > The amsat.org domain is having issues with DMARC / SPF / DKIM: > https://lore.kernel.org/qemu-devel/CAMVc7JUy5NeEN0q=4zfZvn_rppgqn9wicV1z=tsluhks3ry...@mail.gmail.com/ Yeah, I noticed this before, and gmail marks the email as spam, and patchwork simply drops the patch email silently ... > > Consolidate all of my MAINTAINERS entries on my work address. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .mailmap| 4 +++- > MAINTAINERS | 62 ++--- > 2 files changed, 34 insertions(+), 32 deletions(-) > Regards, Bin
Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
On Fri, Sep 30, 2022, Fuad Tabba wrote: > > > > > pKVM would also need a way to make an fd accessible again > > > > > when shared back, which I think isn't possible with this patch. > > > > > > > > But does pKVM really want to mmap/munmap a new region at the page-level, > > > > that can cause VMA fragmentation if the conversion is frequent as I see. > > > > Even with a KVM ioctl for mapping as mentioned below, I think there will > > > > be the same issue. > > > > > > pKVM doesn't really need to unmap the memory. What is really important > > > is that the memory is not GUP'able. > > > > Well, not entirely unguppable, just unguppable without a magic FOLL_* flag, > > otherwise KVM wouldn't be able to get the PFN to map into guest memory. > > > > The problem is that gup() and "mapped" are tied together. So yes, pKVM > > doesn't > > strictly need to unmap memory _in the untrusted host_, but since > > mapped==guppable, > > the end result is the same. > > > > Emphasis above because pKVM still needs unmap the memory _somehwere_. > > IIUC, the > > current approach is to do that only in the stage-2 page tables, i.e. only > > in the > > context of the hypervisor. Which is also the source of the gup() problems; > > the > > untrusted kernel is blissfully unaware that the memory is inaccessible. > > > > Any approach that moves some of that information into the untrusted kernel > > so that > > the kernel can protect itself will incur fragmentation in the VMAs. Well, > > unless > > all of guest memory becomes unguppable, but that's likely not a viable > > option. > > Actually, for pKVM, there is no need for the guest memory to be GUP'able at > all if we use the new inaccessible_get_pfn(). Ya, I was referring to pKVM without UPM / inaccessible memory. Jumping back to blocking gup(), what about using the same tricks as secretmem to block gup()? E.g. compare vm_ops to block regular gup() and a_ops to block fast gup() on struct page? With a Kconfig that's selected by pKVM (which would also need its own Kconfig), e.g. CONFIG_INACCESSIBLE_MAPPABLE_MEM, there would be zero performance overhead for non-pKVM kernels, i.e. hooking gup() shouldn't be controversial. I suspect the fast gup() path could even be optimized to avoid the page_mapping() lookup by adding a PG_inaccessible flag that's defined iff the TBD Kconfig is selected. I'm guessing pKVM isn't expected to be deployed on massivve NUMA systems anytime soon, so there should be plenty of page flags to go around. Blocking gup() instead of trying to play refcount games when converting back to private would eliminate the need to put heavy restrictions on mapping, as the goal of those were purely to simplify the KVM implementation, e.g. the "one mapping per memslot" thing would go away entirely. > This of course goes back to what I'd mentioned before in v7; it seems that > representing the memslot memory as a file descriptor should be orthogonal to > whether the memory is shared or private, rather than a private_fd for private > memory and the userspace_addr for shared memory. I also explored the idea of backing any guest memory with an fd, but came to the conclusion that private memory needs a separate handle[1], at least on x86. For SNP and TDX, even though the GPA is the same (ignoring the fact that SNP and TDX steal GPA bits to differentiate private vs. shared), the two types need to be treated as separate mappings[2]. Post-boot, converting is lossy in both directions, so even conceptually they are two disctint pages that just happen to share (some) GPA bits. To allow conversions, i.e. changing which mapping to use, without memslot updates, KVM needs to let userspace provide both mappings in a single memslot. So while fd-based memory is an orthogonal concept, e.g. we could add fd-based shared memory, KVM would still need a dedicated private handle. For pKVM, the fd doesn't strictly need to be mutually exclusive with the existing userspace_addr, but since the private_fd is going to be added for x86, I think it makes sense to use that instead of adding generic fd-based memory for pKVM's use case (which is arguably still "private" memory but with special semantics). [1] https://lore.kernel.org/all/yulth7bl4mwt5...@google.com [2] https://lore.kernel.org/all/869622df-5bf6-0fbb-cac4-34c6ae7df...@kernel.org > The host can then map or unmap the shared/private memory using the fd, which > allows it more freedom in even choosing to unmap shared memory when not > needed, for example.
[BUG] hw/i386/pc.c: CXL Fixed Memory Window should not reserve e820 in bios
Early-boot e820 records will be inserted by the bios/efi/early boot
software and be reported to the kernel via insert_resource. Later, when
CXL drivers iterate through the regions again, they will insert another
resource and make the RESERVED memory area a child.
This RESERVED memory area causes the memory region to become unusable,
and as a result attempting to create memory regions with
`cxl create-region ...`
Will fail due to the RESERVED area intersecting with the CXL window.
During boot the following traceback is observed:
0x81101650 in insert_resource_expand_to_fit ()
0x83d964c5 in e820__reserve_resources_late ()
0x83e03210 in pcibios_resource_survey ()
0x83e04f4a in pcibios_init ()
Which produces a call to reserve the CFMWS area:
(gdb) p *new
$54 = {start = 0x29000, end = 0x2cfff, name = "Reserved",
flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0,
child = 0x0}
Later the Kernel parses ACPI tables and reserves the exact same area as
the CXL Fixed Memory Window. The use of `insert_resource_conflict`
retains the RESERVED region and makes it a child of the new region.
0x811016a4 in insert_resource_conflict ()
insert_resource ()
0x81a81389 in cxl_parse_cfmws ()
0x818c4a81 in call_handler ()
acpi_parse_entries_array ()
(gdb) p/x *new
$59 = {start = 0x29000, end = 0x2cfff, name = "CXL Window 0",
flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0,
child = 0x0}
This produces the following output in /proc/iomem:
59000-68fff : CXL Window 0
59000-68fff : Reserved
This reserved area causes `get_free_mem_region()` to fail due to a check
against `__region_intersects()`. Due to this reserved area, the
intersect check will only ever return REGION_INTERSECTS, which causes
`cxl create-region` to always fail.
Signed-off-by: Gregory Price
---
hw/i386/pc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 566accf7e6..5bf5465a21 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms,
hwaddr cxl_size = MiB;
cxl_base = pc_get_cxl_range_start(pcms);
-e820_add_entry(cxl_base, cxl_size, E820_RESERVED);
memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size);
memory_region_add_subregion(system_memory, cxl_base, mr);
cxl_resv_end = cxl_base + cxl_size;
@@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms,
memory_region_init_io(>mr, OBJECT(machine), _ops, fw,
"cxl-fixed-memory-region", fw->size);
memory_region_add_subregion(system_memory, fw->base, >mr);
-e820_add_entry(fw->base, fw->size, E820_RESERVED);
cxl_fmw_base += fw->size;
cxl_resv_end = cxl_fmw_base;
}
--
2.37.3
Re: [PATCH v8 5/8] KVM: Register/unregister the guest private memory regions
On Mon, Oct 17, 2022, Fuad Tabba wrote:
> Hi,
>
> > > > +#ifdef CONFIG_HAVE_KVM_PRIVATE_MEM
> > > > +#define KVM_MEM_ATTR_SHARED0x0001
> > > > +static int kvm_vm_ioctl_set_mem_attr(struct kvm *kvm, gpa_t gpa, gpa_t
> > > > size,
> > > > +bool is_private)
> > > > +{
> > >
> > > I wonder if this ioctl should be implemented as an arch-specific
> > > ioctl. In this patch it performs some actions that pKVM might not need
> > > or might want to do differently.
> >
> > I think it's doable. We can provide the mem_attr_array kind thing in
> > common code and let arch code decide to use it or not. Currently
> > mem_attr_array is defined in the struct kvm, if those bytes are
> > unnecessary for pKVM it can even be moved to arch definition, but that
> > also loses the potential code sharing for confidential usages in other
> > non-architectures, e.g. if ARM also supports such usage. Or it can be
> > provided through a different CONFIG_ instead of
> > CONFIG_HAVE_KVM_PRIVATE_MEM.
>
> This sounds good. Thank you.
I like the idea of a separate Kconfig, e.g. CONFIG_KVM_GENERIC_PRIVATE_MEM or
something. I highly doubt there will be any non-x86 users for multiple years,
if ever, but it would allow testing the private memory stuff on ARM (and any
other
non-x86 arch) without needing full pKVM support and with only minor KVM
modifications, e.g. the x86 support[*] to test UPM without TDX is shaping up to
be
trivial.
[*] https://lore.kernel.org/all/y0mu1fkugnqg5...@google.com
Re: [PATCH v4 01/10] acpi/tests/avocado/bits: initial commit of test scripts that are run by biosbits
On Mon, Oct 17, 2022 at 11:13:55PM +0200, Philippe Mathieu-Daudé wrote: > On 14/10/22 19:34, Ani Sinha wrote: > > This is initial commit of cpuid, acpi and smbios python test scripts for > > biosbits to execute. No change has been made to them from the original code > > written by the biosbits author Josh Triplett. They are required to be > > installed > > into the bits iso file and then run from within the virtual machine booted > > off > > with biosbits iso. > > > > The test scripts have a ".py2" extension in order to prevent avocado from > > loading them. They are written in python 2.7 and are run from within bios > > bits. > > There is no need for avocado to try to load them and call out errors on > > python3 > > specific syntaxes. > > > > The original location of these tests are here: > > https://github.com/biosbits/bits/blob/master/python/testacpi.py > > https://github.com/biosbits/bits/blob/master/python/smbios.py > > https://github.com/biosbits/bits/blob/master/python/testcpuid.py > > > > For QEMU, we maintain a fork of the above repo here with numerious fixes: > > https://gitlab.com/qemu-project/biosbits-bits > > > > The acpi test for example is maintained here in the fork: > > https://gitlab.com/qemu-project/biosbits-bits/-/raw/master/python/testacpi.py > > I missed the previous iterations of this series, and wonder why copy > these files in QEMU repository if they already are in a forked > repository. Why not add the fork as a submodule? People don't want to use submodules because their default configuration in git is broken and git devs don't seem to be willing to change this. Look for "submodules" in qemu archives. > > Cc: Daniel P. Berrangé > > Cc: Paolo Bonzini > > Cc: Maydell Peter > > Cc: John Snow > > Cc: Thomas Huth > > Cc: Alex Bennée > > Cc: Igor Mammedov > > Cc: Michael Tsirkin > > Signed-off-by: Ani Sinha > > --- > > tests/avocado/acpi-bits/bits-tests/smbios.py2 | 2430 + > > .../avocado/acpi-bits/bits-tests/testacpi.py2 | 283 ++ > > .../acpi-bits/bits-tests/testcpuid.py2| 83 + > > 3 files changed, 2796 insertions(+) > > create mode 100644 tests/avocado/acpi-bits/bits-tests/smbios.py2 > > create mode 100644 tests/avocado/acpi-bits/bits-tests/testacpi.py2 > > create mode 100644 tests/avocado/acpi-bits/bits-tests/testcpuid.py2
Re: [v2] hw: misc: edu: fix 2 off-by-one errors
> On Oct 17, 2022, at 1:22 PM, Alex Bennée wrote: > > > > > Peter Maydell writes: > >>> On Mon, 17 Oct 2022 at 14:50, Alexander Bulekov wrote: >>> >>> On 221015 1710, Chris Friedt wrote: From: Christopher Friedt >>> Reviewed-by: Alexander Bulekov >>> >>> As a side-note, seems strange that edu_check_range will abort the entire >>> VM if the check fails, rather than handling the error more elegantly. >> >> Yes, this is bad for a device model, though we have a lot of >> older device models that still do it. The preferred pattern is: >> * for situations which are "if this happens there is a >> bug in QEMU itself", use assert. hw_error() is a kind of >> assert that prints a bunch of guest register state: sometimes >> you want that, but more often you just want normal assert() >> * for situations where the guest has misprogrammed the device, >> log that with qemu_log_mask(LOG_GUEST_ERROR, ...) >> and continue with whatever the real hardware would do, or >> some reasonable choice if the h/w spec is vague >> * for situations where the guest is correct but is trying to >> get the device to do something our model doesn't implement >> yet, same as above but with LOG_UNIMP. >> >> Probably most hw_error() uses in the codebase should be >> replaced with one of the above options. > > We should probably document this best practice somewhere in docs/devel > but I guess we really need a "guide to writing device emulation" > section. Should I make a separate PR for that or attach it to the existing series (at v3 now)? Thanks, C
Re: [PATCH v7 9/9] target/arm: Enable TARGET_TB_PCREL
On 10/17/22 23:48, Peter Maydell wrote:
-if (use_goto_tb(s, dest)) {
-tcg_gen_goto_tb(n);
-gen_a64_update_pc(s, diff);
+if (use_goto_tb(s, s->pc_curr + diff)) {
+if (TARGET_TB_PCREL) {
+gen_a64_update_pc(s, diff);
+tcg_gen_goto_tb(n);
+} else {
+tcg_gen_goto_tb(n);
+gen_a64_update_pc(s, diff);
+}
Why do we need to do these things in the opposite order
depending on TARGET_TB_PCREL ? If there's an obscure dependency
then it would be worth commenting it, but it would be nicer
if the semantics of the functions were such that they didn't
need to be called the opposite way round for the two cases...
For !pcrel, we can skip the update to pc in the linked case because the destination knows
the full virtual address and can easily store it when needed. So we skip the update when
we can simply to reduce the dynamic instruction count within the TB.
But for pcrel, the destination cannot easily update, i.e. with just addition, the full
virtual address without it always being up-to-date on entry. So that's the rule there.
A comment, then?
r~
Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
On Mon, Oct 17, 2022 at 06:39:06PM +0200, Gupta, Pankaj wrote:
> On 10/17/2022 6:19 PM, Kirill A . Shutemov wrote:
> > On Mon, Oct 17, 2022 at 03:00:21PM +0200, Vlastimil Babka wrote:
> > > On 9/15/22 16:29, Chao Peng wrote:
> > > > From: "Kirill A. Shutemov"
> > > >
> > > > KVM can use memfd-provided memory for guest memory. For normal userspace
> > > > accessible memory, KVM userspace (e.g. QEMU) mmaps the memfd into its
> > > > virtual address space and then tells KVM to use the virtual address to
> > > > setup the mapping in the secondary page table (e.g. EPT).
> > > >
> > > > With confidential computing technologies like Intel TDX, the
> > > > memfd-provided memory may be encrypted with special key for special
> > > > software domain (e.g. KVM guest) and is not expected to be directly
> > > > accessed by userspace. Precisely, userspace access to such encrypted
> > > > memory may lead to host crash so it should be prevented.
> > > >
> > > > This patch introduces userspace inaccessible memfd (created with
> > > > MFD_INACCESSIBLE). Its memory is inaccessible from userspace through
> > > > ordinary MMU access (e.g. read/write/mmap) but can be accessed via
> > > > in-kernel interface so KVM can directly interact with core-mm without
> > > > the need to map the memory into KVM userspace.
> > > >
> > > > It provides semantics required for KVM guest private(encrypted) memory
> > > > support that a file descriptor with this flag set is going to be used as
> > > > the source of guest memory in confidential computing environments such
> > > > as Intel TDX/AMD SEV.
> > > >
> > > > KVM userspace is still in charge of the lifecycle of the memfd. It
> > > > should pass the opened fd to KVM. KVM uses the kernel APIs newly added
> > > > in this patch to obtain the physical memory address and then populate
> > > > the secondary page table entries.
> > > >
> > > > The userspace inaccessible memfd can be fallocate-ed and hole-punched
> > > > from userspace. When hole-punching happens, KVM can get notified through
> > > > inaccessible_notifier it then gets chance to remove any mapped entries
> > > > of the range in the secondary page tables.
> > > >
> > > > The userspace inaccessible memfd itself is implemented as a shim layer
> > > > on top of real memory file systems like tmpfs/hugetlbfs but this patch
> > > > only implemented tmpfs. The allocated memory is currently marked as
> > > > unmovable and unevictable, this is required for current confidential
> > > > usage. But in future this might be changed.
> > > >
> > > > Signed-off-by: Kirill A. Shutemov
> > > > Signed-off-by: Chao Peng
> > > > ---
> > >
> > > ...
> > >
> > > > +static long inaccessible_fallocate(struct file *file, int mode,
> > > > + loff_t offset, loff_t len)
> > > > +{
> > > > + struct inaccessible_data *data = file->f_mapping->private_data;
> > > > + struct file *memfd = data->memfd;
> > > > + int ret;
> > > > +
> > > > + if (mode & FALLOC_FL_PUNCH_HOLE) {
> > > > + if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + ret = memfd->f_op->fallocate(memfd, mode, offset, len);
> > > > + inaccessible_notifier_invalidate(data, offset, offset + len);
> > >
> > > Wonder if invalidate should precede the actual hole punch, otherwise we
> > > open
> > > a window where the page tables point to memory no longer valid?
> >
> > Yes, you are right. Thanks for catching this.
>
> I also noticed this. But then thought the memory would be anyways zeroed
> (hole punched) before this call?
Hole punching can free pages, given that offset/len covers full page.
--
Kiryl Shutsemau / Kirill A. Shutemov
Re: [PATCH v3 2/9] hw/{arm,ppc}: Resolve unreachable code
Am 17. Oktober 2022 20:57:06 UTC schrieb "Philippe Mathieu-Daudé" : >On 16/10/22 14:27, Bernhard Beschow wrote: >> pflash_cfi01_register() always returns with a non-NULL pointer (otherwise >> it would crash internally). Therefore, the bodies of the if-statements >> are unreachable. > >This is true, pflash_cfi0X_register() use an hardcoded _fatal. > >Shouldn't it be better to pass an Error* argument? You mean that the callers would pass _fatal instead, including the ones in this patch? > >From the pflash API perspective I don't see much value in >returning a PFlashCFI0X type instead of a simple DeviceState >(but this is another story...). It comes in handy in the following patches when retrieving the memory region for memory_region_add_subregion() using pflash_cfi0X_get_memory(). What do you think about these next patches? Furthermore, returning PFlashCFI0X can be downcasted which seems safer than upcasting from DeviceState. Best regards, Bernhard > >> Signed-off-by: Bernhard Beschow >> --- >> hw/arm/gumstix.c | 18 ++ >> hw/arm/mainstone.c | 13 + >> hw/arm/omap_sx1.c| 22 -- >> hw/arm/versatilepb.c | 6 ++ >> hw/arm/z2.c | 9 +++-- >> hw/ppc/sam460ex.c| 12 >> 6 files changed, 28 insertions(+), 52 deletions(-)
Re: [PATCH v3 00/29] PowerPC interrupt rework
Matheus, Nice cleanup and rework. The code is way better now. I send a PR today without this series. As soon as that gets merged I'll push these patches to ppc-next. This will give us more time to test the changes and see if we can detect any unintended changes/bugs. Thanks, Daniel On 10/11/22 17:48, Matheus Ferst wrote: Link to v2: https://lists.gnu.org/archive/html/qemu-ppc/2022-09/msg00556.html This series is also available as a git branch: https://github.com/PPC64/qemu/tree/ferst-interrupt-fix-v3 Patches without review: 3-27 This new version rebases the patch series on the current master and fixes some problems pointed out by Fabiano on v2. Matheus Ferst (29): target/ppc: define PPC_INTERRUPT_* values directly target/ppc: always use ppc_set_irq to set env->pending_interrupts target/ppc: split interrupt masking and delivery from ppc_hw_interrupt target/ppc: prepare to split interrupt masking and delivery by excp_model target/ppc: create an interrupt masking method for POWER9/POWER10 target/ppc: remove unused interrupts from p9_next_unmasked_interrupt target/ppc: create an interrupt deliver method for POWER9/POWER10 target/ppc: remove unused interrupts from p9_deliver_interrupt target/ppc: remove generic architecture checks from p9_deliver_interrupt target/ppc: move power-saving interrupt masking out of cpu_has_work_POWER9 target/ppc: add power-saving interrupt masking logic to p9_next_unmasked_interrupt target/ppc: create an interrupt masking method for POWER8 target/ppc: remove unused interrupts from p8_next_unmasked_interrupt target/ppc: create an interrupt deliver method for POWER8 target/ppc: remove unused interrupts from p8_deliver_interrupt target/ppc: remove generic architecture checks from p8_deliver_interrupt target/ppc: move power-saving interrupt masking out of cpu_has_work_POWER8 target/ppc: add power-saving interrupt masking logic to p8_next_unmasked_interrupt target/ppc: create an interrupt masking method for POWER7 target/ppc: remove unused interrupts from p7_next_unmasked_interrupt target/ppc: create an interrupt deliver method for POWER7 target/ppc: remove unused interrupts from p7_deliver_interrupt target/ppc: remove generic architecture checks from p7_deliver_interrupt target/ppc: move power-saving interrupt masking out of cpu_has_work_POWER7 target/ppc: add power-saving interrupt masking logic to p7_next_unmasked_interrupt target/ppc: remove ppc_store_lpcr from CONFIG_USER_ONLY builds target/ppc: introduce ppc_maybe_interrupt target/ppc: unify cpu->has_work based on cs->interrupt_request target/ppc: move the p*_interrupt_powersave methods to excp_helper.c hw/ppc/pnv_core.c| 1 + hw/ppc/ppc.c | 17 +- hw/ppc/spapr_hcall.c | 6 + hw/ppc/spapr_rtas.c | 2 +- hw/ppc/trace-events | 2 +- target/ppc/cpu.c | 4 + target/ppc/cpu.h | 43 +- target/ppc/cpu_init.c| 212 +- target/ppc/excp_helper.c | 887 ++- target/ppc/helper.h | 1 + target/ppc/helper_regs.c | 2 + target/ppc/misc_helper.c | 11 +- target/ppc/translate.c | 2 + 13 files changed, 833 insertions(+), 357 deletions(-)
Re: [PATCH] hw/ide/microdrive: Use device_cold_reset() for self-resets
On 13/10/22 19:40, Peter Maydell wrote:
Currently the microdrive code uses device_legacy_reset() to reset
itself, and has its reset method call reset on the IDE bus as the
last thing it does. Switch to using device_cold_reset().
The only concrete microdrive device is the TYPE_DSCM1; it is not
command-line pluggable, so it is used only by the old pxa2xx Arm
boards 'akita', 'borzoi', 'spitz', 'terrier' and 'tosa'.
Candidates for deprecation?
You might think that this would result in the IDE bus being
reset automatically, but it does not, because the IDEBus type
does not set the BusClass::reset method. Instead the controller
must explicitly call ide_bus_reset(). We therefore leave that
call in md_reset().
Note also that because the PCMCIA card device is a direct subclass of
TYPE_DEVICE and we don't model the PCMCIA controller-to-card
interface as a qbus, PCMCIA cards are not on any qbus and so they
don't get reset when the system is reset. The reset only happens via
the dscm1_attach() and dscm1_detach() functions during
machine creation.
Because our aim here is merely to try to get rid of calls to the
device_legacy_reset() function, we leave these other dubious
reset-related issues alone. (They all stem from this code being
absolutely ancient.)
Signed-off-by: Peter Maydell
---
hw/ide/microdrive.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ide/microdrive.c b/hw/ide/microdrive.c
index 6df9b4cbbe1..56c5be36551 100644
--- a/hw/ide/microdrive.c
+++ b/hw/ide/microdrive.c
@@ -175,7 +175,7 @@ static void md_attr_write(PCMCIACardState *card, uint32_t
at, uint8_t value)
case 0x00:/* Configuration Option Register */
s->opt = value & 0xcf;
if (value & OPT_SRESET) {
-device_legacy_reset(DEVICE(s));
+device_cold_reset(DEVICE(s));
I agree this one is dubious.
}
md_interrupt_update(s);
break;
@@ -318,7 +318,7 @@ static void md_common_write(PCMCIACardState *card, uint32_t
at, uint16_t value)
case 0xe: /* Device Control */
s->ctrl = value;
if (value & CTRL_SRST) {
-device_legacy_reset(DEVICE(s));
+device_cold_reset(DEVICE(s));
Ditto (dubious).
}
md_interrupt_update(s);
break;
@@ -543,7 +543,7 @@ static int dscm1_attach(PCMCIACardState *card)
md->attr_base = pcc->cis[0x74] | (pcc->cis[0x76] << 8);
md->io_base = 0x0;
-device_legacy_reset(DEVICE(md));
+device_cold_reset(DEVICE(md));
This one makes sense.
md_interrupt_update(md);
return 0;
@@ -553,7 +553,7 @@ static int dscm1_detach(PCMCIACardState *card)
{
MicroDriveState *md = MICRODRIVE(card);
-device_legacy_reset(DEVICE(md));
+device_cold_reset(DEVICE(md));
Ditto (correct).
return 0;
}
Hoping this help to get ride of device_legacy_reset():
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] MAINTAINERS: Replace my amsat.org email address
On Mon, 17 Oct 2022 at 16:16, Philippe Mathieu-Daudé wrote: > > The amsat.org domain is having issues with DMARC / SPF / DKIM: > https://lore.kernel.org/qemu-devel/CAMVc7JUy5NeEN0q=4zfZvn_rppgqn9wicV1z=tsluhks3ry...@mail.gmail.com/ > > Consolidate all of my MAINTAINERS entries on my work address. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .mailmap| 4 +++- > MAINTAINERS | 62 ++--- > 2 files changed, 34 insertions(+), 32 deletions(-) Thanks, applied to qemu.git/master. Stefan
Re: MultiFD and default channel out of order mapping on receive side.
On Mon, Oct 17, 2022 at 12:38:30PM +0100, Daniel P. Berrangé wrote: > On Mon, Oct 17, 2022 at 01:06:00PM +0530, manish.mishra wrote: > > Hi Daniel, > > > > I was thinking for some solutions for this so wanted to discuss that before > > going ahead. Also added Juan and Peter in loop. > > > > 1. Earlier i was thinking, on destination side as of now for default > > and multi-FD channel first data to be sent is MAGIC_NUMBER and VERSION > > so may be we can decide mapping based on that. But then that does not > > work for newly added post copy preempt channel as it does not send > > any MAGIC number. Also even for multiFD just MAGIC number does not > > tell which multifd channel number is it, even though as per my thinking > > it does not matter. So MAGIC number should be good for indentifying > > default vs multiFD channel? > > Yep, you don't need to know more than the MAGIC value. > > In migration_io_process_incoming, we need to use MSG_PEEK to look at > the first 4 bytes pendingon the wire. If those bytes are 'QEVM' that's > the primary channel, if those bytes are big endian 0x11223344, that's > a multifd channel. Using MSG_PEEK aviods need to modify thue later > code that actually reads this data. > > The challenge is how long to wait with the MSG_PEEK. If we do it > in a blocking mode, its fine for main channel and multifd, but > IIUC for the post-copy pre-empt channel we'd be waiting for > something that will never arrive. > > Having suggested MSG_PEEK though, this may well not work if the > channel has TLS present. In fact it almost definitely won't work. > > To cope with TLS migration_io_process_incoming would need to > actually read the data off the wire, and later methods be > taught to skip reading the magic. > > > 2. For post-copy preempt may be we can initiate this channel only > > after we have received a request from remote e.g. remote page fault. > > This to me looks safest considering post-copy recorvery case too. > > I can not think of any depedency on post copy preempt channel which > > requires it to be initialised very early. May be Peter can confirm > > this. > > I guess that could work Currently all preempt code still assumes when postcopy activated it's in preempt mode. IIUC such a change will bring an extra phase of postcopy with no-preempt before preempt enabled. We may need to teach qemu to understand that if it's needed. Meanwhile the initial page requests will not be able to benefit from the new preempt channel too. > > > 3. Another thing we can do is to have 2-way handshake on every > > channel creation with some additional metadata, this to me looks > > like cleanest approach and durable, i understand that can break > > migration to/from old qemu, but then that can come as migration > > capability? > > The benefit of (1) is that the fix can be deployed for all existing > QEMU releases by backporting it. (3) will meanwhile need mgmt app > updates to make it work, which is much more work to deploy. > > We really shoulud have had a more formal handshake, and I've described > ways to achieve this in the past, but it is quite alot of work. I don't know whether (1) is a valid option if there are use cases that it cannot cover (on either tls or preempt). The handshake is definitely the clean approach. What's the outcome of such wrongly ordered connections? Will migration fail immediately and safely? For multifd, I think it should fail immediately after the connection established. For preempt, I'd also expect the same thing because the only wrong order to happen right now is having the preempt channel to be the migration channel, then it should also fail immediately on the first qemu_get_byte(). Hopefully that's still not too bad - I mean, if we can fail constantly and safely (never fail during postcopy), we can always retry and as long as connections created successfully we can start the migration safely. But please correct me if it's not the case. -- Peter Xu
Re: [PATCH v4 01/10] acpi/tests/avocado/bits: initial commit of test scripts that are run by biosbits
On 14/10/22 19:34, Ani Sinha wrote: This is initial commit of cpuid, acpi and smbios python test scripts for biosbits to execute. No change has been made to them from the original code written by the biosbits author Josh Triplett. They are required to be installed into the bits iso file and then run from within the virtual machine booted off with biosbits iso. The test scripts have a ".py2" extension in order to prevent avocado from loading them. They are written in python 2.7 and are run from within bios bits. There is no need for avocado to try to load them and call out errors on python3 specific syntaxes. The original location of these tests are here: https://github.com/biosbits/bits/blob/master/python/testacpi.py https://github.com/biosbits/bits/blob/master/python/smbios.py https://github.com/biosbits/bits/blob/master/python/testcpuid.py For QEMU, we maintain a fork of the above repo here with numerious fixes: https://gitlab.com/qemu-project/biosbits-bits The acpi test for example is maintained here in the fork: https://gitlab.com/qemu-project/biosbits-bits/-/raw/master/python/testacpi.py I missed the previous iterations of this series, and wonder why copy these files in QEMU repository if they already are in a forked repository. Why not add the fork as a submodule? Cc: Daniel P. Berrangé Cc: Paolo Bonzini Cc: Maydell Peter Cc: John Snow Cc: Thomas Huth Cc: Alex Bennée Cc: Igor Mammedov Cc: Michael Tsirkin Signed-off-by: Ani Sinha --- tests/avocado/acpi-bits/bits-tests/smbios.py2 | 2430 + .../avocado/acpi-bits/bits-tests/testacpi.py2 | 283 ++ .../acpi-bits/bits-tests/testcpuid.py2| 83 + 3 files changed, 2796 insertions(+) create mode 100644 tests/avocado/acpi-bits/bits-tests/smbios.py2 create mode 100644 tests/avocado/acpi-bits/bits-tests/testacpi.py2 create mode 100644 tests/avocado/acpi-bits/bits-tests/testcpuid.py2
Re: [PATCH 2/2] hw/audio/intel-hda: Drop unnecessary prototype
On 14/10/22 16:26, Peter Maydell wrote: The only use of intel_hda_reset() is after its definition, so we don't need to separately declare its prototype at the top of the file; drop the unnecessary line. Signed-off-by: Peter Maydell --- hw/audio/intel-hda.c | 2 -- 1 file changed, 2 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 1/2] hw/audio/intel-hda: don't reset codecs twice
On 14/10/22 16:26, Peter Maydell wrote: Currently the intel-hda device has a reset method which manually resets all the codecs by calling device_legacy_reset() on them. This means they get reset twice, once because child devices on a qbus get reset before the parent device's reset method is called, and then again because we're manually resetting them. Drop the manual reset call, and ensure that codecs are still reset when the guest does a reset via ICH6_GCTL_RESET by using device_cold_reset() (which resets all the devices on the qbus as well as the device itself) instead of a direct call to the reset function. This is a slight ordering change because the (only) codec reset now happens before the controller registers etc are reset, rather than once before and then once after, but the codec reset function hda_audio_reset() doesn't care. This lets us drop a use of device_legacy_reset(), which is deprecated. Signed-off-by: Peter Maydell --- hw/audio/intel-hda.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] input: Allow to choose console with qemu_input_is_absolute
On 14/10/22 13:54, Akihiko Odaki wrote: Although an input is routed depending on the console, qemu_input_is_absolute() had no mechanism to specify the console. Accept QemuConsole as an argument for qemu_input_is_absolute, and let the display know the absolute/relative state for a particular console. Signed-off-by: Akihiko Odaki --- include/ui/input.h | 2 +- ui/cocoa.m | 2 +- ui/dbus-console.c | 6 +++--- ui/gtk.c | 12 ++-- ui/input.c | 29 +++-- ui/sdl2.c | 26 +- ui/spice-input.c | 2 +- ui/trace-events| 1 - ui/vnc.c | 2 +- 9 files changed, 33 insertions(+), 49 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [RFC PATCH] virtio: re-order vm_running and use_started checks
On 14/10/22 15:21, Alex Bennée wrote: During migration the virtio device state can be restored before we restart the VM. As no devices can be running while the VM is paused it makes sense to bail out early in that case. This returns the order introduced in: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started) to what virtio-sock was doing longhand. Signed-off-by: Alex Bennée Cc: Christian Borntraeger --- include/hw/virtio/virtio.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v3 2/9] hw/{arm,ppc}: Resolve unreachable code
On 16/10/22 14:27, Bernhard Beschow wrote: pflash_cfi01_register() always returns with a non-NULL pointer (otherwise it would crash internally). Therefore, the bodies of the if-statements are unreachable. This is true, pflash_cfi0X_register() use an hardcoded _fatal. Shouldn't it be better to pass an Error* argument? From the pflash API perspective I don't see much value in returning a PFlashCFI0X type instead of a simple DeviceState (but this is another story...). Signed-off-by: Bernhard Beschow --- hw/arm/gumstix.c | 18 ++ hw/arm/mainstone.c | 13 + hw/arm/omap_sx1.c| 22 -- hw/arm/versatilepb.c | 6 ++ hw/arm/z2.c | 9 +++-- hw/ppc/sam460ex.c| 12 6 files changed, 28 insertions(+), 52 deletions(-)
Re: [PATCH] tcg/aarch64: Remove unused code in tcg_out_op
On 17/10/22 04:08, Qi Hu wrote: AArch64 defines the TCG_TARGET_HAS_direct_jump. So the "else" block is useless in the case of "INDEX_op_goto_tb" in function "tcg_out_op". Add an assertion and delete these codes for clarity. Suggested-by: WANG Xuerui Signed-off-by: Qi Hu --- tcg/aarch64/tcg-target.c.inc | 31 ++- 1 file changed, 14 insertions(+), 17 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
[PATCH v4] m68k: write bootinfo as rom section and re-randomize on reboot
Rather than poking directly into RAM, add the bootinfo block as a proper
ROM, so that it's restored when rebooting the system. This way, if the
guest corrupts any of the bootinfo items, but then tries to reboot,
it'll still be restored back to normal as expected.
Then, since the RNG seed needs to be fresh on each boot, regenerate the
RNG seed in the ROM when reseting the CPU.
Cc: Geert Uytterhoeven
Cc: Laurent Vivier
Signed-off-by: Jason A. Donenfeld
---
hw/m68k/bootinfo.h | 48 +++
hw/m68k/q800.c | 71 +-
hw/m68k/virt.c | 51 +++--
3 files changed, 111 insertions(+), 59 deletions(-)
diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
index 897162b818..67e6b66b7d 100644
--- a/hw/m68k/bootinfo.h
+++ b/hw/m68k/bootinfo.h
@@ -12,66 +12,66 @@
#ifndef HW_M68K_BOOTINFO_H
#define HW_M68K_BOOTINFO_H
-#define BOOTINFO0(as, base, id) \
+#define BOOTINFO0(base, id) \
do { \
-stw_phys(as, base, id); \
+stw_p(base, id); \
base += 2; \
-stw_phys(as, base, sizeof(struct bi_record)); \
+stw_p(base, sizeof(struct bi_record)); \
base += 2; \
} while (0)
-#define BOOTINFO1(as, base, id, value) \
+#define BOOTINFO1(base, id, value) \
do { \
-stw_phys(as, base, id); \
+stw_p(base, id); \
base += 2; \
-stw_phys(as, base, sizeof(struct bi_record) + 4); \
+stw_p(base, sizeof(struct bi_record) + 4); \
base += 2; \
-stl_phys(as, base, value); \
+stl_p(base, value); \
base += 4; \
} while (0)
-#define BOOTINFO2(as, base, id, value1, value2) \
+#define BOOTINFO2(base, id, value1, value2) \
do { \
-stw_phys(as, base, id); \
+stw_p(base, id); \
base += 2; \
-stw_phys(as, base, sizeof(struct bi_record) + 8); \
+stw_p(base, sizeof(struct bi_record) + 8); \
base += 2; \
-stl_phys(as, base, value1); \
+stl_p(base, value1); \
base += 4; \
-stl_phys(as, base, value2); \
+stl_p(base, value2); \
base += 4; \
} while (0)
-#define BOOTINFOSTR(as, base, id, string) \
+#define BOOTINFOSTR(base, id, string) \
do { \
int i; \
-stw_phys(as, base, id); \
+stw_p(base, id); \
base += 2; \
-stw_phys(as, base, \
+stw_p(base, \
(sizeof(struct bi_record) + strlen(string) + \
1 /* null termination */ + 3 /* padding */) & ~3); \
base += 2; \
for (i = 0; string[i]; i++) { \
-stb_phys(as, base++, string[i]); \
+stb_p(base++, string[i]); \
} \
-stb_phys(as, base++, 0); \
-base = (base + 3) & ~3; \
+stb_p(base++, 0); \
+base = (void *)(((uintptr_t)base + 3) & ~3); \
} while (0)
-#define BOOTINFODATA(as, base, id, data, len) \
+#define BOOTINFODATA(base, id, data, len) \
do { \
int i; \
-stw_phys(as, base, id); \
+stw_p(base, id); \
base += 2; \
-stw_phys(as, base, \
+stw_p(base, \
(sizeof(struct bi_record) + len + \
2 /* length field */ + 3 /* padding */) & ~3); \
base += 2; \
-stw_phys(as, base, len); \
+stw_p(base, len); \
base += 2; \
for (i = 0; i < len; ++i) { \
-stb_phys(as, base++, data[i]); \
+stb_p(base++, data[i]); \
} \
-base = (base + 3) & ~3; \
+base = (void *)(((uintptr_t)base + 3) & ~3); \
} while (0)
#endif
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index a4590c2cb0..e09e244ddc 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -321,11 +321,22 @@ static const TypeInfo glue_info = {
},
};
+typedef struct {
+M68kCPU *cpu;
+struct bi_record *rng_seed;
+} ResetInfo;
+
static void main_cpu_reset(void *opaque)
{
-M68kCPU *cpu = opaque;
+ResetInfo *reset_info = opaque;
+M68kCPU *cpu = reset_info->cpu;
CPUState *cs = CPU(cpu);
+if (reset_info->rng_seed) {
+qemu_guest_getrandom_nofail((void *)reset_info->rng_seed->data + 2,
+be16_to_cpu(*(uint16_t *)reset_info->rng_seed->data));
+}
+
cpu_reset(cs);
cpu->env.aregs[7] = ldl_phys(cs->as, 0);
cpu->env.pc = ldl_phys(cs->as, 4);
@@ -386,6 +397,7 @@ static void q800_init(MachineState *machine)
NubusBus *nubus;
DeviceState *glue;
DriveInfo *dinfo;
+ResetInfo *reset_info;
uint8_t rng_seed[32];
linux_boot = (kernel_filename != NULL);
@@ -396,9 +408,12 @@ static void q800_init(MachineState *machine)
exit(1);
}
+reset_info = g_new0(ResetInfo, 1);
+
/* init CPUs */
cpu = M68K_CPU(cpu_create(machine->cpu_type));
-qemu_register_reset(main_cpu_reset, cpu);
+reset_info->cpu = cpu;
+qemu_register_reset(main_cpu_reset, reset_info);
[PATCH] MAINTAINERS: Replace my amsat.org email address
The amsat.org domain is having issues with DMARC / SPF / DKIM: https://lore.kernel.org/qemu-devel/CAMVc7JUy5NeEN0q=4zfZvn_rppgqn9wicV1z=tsluhks3ry...@mail.gmail.com/ Consolidate all of my MAINTAINERS entries on my work address. Signed-off-by: Philippe Mathieu-Daudé --- .mailmap| 4 +++- MAINTAINERS | 62 ++--- 2 files changed, 34 insertions(+), 32 deletions(-) diff --git a/.mailmap b/.mailmap index 1f7319b70b..35dddbe27b 100644 --- a/.mailmap +++ b/.mailmap @@ -70,7 +70,9 @@ Paul Burton Paul Burton Paul Burton Paul Burton -Philippe Mathieu-Daudé +Philippe Mathieu-Daudé +Philippe Mathieu-Daudé +Philippe Mathieu-Daudé Stefan Brankovic Yongbok Kim diff --git a/MAINTAINERS b/MAINTAINERS index 8ae2e43c83..f169fec6fc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -110,7 +110,7 @@ T: git https://gitlab.com/cohuck/qemu.git s390-next L: qemu-s3...@nongnu.org MIPS general architecture support -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé R: Jiaxun Yang S: Odd Fixes K: ^Subject:.*(?i)mips @@ -233,7 +233,7 @@ F: tests/docker/dockerfiles/debian-microblaze-cross.d/build-toolchain.sh F: tests/tcg/nios2/Makefile.target MIPS TCG CPUs -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé R: Aurelien Jarno R: Jiaxun Yang R: Aleksandar Rikalo @@ -550,7 +550,7 @@ X: qga/*win32* F: qemu.nsi Darwin (macOS, iOS) -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Odd Fixes F: .gitlab-ci.d/cirrus/macos-* F: */*.m @@ -681,7 +681,7 @@ F: include/hw/rtc/goldfish_rtc.h Gumstix M: Peter Maydell -R: Philippe Mathieu-Daudé +R: Philippe Mathieu-Daudé L: qemu-...@nongnu.org S: Odd Fixes F: hw/arm/gumstix.c @@ -832,7 +832,7 @@ F: docs/system/arm/palm.rst Raspberry Pi M: Peter Maydell -R: Philippe Mathieu-Daudé +R: Philippe Mathieu-Daudé L: qemu-...@nongnu.org S: Odd Fixes F: hw/arm/raspi.c @@ -1095,7 +1095,7 @@ F: include/hw/misc/avr_power.h F: hw/misc/avr_power.c Arduino -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Maintained F: hw/avr/arduino.c @@ -1210,7 +1210,7 @@ F: hw/microblaze/petalogix_ml605_mmu.c MIPS Machines - Overall MIPS Machines -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Odd Fixes F: configs/devices/mips*/* F: hw/mips/ @@ -1225,7 +1225,7 @@ F: hw/display/jazz_led.c F: hw/dma/rc4030.c Malta -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé R: Aurelien Jarno S: Odd Fixes F: hw/isa/piix4.c @@ -1244,7 +1244,7 @@ F: hw/net/mipsnet.c Fuloong 2E M: Huacai Chen -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé R: Jiaxun Yang S: Odd Fixes F: hw/mips/fuloong2e.c @@ -1700,7 +1700,7 @@ F: pc-bios/bios-microvm.bin Machine core M: Eduardo Habkost M: Marcel Apfelbaum -R: Philippe Mathieu-Daudé +R: Philippe Mathieu-Daudé R: Yanan Wang S: Supported F: cpu.c @@ -1893,7 +1893,7 @@ F: docs/virtio-net-failover.rst T: git https://github.com/jasowang/qemu.git net Parallel NOR Flash devices -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé T: git https://gitlab.com/philmd/qemu.git pflash-next S: Maintained F: hw/block/pflash_cfi*.c @@ -1926,7 +1926,7 @@ S: Maintained F: hw/ssi/xilinx_* SD (Secure Card) -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé M: Bin Meng L: qemu-bl...@nongnu.org S: Odd Fixes @@ -2233,14 +2233,14 @@ F: tests/qtest/vmgenid-test.c F: stubs/vmgenid.c LED -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Maintained F: include/hw/misc/led.h F: hw/misc/led.c Unimplemented device M: Peter Maydell -R: Philippe Mathieu-Daudé +R: Philippe Mathieu-Daudé R: Ani Sinha S: Maintained F: include/hw/misc/unimp.h @@ -2248,7 +2248,7 @@ F: hw/misc/unimp.c Empty slot M: Artyom Tarasenko -R: Philippe Mathieu-Daudé +R: Philippe Mathieu-Daudé R: Ani Sinha S: Maintained F: include/hw/misc/empty_slot.h @@ -2312,13 +2312,13 @@ F: qemu-edid.c PIIX4 South Bridge (i82371AB) M: Hervé Poussineau -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Maintained F: hw/isa/piix4.c F: include/hw/southbridge/piix.h Firmware configuration (fw_cfg) -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé R: Gerd Hoffmann S: Supported F: docs/specs/fw_cfg.txt @@ -2374,13 +2374,13 @@ F: hw/intc/openpic.c F: include/hw/ppc/openpic.h MIPS CPS -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Odd Fixes F: hw/misc/mips_* F: include/hw/misc/mips_* MIPS GIC -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé S: Odd Fixes F: hw/intc/mips_gic.c F: hw/timer/mips_gictimer.c @@ -2462,7 +2462,7 @@ F: audio/alsaaudio.c Core Audio framework backend M: Gerd Hoffmann -M: Philippe Mathieu-Daudé +M: Philippe Mathieu-Daudé R: Christian Schoenebeck R: Akihiko Odaki S: Odd Fixes @@ -2687,7 +2687,7 @@ F: scripts/coccinelle/errp-guard.cocci GDB stub M: Alex Bennée -R: Philippe Mathieu-Daudé +R: Philippe Mathieu-Daudé S:
[PULL 34/38] hw/ppc: set machine->fdt in pegasos2_machine_reset()
We'll introduce a QMP/HMP command that requires machine->fdt to be set properly. Cc: BALATON Zoltan Cc: qemu-...@nongnu.org Reviewed-by: BALATON Zoltan Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Daniel Henrique Barboza Message-Id: <20220926173855.1159396-12-danielhb...@gmail.com> --- hw/ppc/pegasos2.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c index 61f4263953..ecf682b148 100644 --- a/hw/ppc/pegasos2.c +++ b/hw/ppc/pegasos2.c @@ -331,6 +331,10 @@ static void pegasos2_machine_reset(MachineState *machine) vof_build_dt(fdt, pm->vof); vof_client_open_store(fdt, pm->vof, "/chosen", "stdout", "/failsafe"); + +/* Set machine->fdt for 'dumpdtb' QMP/HMP command */ +machine->fdt = fdt; + pm->cpu->vhyp = PPC_VIRTUAL_HYPERVISOR(machine); } -- 2.37.3
[PULL 38/38] hw/riscv: set machine->fdt in spike_board_init()
This will enable support for the 'dumpdtb' QMP/HMP command for the spike
machine.
Cc: Palmer Dabbelt
Cc: Alistair Francis
Cc: Bin Meng
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-16-danielhb...@gmail.com>
---
hw/riscv/spike.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 5ba34543c8..1e1d752c00 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -40,6 +40,8 @@
#include "sysemu/device_tree.h"
#include "sysemu/sysemu.h"
+#include
+
static const MemMapEntry spike_memmap[] = {
[SPIKE_MROM] = { 0x1000, 0xf000 },
[SPIKE_HTIF] = { 0x100, 0x1000 },
@@ -304,6 +306,10 @@ static void spike_board_init(MachineState *machine)
/* Compute the fdt load address in dram */
fdt_load_addr = riscv_load_fdt(memmap[SPIKE_DRAM].base,
machine->ram_size, s->fdt);
+
+/* Set machine->fdt for 'dumpdtb' QMP/HMP command */
+machine->fdt = s->fdt;
+
/* load the reset vector */
riscv_setup_rom_reset_vec(machine, >soc[0], memmap[SPIKE_DRAM].base,
memmap[SPIKE_MROM].base,
--
2.37.3
[PULL 28/38] hw/ppc/spapr_pci.c: Use device_cold_reset() rather than device_legacy_reset()
From: Peter Maydell
In spapr_phb_children_reset() we call device_legacy_reset() to reset any
QOM children of the SPAPR PCI host bridge device. This will not reset
any qbus such a child might own. Switch to device_cold_reset(), which will
reset both the device and its buses. (If the child has no qbuses then
there will be no change in behaviour.)
Signed-off-by: Peter Maydell
Reviewed-by: Cédric Le Goater
Reviewed-by: Daniel Henrique Barboza
Message-Id: <20221014142841.2092784-1-peter.mayd...@linaro.org>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/spapr_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 57c8a4f085..7b7618d5da 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -2045,7 +2045,7 @@ static int spapr_phb_children_reset(Object *child, void
*opaque)
DeviceState *dev = (DeviceState *) object_dynamic_cast(child, TYPE_DEVICE);
if (dev) {
-device_legacy_reset(dev);
+device_cold_reset(dev);
}
return 0;
--
2.37.3
[PULL 32/38] hw/ppc: set machine->fdt in sam460ex_load_device_tree()
This will enable support for 'dumpdtb' QMP/HMP command for the sam460ex
machine.
Setting machine->fdt requires a MachineState pointer to be used inside
sam460ex_load_device_tree(). Let's change the function to receive this
pointer from the caller. 'ramsize' and 'kernel_cmdline' can be retrieved
directly from the 'machine' pointer.
Reviewed-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-10-danielhb...@gmail.com>
---
hw/ppc/sam460ex.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index f03cdc9ecc..4a22ce3761 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -123,13 +123,12 @@ static int sam460ex_load_uboot(void)
return 0;
}
-static int sam460ex_load_device_tree(hwaddr addr,
- uint32_t ramsize,
+static int sam460ex_load_device_tree(MachineState *machine,
+ hwaddr addr,
hwaddr initrd_base,
- hwaddr initrd_size,
- const char *kernel_cmdline)
+ hwaddr initrd_size)
{
-uint32_t mem_reg_property[] = { 0, 0, cpu_to_be32(ramsize) };
+uint32_t mem_reg_property[] = { 0, 0, cpu_to_be32(machine->ram_size) };
char *filename;
int fdt_size;
void *fdt;
@@ -163,7 +162,8 @@ static int sam460ex_load_device_tree(hwaddr addr,
qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end",
(initrd_base + initrd_size));
-qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", kernel_cmdline);
+qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
+machine->kernel_cmdline);
/* Copy data from the host device tree into the guest. Since the guest can
* directly access the timebase without host involvement, we must expose
@@ -200,7 +200,9 @@ static int sam460ex_load_device_tree(hwaddr addr,
EBC_FREQ);
rom_add_blob_fixed(BINARY_DEVICE_TREE_FILE, fdt, fdt_size, addr);
-g_free(fdt);
+
+/* Set machine->fdt for 'dumpdtb' QMP/HMP command */
+machine->fdt = fdt;
return fdt_size;
}
@@ -500,9 +502,8 @@ static void sam460ex_init(MachineState *machine)
if (machine->kernel_filename) {
int dt_size;
-dt_size = sam460ex_load_device_tree(FDT_ADDR, machine->ram_size,
-RAMDISK_ADDR, initrd_size,
-machine->kernel_cmdline);
+dt_size = sam460ex_load_device_tree(machine, FDT_ADDR,
+RAMDISK_ADDR, initrd_size);
boot_info->dt_base = FDT_ADDR;
boot_info->dt_size = dt_size;
--
2.37.3
[PULL 26/38] hw/ppc/e500: Remove if statement which is now always true
From: Bernhard Beschow
Now that the MPC8544DS board also has a platform bus, the if statement
is always true.
Signed-off-by: Bernhard Beschow
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20221003203142.24355-8-shen...@gmail.com>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/e500.c | 30 ++
hw/ppc/e500.h | 1 -
hw/ppc/e500plat.c | 1 -
hw/ppc/mpc8544ds.c | 1 -
4 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 496c61b612..3e950ea3ba 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -1007,25 +1007,23 @@ void ppce500_init(MachineState *machine)
}
/* Platform Bus Device */
-if (pmc->has_platform_bus) {
-dev = qdev_new(TYPE_PLATFORM_BUS_DEVICE);
-dev->id = g_strdup(TYPE_PLATFORM_BUS_DEVICE);
-qdev_prop_set_uint32(dev, "num_irqs", pmc->platform_bus_num_irqs);
-qdev_prop_set_uint32(dev, "mmio_size", pmc->platform_bus_size);
-sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
-pms->pbus_dev = PLATFORM_BUS_DEVICE(dev);
-
-s = SYS_BUS_DEVICE(pms->pbus_dev);
-for (i = 0; i < pmc->platform_bus_num_irqs; i++) {
-int irqn = pmc->platform_bus_first_irq + i;
-sysbus_connect_irq(s, i, qdev_get_gpio_in(mpicdev, irqn));
-}
+dev = qdev_new(TYPE_PLATFORM_BUS_DEVICE);
+dev->id = g_strdup(TYPE_PLATFORM_BUS_DEVICE);
+qdev_prop_set_uint32(dev, "num_irqs", pmc->platform_bus_num_irqs);
+qdev_prop_set_uint32(dev, "mmio_size", pmc->platform_bus_size);
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+pms->pbus_dev = PLATFORM_BUS_DEVICE(dev);
-memory_region_add_subregion(address_space_mem,
-pmc->platform_bus_base,
->pbus_dev->mmio);
+s = SYS_BUS_DEVICE(pms->pbus_dev);
+for (i = 0; i < pmc->platform_bus_num_irqs; i++) {
+int irqn = pmc->platform_bus_first_irq + i;
+sysbus_connect_irq(s, i, qdev_get_gpio_in(mpicdev, irqn));
}
+memory_region_add_subregion(address_space_mem,
+pmc->platform_bus_base,
+>pbus_dev->mmio);
+
/*
* Smart firmware defaults ahead!
*
diff --git a/hw/ppc/e500.h b/hw/ppc/e500.h
index 1e5853b032..68f754ce50 100644
--- a/hw/ppc/e500.h
+++ b/hw/ppc/e500.h
@@ -27,7 +27,6 @@ struct PPCE500MachineClass {
int mpic_version;
bool has_mpc8xxx_gpio;
-bool has_platform_bus;
hwaddr platform_bus_base;
hwaddr platform_bus_size;
int platform_bus_first_irq;
diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index fc911bbb7b..5bb1c603da 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -86,7 +86,6 @@ static void e500plat_machine_class_init(ObjectClass *oc, void
*data)
pmc->fixup_devtree = e500plat_fixup_devtree;
pmc->mpic_version = OPENPIC_MODEL_FSL_MPIC_42;
pmc->has_mpc8xxx_gpio = true;
-pmc->has_platform_bus = true;
pmc->platform_bus_base = 0xfULL;
pmc->platform_bus_size = 128 * MiB;
pmc->platform_bus_first_irq = 5;
diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
index 9c81477698..7dd5219736 100644
--- a/hw/ppc/mpc8544ds.c
+++ b/hw/ppc/mpc8544ds.c
@@ -46,7 +46,6 @@ static void mpc8544ds_machine_class_init(ObjectClass *oc,
void *data)
pmc->pci_nr_slots = 2;
pmc->fixup_devtree = mpc8544ds_fixup_devtree;
pmc->mpic_version = OPENPIC_MODEL_FSL_MPIC_20;
-pmc->has_platform_bus = true;
pmc->platform_bus_base = 0xFF80ULL;
pmc->platform_bus_size = 8 * MiB;
pmc->platform_bus_first_irq = 5;
--
2.37.3
[PULL 21/38] hw/gpio/meson: Introduce dedicated config switch for hw/gpio/mpc8xxx
From: Bernhard Beschow
Having a dedicated config switch makes dependency handling cleaner.
Signed-off-by: Bernhard Beschow
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20221003203142.24355-3-shen...@gmail.com>
Signed-off-by: Daniel Henrique Barboza
---
hw/gpio/Kconfig | 3 +++
hw/gpio/meson.build | 2 +-
hw/ppc/Kconfig | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig
index f0e7405f6e..d2cf3accc8 100644
--- a/hw/gpio/Kconfig
+++ b/hw/gpio/Kconfig
@@ -8,6 +8,9 @@ config PL061
config GPIO_KEY
bool
+config GPIO_MPC8XXX
+bool
+
config GPIO_PWR
bool
diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build
index 7bd6a57264..b726e6d27a 100644
--- a/hw/gpio/meson.build
+++ b/hw/gpio/meson.build
@@ -1,5 +1,5 @@
-softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c'))
softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c'))
+softmmu_ss.add(when: 'CONFIG_GPIO_MPC8XXX', if_true: files('mpc8xxx.c'))
softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c'))
softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c'))
softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c'))
diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
index 22a64745d4..791fe78a50 100644
--- a/hw/ppc/Kconfig
+++ b/hw/ppc/Kconfig
@@ -124,6 +124,7 @@ config E500
imply AT24C
imply VIRTIO_PCI
select ETSEC
+select GPIO_MPC8XXX
select OPENPIC
select PLATFORM_BUS
select PPCE500_PCI
--
2.37.3
[PULL 33/38] hw/ppc: set machine->fdt in xilinx_load_device_tree()
This will enable support for 'dumpdtb' QMP/HMP command for the
virtex_ml507 machine.
Setting machine->fdt requires a MachineState pointer to be used inside
xilinx_load_device_tree(). Let's change the function to receive this
pointer from the caller. kernel_cmdline' can be retrieved directly from
the 'machine' pointer. 'ramsize' wasn't being used so can be removed.
Cc: Edgar E. Iglesias
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-11-danielhb...@gmail.com>
---
hw/ppc/virtex_ml507.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c
index 493ea0c19f..13cace229b 100644
--- a/hw/ppc/virtex_ml507.c
+++ b/hw/ppc/virtex_ml507.c
@@ -45,6 +45,8 @@
#include "hw/qdev-properties.h"
#include "ppc405.h"
+#include
+
#define EPAPR_MAGIC(0x45504150)
#define FLASH_SIZE (16 * MiB)
@@ -144,11 +146,10 @@ static void main_cpu_reset(void *opaque)
}
#define BINARY_DEVICE_TREE_FILE "virtex-ml507.dtb"
-static int xilinx_load_device_tree(hwaddr addr,
- uint32_t ramsize,
- hwaddr initrd_base,
- hwaddr initrd_size,
- const char *kernel_cmdline)
+static int xilinx_load_device_tree(MachineState *machine,
+ hwaddr addr,
+ hwaddr initrd_base,
+ hwaddr initrd_size)
{
char *path;
int fdt_size;
@@ -190,18 +191,21 @@ static int xilinx_load_device_tree(hwaddr addr,
error_report("couldn't set /chosen/linux,initrd-end");
}
-r = qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", kernel_cmdline);
+r = qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
+machine->kernel_cmdline);
if (r < 0)
fprintf(stderr, "couldn't set /chosen/bootargs\n");
cpu_physical_memory_write(addr, fdt, fdt_size);
-g_free(fdt);
+
+/* Set machine->fdt for 'dumpdtb' QMP/HMP command */
+machine->fdt = fdt;
+
return fdt_size;
}
static void virtex_init(MachineState *machine)
{
const char *kernel_filename = machine->kernel_filename;
-const char *kernel_cmdline = machine->kernel_cmdline;
hwaddr initrd_base = 0;
int initrd_size = 0;
MemoryRegion *address_space_mem = get_system_memory();
@@ -294,9 +298,8 @@ static void virtex_init(MachineState *machine)
boot_info.fdt = high + (8192 * 2);
boot_info.fdt &= ~8191;
-xilinx_load_device_tree(boot_info.fdt, machine->ram_size,
-initrd_base, initrd_size,
-kernel_cmdline);
+xilinx_load_device_tree(machine, boot_info.fdt,
+initrd_base, initrd_size);
}
env->load_info = _info;
}
--
2.37.3
[PULL 37/38] hw/riscv: set machine->fdt in sifive_u_machine_init()
This will enable support for 'dumpdtb' QMP/HMP command for the sifive_u
machine.
Cc: Alistair Francis
Cc: Bin Meng
Cc: Palmer Dabbelt
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-15-danielhb...@gmail.com>
---
hw/riscv/sifive_u.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index e4c814a3ea..b139824aab 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -634,6 +634,9 @@ static void sifive_u_machine_init(MachineState *machine)
start_addr_hi32 = (uint64_t)start_addr >> 32;
}
+/* Set machine->fdt for 'dumpdtb' QMP/HMP command */
+machine->fdt = s->fdt;
+
/* reset vector */
uint32_t reset_vec[12] = {
s->msel, /* MSEL pin state */
--
2.37.3
[PULL 30/38] hw/nios2: set machine->fdt in nios2_load_dtb()
This will enable support for 'dumpdtb' QMP/HMP command for all nios2
machines that uses nios2_load_dtb().
Cc: Chris Wulff
Cc: Marek Vasut
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-7-danielhb...@gmail.com>
---
hw/nios2/boot.c | 8 +++-
hw/nios2/meson.build | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
index 21cb47..b30a7b1efb 100644
--- a/hw/nios2/boot.c
+++ b/hw/nios2/boot.c
@@ -43,6 +43,8 @@
#include "boot.h"
+#include
+
#define NIOS2_MAGIC0x534f494e
static struct nios2_boot_info {
@@ -81,6 +83,7 @@ static uint64_t translate_kernel_address(void *opaque,
uint64_t addr)
static int nios2_load_dtb(struct nios2_boot_info bi, const uint32_t ramsize,
const char *kernel_cmdline, const char *dtb_filename)
{
+MachineState *machine = MACHINE(qdev_get_machine());
int fdt_size;
void *fdt = NULL;
int r;
@@ -113,7 +116,10 @@ static int nios2_load_dtb(struct nios2_boot_info bi, const
uint32_t ramsize,
}
cpu_physical_memory_write(bi.fdt, fdt, fdt_size);
-g_free(fdt);
+
+/* Set machine->fdt for 'dumpdtb' QMP/HMP command */
+machine->fdt = fdt;
+
return fdt_size;
}
diff --git a/hw/nios2/meson.build b/hw/nios2/meson.build
index 6c58e8082b..22277bd6c5 100644
--- a/hw/nios2/meson.build
+++ b/hw/nios2/meson.build
@@ -1,5 +1,5 @@
nios2_ss = ss.source_set()
-nios2_ss.add(files('boot.c'))
+nios2_ss.add(files('boot.c'), fdt)
nios2_ss.add(when: 'CONFIG_NIOS2_10M50', if_true: files('10m50_devboard.c'))
nios2_ss.add(when: 'CONFIG_NIOS2_GENERIC_NOMMU', if_true:
files('generic_nommu.c'))
--
2.37.3
[PULL 16/38] ppc440_sdram: Move RAM size check to ppc440_sdram_init
From: BALATON Zoltan
Move the check for valid memory sizes from board to sdram controller
init. This adds the missing valid memory sizes of 16 and 8 MiB to the
DoC and the board now only checks for additional restrictions imposed
by its firmware then sdram init checks for valid sizes for SoC.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<41da3797392acaacc7963b79512c8af8005fa4b0.1664021647.git.bala...@eik.bme.hu>
[danielhb: avoid 4*GiB size due to 32 bit build problems]
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440.h| 4 ++--
hw/ppc/ppc440_uc.c | 19 +++
hw/ppc/sam460ex.c | 32 +---
3 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/hw/ppc/ppc440.h b/hw/ppc/ppc440.h
index 01d76b8000..29f6f14ed7 100644
--- a/hw/ppc/ppc440.h
+++ b/hw/ppc/ppc440.h
@@ -11,13 +11,13 @@
#ifndef PPC440_H
#define PPC440_H
-#include "hw/ppc/ppc4xx.h"
+#include "hw/ppc/ppc.h"
void ppc4xx_l2sram_init(CPUPPCState *env);
void ppc4xx_cpr_init(CPUPPCState *env);
void ppc4xx_sdr_init(CPUPPCState *env);
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- Ppc4xxSdramBank *ram_banks);
+ MemoryRegion *ram);
void ppc4xx_ahb_init(CPUPPCState *env);
void ppc4xx_dma_init(CPUPPCState *env, int dcr_base);
void ppc460ex_pcie_init(CPUPPCState *env);
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index edd0781eb7..dd873d892c 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -487,7 +487,7 @@ void ppc4xx_sdr_init(CPUPPCState *env)
typedef struct ppc440_sdram_t {
uint32_t addr;
uint32_t mcopt2;
-int nbanks;
+int nbanks; /* Banks to use from the 4, e.g. when board has less slots */
Ppc4xxSdramBank bank[4];
} ppc440_sdram_t;
@@ -733,18 +733,21 @@ static void sdram_ddr2_reset(void *opaque)
}
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- Ppc4xxSdramBank *ram_banks)
+ MemoryRegion *ram)
{
ppc440_sdram_t *s;
-int i;
+/*
+ * SoC also has 4 GiB but that causes problem with 32 bit
+ * builds (4*GiB overflows the 32 bit ram_addr_t).
+ */
+const ram_addr_t valid_bank_sizes[] = {
+2 * GiB, 1 * GiB, 512 * MiB, 256 * MiB, 128 * MiB,
+64 * MiB, 32 * MiB, 16 * MiB, 8 * MiB, 0
+};
s = g_malloc0(sizeof(*s));
s->nbanks = nbanks;
-for (i = 0; i < nbanks; i++) {
-s->bank[i].ram = ram_banks[i].ram;
-s->bank[i].base = ram_banks[i].base;
-s->bank[i].size = ram_banks[i].size;
-}
+ppc4xx_sdram_banks(ram, s->nbanks, s->bank, valid_bank_sizes);
qemu_register_reset(_ddr2_reset, s);
ppc_dcr_register(env, SDRAM0_CFGADDR,
s, _ddr2_dcr_read, _ddr2_dcr_write);
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index b318521b01..13055a8916 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -74,13 +74,6 @@
#define EBC_FREQ 11500
#define UART_FREQ 11059200
-/* The SoC could also handle 4 GiB but firmware does not work with that. */
-/* Maybe it overflows a signed 32 bit number somewhere? */
-static const ram_addr_t ppc460ex_sdram_bank_sizes[] = {
-2 * GiB, 1 * GiB, 512 * MiB, 256 * MiB, 128 * MiB, 64 * MiB,
-32 * MiB, 0
-};
-
struct boot_info {
uint32_t dt_base;
uint32_t dt_size;
@@ -273,7 +266,6 @@ static void sam460ex_init(MachineState *machine)
{
MemoryRegion *address_space_mem = get_system_memory();
MemoryRegion *isa = g_new(MemoryRegion, 1);
-Ppc4xxSdramBank *ram_banks = g_new0(Ppc4xxSdramBank, 1);
MemoryRegion *l2cache_ram = g_new(MemoryRegion, 1);
DeviceState *uic[4];
int i;
@@ -340,12 +332,22 @@ static void sam460ex_init(MachineState *machine)
}
/* SDRAM controller */
-/* put all RAM on first bank because board has one slot
- * and firmware only checks that */
-ppc4xx_sdram_banks(machine->ram, 1, ram_banks, ppc460ex_sdram_bank_sizes);
-
+/* The SoC could also handle 4 GiB but firmware does not work with that. */
+if (machine->ram_size > 2 * GiB) {
+error_report("Memory over 2 GiB is not supported");
+exit(1);
+}
+/* Firmware needs at least 64 MiB */
+if (machine->ram_size < 64 * MiB) {
+error_report("Memory below 64 MiB is not supported");
+exit(1);
+}
+/*
+ * Put all RAM on first bank because board has one slot
+ * and firmware only checks that
+ */
+ppc440_sdram_init(env, 1, machine->ram);
/* FIXME: does 460EX have ECC interrupts? */
-ppc440_sdram_init(env, 1, ram_banks);
/* Enable SDRAM memory regions as we may boot without firmware */
ppc4xx_sdram_ddr2_enable(env);
@@ -354,8 +356,8 @@ static void sam460ex_init(MachineState *machine)
qdev_get_gpio_in(uic[0], 2));
i2c = PPC4xx_I2C(dev)->bus;
/* SPD EEPROM on RAM module */
-spd_data =
[PULL 13/38] ppc440_sdram: Get rid of the init RAM hack
From: BALATON Zoltan
Remove the do_init parameter of ppc440_sdram_init and enable SDRAM
controller from the board. Firmware does this so it may only be needed
when booting with -kernel without firmware but we enable SDRAM
unconditionally to preserve previous behaviour.
Signed-off-by: BALATON Zoltan
Reviewed-by: Daniel Henrique Barboza
Message-Id:
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440.h | 3 +--
hw/ppc/ppc440_uc.c | 15 +--
hw/ppc/sam460ex.c | 4 +++-
include/hw/ppc/ppc4xx.h | 2 ++
4 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/hw/ppc/ppc440.h b/hw/ppc/ppc440.h
index e6c905b7d6..01d76b8000 100644
--- a/hw/ppc/ppc440.h
+++ b/hw/ppc/ppc440.h
@@ -17,8 +17,7 @@ void ppc4xx_l2sram_init(CPUPPCState *env);
void ppc4xx_cpr_init(CPUPPCState *env);
void ppc4xx_sdr_init(CPUPPCState *env);
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- Ppc4xxSdramBank *ram_banks,
- int do_init);
+ Ppc4xxSdramBank *ram_banks);
void ppc4xx_ahb_init(CPUPPCState *env);
void ppc4xx_dma_init(CPUPPCState *env, int dcr_base);
void ppc460ex_pcie_init(CPUPPCState *env);
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 3fbfe4ad13..e8bc088c8f 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -16,6 +16,7 @@
#include "qemu/module.h"
#include "hw/irq.h"
#include "exec/memory.h"
+#include "cpu.h"
#include "hw/ppc/ppc4xx.h"
#include "hw/qdev-properties.h"
#include "hw/pci/pci.h"
@@ -727,12 +728,11 @@ static void sdram_reset(void *opaque)
ppc440_sdram_t *sdram = opaque;
sdram->addr = 0;
-sdram->mcopt2 = SDRAM_DDR2_MCOPT2_DCEN;
+sdram->mcopt2 = 0;
}
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- Ppc4xxSdramBank *ram_banks,
- int do_init)
+ Ppc4xxSdramBank *ram_banks)
{
ppc440_sdram_t *sdram;
int i;
@@ -749,9 +749,6 @@ void ppc440_sdram_init(CPUPPCState *env, int nbanks,
sdram, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM0_CFGDATA,
sdram, _read_sdram, _write_sdram);
-if (do_init) {
-sdram_map_bcr(sdram);
-}
ppc_dcr_register(env, SDRAM_R0BAS,
sdram, _read_sdram, _write_sdram);
@@ -773,6 +770,12 @@ void ppc440_sdram_init(CPUPPCState *env, int nbanks,
sdram, _read_sdram, _write_sdram);
}
+void ppc440_sdram_enable(CPUPPCState *env)
+{
+ppc_dcr_write(env->dcr_env, SDRAM0_CFGADDR, 0x21);
+ppc_dcr_write(env->dcr_env, SDRAM0_CFGDATA, 0x0800);
+}
+
/*/
/* PLB to AHB bridge */
enum {
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index f4c2a693fb..9c01211b20 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -345,7 +345,9 @@ static void sam460ex_init(MachineState *machine)
ppc4xx_sdram_banks(machine->ram, 1, ram_banks, ppc460ex_sdram_bank_sizes);
/* FIXME: does 460EX have ECC interrupts? */
-ppc440_sdram_init(env, 1, ram_banks, 1);
+ppc440_sdram_init(env, 1, ram_banks);
+/* Enable SDRAM memory regions as we may boot without firmware */
+ppc440_sdram_enable(env);
/* IIC controllers and devices */
dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600700,
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 558500fb97..78a845399e 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -37,6 +37,8 @@ typedef struct {
uint32_t bcr;
} Ppc4xxSdramBank;
+void ppc440_sdram_enable(CPUPPCState *env);
+
void ppc4xx_sdram_banks(MemoryRegion *ram, int nr_banks,
Ppc4xxSdramBank ram_banks[],
const ram_addr_t sdram_bank_sizes[]);
--
2.37.3
[PULL 20/38] hw/ppc/meson: Allow e500 boards to be enabled separately
From: Bernhard Beschow
Gives users more fine-grained control over what should be compiled into
QEMU.
Signed-off-by: Bernhard Beschow
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20221003203142.24355-2-shen...@gmail.com>
Signed-off-by: Daniel Henrique Barboza
---
configs/devices/ppc-softmmu/default.mak | 3 ++-
hw/ppc/Kconfig | 8
hw/ppc/meson.build | 6 ++
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/configs/devices/ppc-softmmu/default.mak
b/configs/devices/ppc-softmmu/default.mak
index 658a454426..a887f5438b 100644
--- a/configs/devices/ppc-softmmu/default.mak
+++ b/configs/devices/ppc-softmmu/default.mak
@@ -1,7 +1,8 @@
# Default configuration for ppc-softmmu
# For embedded PPCs:
-CONFIG_E500=y
+CONFIG_E500PLAT=y
+CONFIG_MPC8544DS=y
CONFIG_PPC405=y
CONFIG_PPC440=y
CONFIG_VIRTEX=y
diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
index 3a4418a69e..22a64745d4 100644
--- a/hw/ppc/Kconfig
+++ b/hw/ppc/Kconfig
@@ -132,6 +132,14 @@ config E500
select FDT_PPC
select DS1338
+config E500PLAT
+bool
+select E500
+
+config MPC8544DS
+bool
+select E500
+
config VIRTEX
bool
select PPC4XX
diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
index 62801923f3..32babc9b48 100644
--- a/hw/ppc/meson.build
+++ b/hw/ppc/meson.build
@@ -71,12 +71,10 @@ ppc_ss.add(when: 'CONFIG_MAC_OLDWORLD', if_true:
files('mac_oldworld.c'))
# NewWorld PowerMac
ppc_ss.add(when: 'CONFIG_MAC_NEWWORLD', if_true: files('mac_newworld.c'))
# e500
+ppc_ss.add(when: 'CONFIG_E500PLAT', if_true: files('e500plat.c'))
+ppc_ss.add(when: 'CONFIG_MPC8544DS', if_true: files('mpc8544ds.c'))
ppc_ss.add(when: 'CONFIG_E500', if_true: files(
'e500.c',
- 'mpc8544ds.c',
- 'e500plat.c'
-))
-ppc_ss.add(when: 'CONFIG_E500', if_true: files(
'mpc8544_guts.c',
'ppce500_spin.c'
))
--
2.37.3
[PULL 03/38] ppc440_bamboo: Remove unnecessary memsets
From: BALATON Zoltan
In ppc4xx_sdram_init() the struct is allocated with g_new0() so no
need to clear its elements. In the bamboo machine init memset can be
replaced with array initialiser which is shorter.
Signed-off-by: BALATON Zoltan
Reviewed-by: Daniel Henrique Barboza
Message-Id:
<529adc7705fb3e3e777439895bdaa136bacb9403.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_bamboo.c | 6 ++
hw/ppc/ppc4xx_devs.c | 8 ++--
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index ea945a1c99..5ec82fa8c2 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -169,8 +169,8 @@ static void bamboo_init(MachineState *machine)
MemoryRegion *address_space_mem = get_system_memory();
MemoryRegion *isa = g_new(MemoryRegion, 1);
MemoryRegion *ram_memories = g_new(MemoryRegion, PPC440EP_SDRAM_NR_BANKS);
-hwaddr ram_bases[PPC440EP_SDRAM_NR_BANKS];
-hwaddr ram_sizes[PPC440EP_SDRAM_NR_BANKS];
+hwaddr ram_bases[PPC440EP_SDRAM_NR_BANKS] = {0};
+hwaddr ram_sizes[PPC440EP_SDRAM_NR_BANKS] = {0};
PCIBus *pcibus;
PowerPCCPU *cpu;
CPUPPCState *env;
@@ -205,8 +205,6 @@ static void bamboo_init(MachineState *machine)
qdev_get_gpio_in(DEVICE(cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
-memset(ram_bases, 0, sizeof(ram_bases));
-memset(ram_sizes, 0, sizeof(ram_sizes));
ppc4xx_sdram_banks(machine->ram, PPC440EP_SDRAM_NR_BANKS, ram_memories,
ram_bases, ram_sizes, ppc440ep_sdram_bank_sizes);
/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index ce38ae65e6..b4cd10f735 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -363,12 +363,8 @@ void ppc4xx_sdram_init(CPUPPCState *env, qemu_irq irq, int
nbanks,
sdram->irq = irq;
sdram->nbanks = nbanks;
sdram->ram_memories = ram_memories;
-memset(sdram->ram_bases, 0, 4 * sizeof(hwaddr));
-memcpy(sdram->ram_bases, ram_bases,
- nbanks * sizeof(hwaddr));
-memset(sdram->ram_sizes, 0, 4 * sizeof(hwaddr));
-memcpy(sdram->ram_sizes, ram_sizes,
- nbanks * sizeof(hwaddr));
+memcpy(sdram->ram_bases, ram_bases, nbanks * sizeof(hwaddr));
+memcpy(sdram->ram_sizes, ram_sizes, nbanks * sizeof(hwaddr));
qemu_register_reset(_reset, sdram);
ppc_dcr_register(env, SDRAM0_CFGADDR,
sdram, _read_sdram, _write_sdram);
--
2.37.3
[PULL 18/38] ppc440_uc.c: Move some macros to ppc4xx.h
From: BALATON Zoltan
These are used by both the SDRAM controller model and system DCRs. In
preparation to move SDRAM controller in its own file move these macros
to the ppc4xx.h header.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<74d9bf4891e2ccceb52bb6ca6b54fd3f37a9fb04.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_uc.c | 4
include/hw/ppc/ppc4xx.h | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 55082f2b88..57274b56dd 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -380,10 +380,6 @@ enum {
PESDR1_RSTSTA = 0x365,
};
-#define SDR0_DDR0_DDRM_ENCODE(n) unsigned long)(n)) & 0x03) << 29)
-#define SDR0_DDR0_DDRM_DDR1 0x2000
-#define SDR0_DDR0_DDRM_DDR2 0x4000
-
static uint32_t dcr_read_sdr(void *opaque, int dcrn)
{
ppc4xx_sdr_t *sdr = opaque;
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index ff88385ac0..10c6dd535f 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -111,6 +111,10 @@ struct Ppc4xxEbcState {
};
/* SDRAM DDR controller */
+#define SDR0_DDR0_DDRM_ENCODE(n) unsigned long)(n)) & 0x03) << 29)
+#define SDR0_DDR0_DDRM_DDR1 0x2000
+#define SDR0_DDR0_DDRM_DDR2 0x4000
+
#define TYPE_PPC4xx_SDRAM_DDR "ppc4xx-sdram-ddr"
OBJECT_DECLARE_SIMPLE_TYPE(Ppc4xxSdramDdrState, PPC4xx_SDRAM_DDR);
struct Ppc4xxSdramDdrState {
--
2.37.3
[PULL 24/38] hw/ppc/mpc8544ds: Rename wrongly named method
From: Bernhard Beschow
Signed-off-by: Bernhard Beschow
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20221003203142.24355-6-shen...@gmail.com>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/mpc8544ds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
index 81177505f0..8e674ad195 100644
--- a/hw/ppc/mpc8544ds.c
+++ b/hw/ppc/mpc8544ds.c
@@ -36,7 +36,7 @@ static void mpc8544ds_init(MachineState *machine)
ppce500_init(machine);
}
-static void e500plat_machine_class_init(ObjectClass *oc, void *data)
+static void mpc8544ds_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
PPCE500MachineClass *pmc = PPCE500_MACHINE_CLASS(oc);
@@ -63,7 +63,7 @@ static void e500plat_machine_class_init(ObjectClass *oc, void
*data)
static const TypeInfo mpc8544ds_info = {
.name = TYPE_MPC8544DS_MACHINE,
.parent= TYPE_PPCE500_MACHINE,
-.class_init= e500plat_machine_class_init,
+.class_init= mpc8544ds_machine_class_init,
};
static void mpc8544ds_register_types(void)
--
2.37.3
[PULL 06/38] ppc4xx: Use Ppc4xxSdramBank in ppc4xx_sdram_banks()
From: BALATON Zoltan
Change ppc4xx_sdram_banks() to take one Ppc4xxSdramBank array instead
of the separate arrays and adjust ppc4xx_sdram_init() and
ppc440_sdram_init() accordingly as well as machines using these.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc405.h | 4 +---
hw/ppc/ppc405_uc.c | 10 +-
hw/ppc/ppc440.h | 5 ++---
hw/ppc/ppc440_bamboo.c | 15 ++-
hw/ppc/ppc440_uc.c | 9 -
hw/ppc/ppc4xx_devs.c| 21 +
hw/ppc/sam460ex.c | 15 +--
include/hw/ppc/ppc4xx.h | 9 +++--
8 files changed, 35 insertions(+), 53 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 756865621b..ca0972b88b 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -167,9 +167,7 @@ struct Ppc405SoCState {
DeviceState parent_obj;
/* Public */
-MemoryRegion ram_banks[2];
-hwaddr ram_bases[2], ram_sizes[2];
-
+Ppc4xxSdramBank ram_banks[2];
MemoryRegion *dram_mr;
hwaddr ram_size;
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 1e02347e57..bcbf35bc14 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1074,14 +1074,14 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
/* SDRAM controller */
/* XXX 405EP has no ECC interrupt */
-s->ram_bases[0] = 0;
-s->ram_sizes[0] = s->ram_size;
-memory_region_init_alias(>ram_banks[0], OBJECT(s),
+s->ram_banks[0].base = 0;
+s->ram_banks[0].size = s->ram_size;
+memory_region_init_alias(>ram_banks[0].ram, OBJECT(s),
"ppc405.sdram0", s->dram_mr,
- s->ram_bases[0], s->ram_sizes[0]);
+ s->ram_banks[0].base, s->ram_banks[0].size);
ppc4xx_sdram_init(env, qdev_get_gpio_in(DEVICE(>uic), 17), 1,
- s->ram_banks, s->ram_bases, s->ram_sizes);
+ s->ram_banks);
/* External bus controller */
if (!ppc4xx_dcr_realize(PPC4xx_DCR_DEVICE(>ebc), >cpu, errp)) {
diff --git a/hw/ppc/ppc440.h b/hw/ppc/ppc440.h
index 7cef936125..e6c905b7d6 100644
--- a/hw/ppc/ppc440.h
+++ b/hw/ppc/ppc440.h
@@ -11,14 +11,13 @@
#ifndef PPC440_H
#define PPC440_H
-#include "hw/ppc/ppc.h"
+#include "hw/ppc/ppc4xx.h"
void ppc4xx_l2sram_init(CPUPPCState *env);
void ppc4xx_cpr_init(CPUPPCState *env);
void ppc4xx_sdr_init(CPUPPCState *env);
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- MemoryRegion *ram_memories,
- hwaddr *ram_bases, hwaddr *ram_sizes,
+ Ppc4xxSdramBank *ram_banks,
int do_init);
void ppc4xx_ahb_init(CPUPPCState *env);
void ppc4xx_dma_init(CPUPPCState *env, int dcr_base);
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 409a8840da..edfb8c9709 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -168,9 +168,8 @@ static void bamboo_init(MachineState *machine)
unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
MemoryRegion *address_space_mem = get_system_memory();
MemoryRegion *isa = g_new(MemoryRegion, 1);
-MemoryRegion *ram_memories = g_new(MemoryRegion, PPC440EP_SDRAM_NR_BANKS);
-hwaddr ram_bases[PPC440EP_SDRAM_NR_BANKS] = {0};
-hwaddr ram_sizes[PPC440EP_SDRAM_NR_BANKS] = {0};
+Ppc4xxSdramBank *ram_banks = g_new0(Ppc4xxSdramBank,
+PPC440EP_SDRAM_NR_BANKS);
PCIBus *pcibus;
PowerPCCPU *cpu;
CPUPPCState *env;
@@ -205,13 +204,11 @@ static void bamboo_init(MachineState *machine)
qdev_get_gpio_in(DEVICE(cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
-ppc4xx_sdram_banks(machine->ram, PPC440EP_SDRAM_NR_BANKS, ram_memories,
- ram_bases, ram_sizes, ppc440ep_sdram_bank_sizes);
+ppc4xx_sdram_banks(machine->ram, PPC440EP_SDRAM_NR_BANKS, ram_banks,
+ ppc440ep_sdram_bank_sizes);
/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
-ppc4xx_sdram_init(env,
- qdev_get_gpio_in(uicdev, 14),
- PPC440EP_SDRAM_NR_BANKS, ram_memories,
- ram_bases, ram_sizes);
+ppc4xx_sdram_init(env, qdev_get_gpio_in(uicdev, 14),
+ PPC440EP_SDRAM_NR_BANKS, ram_banks);
/* Enable SDRAM memory regions, this should be done by the firmware */
ppc4xx_sdram_enable(env);
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index db4e29..8eae4ad9f0 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -692,8 +692,7 @@ static void sdram_reset(void *opaque)
}
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- MemoryRegion *ram_memories,
- hwaddr *ram_bases, hwaddr *ram_sizes,
+ Ppc4xxSdramBank *ram_banks,
[PULL 31/38] hw/ppc: set machine->fdt in bamboo_load_device_tree()
This will enable support for 'dumpdtb' QMP/HMP command for the bamboo
machine.
Setting machine->fdt requires a MachineState pointer to be used inside
bamboo_load_device_tree(). Let's change the function to receive this
pointer from the caller. 'ramsize' and 'kernel_cmdline' can be retrieved
directly from the 'machine' pointer.
Cc: Cédric Le Goater
Reviewed-by: BALATON Zoltan
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-9-danielhb...@gmail.com>
---
hw/ppc/ppc440_bamboo.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 56f47e7509..81d71adf34 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -34,6 +34,8 @@
#include "hw/qdev-properties.h"
#include "qapi/error.h"
+#include
+
#define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
/* from u-boot */
@@ -50,14 +52,13 @@
static hwaddr entry;
-static int bamboo_load_device_tree(hwaddr addr,
- uint32_t ramsize,
- hwaddr initrd_base,
- hwaddr initrd_size,
- const char *kernel_cmdline)
+static int bamboo_load_device_tree(MachineState *machine,
+ hwaddr addr,
+ hwaddr initrd_base,
+ hwaddr initrd_size)
{
int ret = -1;
-uint32_t mem_reg_property[] = { 0, 0, cpu_to_be32(ramsize) };
+uint32_t mem_reg_property[] = { 0, 0, cpu_to_be32(machine->ram_size) };
char *filename;
int fdt_size;
void *fdt;
@@ -92,7 +93,7 @@ static int bamboo_load_device_tree(hwaddr addr,
fprintf(stderr, "couldn't set /chosen/linux,initrd-end\n");
}
ret = qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
- kernel_cmdline);
+ machine->kernel_cmdline);
if (ret < 0) {
fprintf(stderr, "couldn't set /chosen/bootargs\n");
}
@@ -113,7 +114,10 @@ static int bamboo_load_device_tree(hwaddr addr,
tb_freq);
rom_add_blob_fixed(BINARY_DEVICE_TREE_FILE, fdt, fdt_size, addr);
-g_free(fdt);
+
+/* Set ms->fdt for 'dumpdtb' QMP/HMP command */
+machine->fdt = fdt;
+
return 0;
}
@@ -157,7 +161,6 @@ static void main_cpu_reset(void *opaque)
static void bamboo_init(MachineState *machine)
{
const char *kernel_filename = machine->kernel_filename;
-const char *kernel_cmdline = machine->kernel_cmdline;
const char *initrd_filename = machine->initrd_filename;
unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
MemoryRegion *address_space_mem = get_system_memory();
@@ -280,8 +283,8 @@ static void bamboo_init(MachineState *machine)
/* If we're loading a kernel directly, we must load the device tree too. */
if (kernel_filename) {
-if (bamboo_load_device_tree(FDT_ADDR, machine->ram_size, RAMDISK_ADDR,
-initrd_size, kernel_cmdline) < 0) {
+if (bamboo_load_device_tree(machine, FDT_ADDR,
+RAMDISK_ADDR, initrd_size) < 0) {
error_report("couldn't load device tree");
exit(1);
}
--
2.37.3
[PULL 22/38] docs/system/ppc/ppce500: Add heading for networking chapter
From: Bernhard Beschow The sudden change of topics is slightly confusing and makes the networking information less visible. So separate the networking chapter to improve comprehensibility. Signed-off-by: Bernhard Beschow Reviewed-by: Bin Meng Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20221003203142.24355-4-shen...@gmail.com> Signed-off-by: Daniel Henrique Barboza --- docs/system/ppc/ppce500.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst index 9beef39171..ba6bcb7314 100644 --- a/docs/system/ppc/ppce500.rst +++ b/docs/system/ppc/ppce500.rst @@ -146,6 +146,9 @@ You can specify a real world SoC device that QEMU has built-in support but all these SoCs are e500v2 based MPC85xx series, hence you cannot test anything built for P4080 (e500mc), P5020 (e5500) and T2080 (e6500). +Networking +-- + By default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by: -- 2.37.3
[PULL 23/38] hw/ppc/e500: Reduce usage of sysbus API
From: Bernhard Beschow PlatformBusDevice has an mmio attribute which gets aliased to SysBusDevice::mmio[0]. So PlatformbusDevice::mmio can be used directly, avoiding the sysbus API. Signed-off-by: Bernhard Beschow Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Bin Meng Message-Id: <20221003203142.24355-5-shen...@gmail.com> Signed-off-by: Daniel Henrique Barboza --- hw/ppc/e500.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index 32495d0123..496c61b612 100644 --- a/hw/ppc/e500.c +++ b/hw/ppc/e500.c @@ -1023,7 +1023,7 @@ void ppce500_init(MachineState *machine) memory_region_add_subregion(address_space_mem, pmc->platform_bus_base, -sysbus_mmio_get_region(s, 0)); +>pbus_dev->mmio); } /* -- 2.37.3
[PULL 17/38] ppc440_sdram: QOM'ify
From: BALATON Zoltan
Change the ppc440_sdram model to a QOM class derived from the
PPC4xx-dcr-device and name it ppc4xx-sdram-ddr2. This is mostly
modelling the DDR2 SDRAM controller found in the 460EX (used on the
sam460ex board). Newer SoCs (regardless of their PPC core, e.g. 405EX)
may have this controller but we only emulate enough of it for the
sam460ex u-boot firmware.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<3e82ae575c7c41e464a0082d55ecb4ebcc4d4329.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440.h | 2 -
hw/ppc/ppc440_uc.c | 121
hw/ppc/sam460ex.c | 9 ++-
include/hw/ppc/ppc4xx.h | 18 +-
4 files changed, 97 insertions(+), 53 deletions(-)
diff --git a/hw/ppc/ppc440.h b/hw/ppc/ppc440.h
index 29f6f14ed7..7c24db8504 100644
--- a/hw/ppc/ppc440.h
+++ b/hw/ppc/ppc440.h
@@ -16,8 +16,6 @@
void ppc4xx_l2sram_init(CPUPPCState *env);
void ppc4xx_cpr_init(CPUPPCState *env);
void ppc4xx_sdr_init(CPUPPCState *env);
-void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- MemoryRegion *ram);
void ppc4xx_ahb_init(CPUPPCState *env);
void ppc4xx_dma_init(CPUPPCState *env, int dcr_base);
void ppc460ex_pcie_init(CPUPPCState *env);
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index dd873d892c..55082f2b88 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -484,13 +484,6 @@ void ppc4xx_sdr_init(CPUPPCState *env)
/*/
/* SDRAM controller */
-typedef struct ppc440_sdram_t {
-uint32_t addr;
-uint32_t mcopt2;
-int nbanks; /* Banks to use from the 4, e.g. when board has less slots */
-Ppc4xxSdramBank bank[4];
-} ppc440_sdram_t;
-
enum {
SDRAM0_CFGADDR = 0x10,
SDRAM0_CFGDATA,
@@ -581,7 +574,7 @@ static void sdram_bank_unmap(Ppc4xxSdramBank *bank)
object_unparent(OBJECT(>container));
}
-static void sdram_ddr2_set_bcr(ppc440_sdram_t *sdram, int i,
+static void sdram_ddr2_set_bcr(Ppc4xxSdramDdr2State *sdram, int i,
uint32_t bcr, int enabled)
{
if (sdram->bank[i].bcr & 1) {
@@ -597,7 +590,7 @@ static void sdram_ddr2_set_bcr(ppc440_sdram_t *sdram, int i,
}
}
-static void sdram_ddr2_map_bcr(ppc440_sdram_t *sdram)
+static void sdram_ddr2_map_bcr(Ppc4xxSdramDdr2State *sdram)
{
int i;
@@ -612,7 +605,7 @@ static void sdram_ddr2_map_bcr(ppc440_sdram_t *sdram)
}
}
-static void sdram_ddr2_unmap_bcr(ppc440_sdram_t *sdram)
+static void sdram_ddr2_unmap_bcr(Ppc4xxSdramDdr2State *sdram)
{
int i;
@@ -625,7 +618,7 @@ static void sdram_ddr2_unmap_bcr(ppc440_sdram_t *sdram)
static uint32_t sdram_ddr2_dcr_read(void *opaque, int dcrn)
{
-ppc440_sdram_t *sdram = opaque;
+Ppc4xxSdramDdr2State *sdram = opaque;
uint32_t ret = 0;
switch (dcrn) {
@@ -680,7 +673,7 @@ static uint32_t sdram_ddr2_dcr_read(void *opaque, int dcrn)
static void sdram_ddr2_dcr_write(void *opaque, int dcrn, uint32_t val)
{
-ppc440_sdram_t *sdram = opaque;
+Ppc4xxSdramDdr2State *sdram = opaque;
switch (dcrn) {
case SDRAM_R0BAS:
@@ -724,18 +717,18 @@ static void sdram_ddr2_dcr_write(void *opaque, int dcrn,
uint32_t val)
}
}
-static void sdram_ddr2_reset(void *opaque)
+static void ppc4xx_sdram_ddr2_reset(DeviceState *dev)
{
-ppc440_sdram_t *sdram = opaque;
+Ppc4xxSdramDdr2State *sdram = PPC4xx_SDRAM_DDR2(dev);
sdram->addr = 0;
sdram->mcopt2 = 0;
}
-void ppc440_sdram_init(CPUPPCState *env, int nbanks,
- MemoryRegion *ram)
+static void ppc4xx_sdram_ddr2_realize(DeviceState *dev, Error **errp)
{
-ppc440_sdram_t *s;
+Ppc4xxSdramDdr2State *s = PPC4xx_SDRAM_DDR2(dev);
+Ppc4xxDcrDeviceState *dcr = PPC4xx_DCR_DEVICE(dev);
/*
* SoC also has 4 GiB but that causes problem with 32 bit
* builds (4*GiB overflows the 32 bit ram_addr_t).
@@ -745,41 +738,75 @@ void ppc440_sdram_init(CPUPPCState *env, int nbanks,
64 * MiB, 32 * MiB, 16 * MiB, 8 * MiB, 0
};
-s = g_malloc0(sizeof(*s));
-s->nbanks = nbanks;
-ppc4xx_sdram_banks(ram, s->nbanks, s->bank, valid_bank_sizes);
-qemu_register_reset(_ddr2_reset, s);
-ppc_dcr_register(env, SDRAM0_CFGADDR,
- s, _ddr2_dcr_read, _ddr2_dcr_write);
-ppc_dcr_register(env, SDRAM0_CFGDATA,
- s, _ddr2_dcr_read, _ddr2_dcr_write);
-
-ppc_dcr_register(env, SDRAM_R0BAS,
- s, _ddr2_dcr_read, _ddr2_dcr_write);
-ppc_dcr_register(env, SDRAM_R1BAS,
- s, _ddr2_dcr_read, _ddr2_dcr_write);
-ppc_dcr_register(env, SDRAM_R2BAS,
- s, _ddr2_dcr_read, _ddr2_dcr_write);
-ppc_dcr_register(env, SDRAM_R3BAS,
- s, _ddr2_dcr_read, _ddr2_dcr_write);
-ppc_dcr_register(env, SDRAM_CONF1HB,
- s,
[PULL 27/38] target/ppc: Fix xvcmp* clearing FI bit
From: Víctor Colombo
Vector instructions in general are not supposed to change the FI bit.
However, xvcmp* instructions are calling gen_helper_float_check_status,
which is leading to a cleared FI flag where it should be kept
unchanged.
As helper_float_check_status only affects inexact, overflow and
underflow, and the xvcmp* instructions don't change these flags, this
issue can be fixed by removing the call to helper_float_check_status.
By doing this, the FI bit in FPSCR will be preserved as expected.
Fixes: 00084a25adf ("target/ppc: introduce separate VSX_CMP macro for xvcmp*
instructions")
Signed-off-by: Víctor Colombo
Reviewed-by: Richard Henderson
Message-Id: <20221005121551.27957-1-victor.colo...@eldorado.org.br>
Signed-off-by: Daniel Henrique Barboza
---
target/ppc/translate/vsx-impl.c.inc | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/ppc/translate/vsx-impl.c.inc
b/target/ppc/translate/vsx-impl.c.inc
index 7acdbceec4..e6e5c45ffd 100644
--- a/target/ppc/translate/vsx-impl.c.inc
+++ b/target/ppc/translate/vsx-impl.c.inc
@@ -810,7 +810,6 @@ static void gen_##name(DisasContext *ctx)
\
gen_helper_##name(ignored, cpu_env, xt, xa, xb); \
tcg_temp_free_i32(ignored); \
} \
-gen_helper_float_check_status(cpu_env); \
tcg_temp_free_ptr(xt);\
tcg_temp_free_ptr(xa);\
tcg_temp_free_ptr(xb);\
--
2.37.3
[PULL 09/38] ppc4xx_sdram: QOM'ify
From: BALATON Zoltan
Change the ppc4xx_sdram model to a QOM class derived from the
PPC4xx-dcr-device and name it ppc4xx-sdram-ddr. This is mostly
modelling the DDR SDRAM controller found in the 440EP (used on the
bamboo board) but also backward compatible with the older DDR
controllers on some 405 SoCs so we also use it for those now. This
likely does not cause problems for guests we run as the new features
are just not accessed but to model 405 SoC accurately some features
may have to be disabled or the model split between 440 and older.
Newer SoCs (regardless of their PPC core, e.g. 405EX) may have an
updated DDR2 SDRAM controller implemented by the ppc440_sdram model
(only partially, enough for the 460EX on the sam460ex) that is not yet
QOM'ified in this patch. That is intended to become ppc4xx-sdram-ddr2
when QOM'ified later.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<8f820487fc9011343032c422ecdf3e8ee74d8c11.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc405.h | 3 +-
hw/ppc/ppc405_boards.c | 2 +-
hw/ppc/ppc405_uc.c | 22 +
hw/ppc/ppc440_bamboo.c | 12 +++--
hw/ppc/ppc4xx_devs.c| 105 ++--
include/hw/ppc/ppc4xx.h | 31 ++--
6 files changed, 105 insertions(+), 70 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index ad54dff542..9a4312691e 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -167,8 +167,6 @@ struct Ppc405SoCState {
DeviceState parent_obj;
/* Public */
-MemoryRegion *dram_mr;
-
PowerPCCPU cpu;
PPCUIC uic;
Ppc405CpcState cpc;
@@ -182,6 +180,7 @@ struct Ppc405SoCState {
Ppc405PobState pob;
Ppc4xxPlbState plb;
Ppc4xxMalState mal;
+Ppc4xxSdramDdrState sdram;
};
#endif /* PPC405_H */
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 824acf7a80..b59393d4bd 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -337,7 +337,7 @@ static void ppc405_init(MachineState *machine)
/* Load ELF kernel and rootfs.cpio */
} else if (kernel_filename && !machine->firmware) {
-ppc4xx_sdram_enable(>soc.cpu.env);
+ppc4xx_sdram_enable(>soc.sdram);
boot_from_kernel(machine, >soc.cpu);
}
}
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index e1c7188e61..c973cfb04e 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1016,6 +1016,9 @@ static void ppc405_soc_instance_init(Object *obj)
object_initialize_child(obj, "plb", >plb, TYPE_PPC4xx_PLB);
object_initialize_child(obj, "mal", >mal, TYPE_PPC4xx_MAL);
+
+object_initialize_child(obj, "sdram", >sdram, TYPE_PPC4xx_SDRAM_DDR);
+object_property_add_alias(obj, "dram", OBJECT(>sdram), "dram");
}
static void ppc405_reset(void *opaque)
@@ -1073,9 +1076,17 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
qdev_get_gpio_in(DEVICE(>cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
+/*
+ * We use the 440 DDR SDRAM controller which has more regs and features
+ * but it's compatible enough for now
+ */
+object_property_set_int(OBJECT(>sdram), "nbanks", 2, _abort);
+if (!ppc4xx_dcr_realize(PPC4xx_DCR_DEVICE(>sdram), >cpu, errp)) {
+return;
+}
/* XXX 405EP has no ECC interrupt */
-ppc4xx_sdram_init(env, qdev_get_gpio_in(DEVICE(>uic), 17), 1,
- s->dram_mr);
+sysbus_connect_irq(SYS_BUS_DEVICE(>sdram), 0,
+ qdev_get_gpio_in(DEVICE(>uic), 17));
/* External bus controller */
if (!ppc4xx_dcr_realize(PPC4xx_DCR_DEVICE(>ebc), >cpu, errp)) {
@@ -1150,12 +1161,6 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
/* Uses UIC IRQs 9, 15, 17 */
}
-static Property ppc405_soc_properties[] = {
-DEFINE_PROP_LINK("dram", Ppc405SoCState, dram_mr, TYPE_MEMORY_REGION,
- MemoryRegion *),
-DEFINE_PROP_END_OF_LIST(),
-};
-
static void ppc405_soc_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -1163,7 +1168,6 @@ static void ppc405_soc_class_init(ObjectClass *oc, void
*data)
dc->realize = ppc405_soc_realize;
/* Reason: only works as part of a ppc405 board/machine */
dc->user_creatable = false;
-device_class_set_props(dc, ppc405_soc_properties);
}
static const TypeInfo ppc405_types[] = {
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 91d9a4eef3..5c35ba6086 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -48,8 +48,6 @@
#define PPC440EP_PCI_IO 0xe800
#define PPC440EP_PCI_IOLEN 0x0001
-#define PPC440EP_SDRAM_NR_BANKS 4
-
static hwaddr entry;
static int bamboo_load_device_tree(hwaddr addr,
@@ -198,11 +196,15 @@ static void bamboo_init(MachineState *machine)
qdev_get_gpio_in(DEVICE(cpu), PPC40x_INPUT_CINT));
/* SDRAM
[PULL 08/38] ppc4xx_sdram: Move size check to ppc4xx_sdram_init()
From: BALATON Zoltan
Instead of checking if memory size is valid in board code move this
check to ppc4xx_sdram_init() as this is a restriction imposed by the
SDRAM controller.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
<39e5129dd095b285676a6267c5753786da1bc30d.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc405.h | 2 --
hw/ppc/ppc405_boards.c | 10 --
hw/ppc/ppc405_uc.c | 11 ++-
hw/ppc/ppc440_bamboo.c | 10 +-
hw/ppc/ppc4xx_devs.c| 14 ++
include/hw/ppc/ppc4xx.h | 2 +-
6 files changed, 10 insertions(+), 39 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index ca0972b88b..ad54dff542 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -167,9 +167,7 @@ struct Ppc405SoCState {
DeviceState parent_obj;
/* Public */
-Ppc4xxSdramBank ram_banks[2];
MemoryRegion *dram_mr;
-hwaddr ram_size;
PowerPCCPU cpu;
PPCUIC uic;
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 1eaeca8806..824acf7a80 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -271,21 +271,11 @@ static void boot_from_kernel(MachineState *machine,
PowerPCCPU *cpu)
static void ppc405_init(MachineState *machine)
{
Ppc405MachineState *ppc405 = PPC405_MACHINE(machine);
-MachineClass *mc = MACHINE_GET_CLASS(machine);
const char *kernel_filename = machine->kernel_filename;
MemoryRegion *sysmem = get_system_memory();
-if (machine->ram_size != mc->default_ram_size) {
-char *sz = size_to_str(mc->default_ram_size);
-error_report("Invalid RAM size, should be %s", sz);
-g_free(sz);
-exit(EXIT_FAILURE);
-}
-
object_initialize_child(OBJECT(machine), "soc", >soc,
TYPE_PPC405_SOC);
-object_property_set_uint(OBJECT(>soc), "ram-size",
- machine->ram_size, _fatal);
object_property_set_link(OBJECT(>soc), "dram",
OBJECT(machine->ram), _abort);
object_property_set_uint(OBJECT(>soc), "sys-clk", ,
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index bcbf35bc14..e1c7188e61 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1073,15 +1073,9 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
qdev_get_gpio_in(DEVICE(>cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
-/* XXX 405EP has no ECC interrupt */
-s->ram_banks[0].base = 0;
-s->ram_banks[0].size = s->ram_size;
-memory_region_init_alias(>ram_banks[0].ram, OBJECT(s),
- "ppc405.sdram0", s->dram_mr,
- s->ram_banks[0].base, s->ram_banks[0].size);
-
+/* XXX 405EP has no ECC interrupt */
ppc4xx_sdram_init(env, qdev_get_gpio_in(DEVICE(>uic), 17), 1,
- s->ram_banks);
+ s->dram_mr);
/* External bus controller */
if (!ppc4xx_dcr_realize(PPC4xx_DCR_DEVICE(>ebc), >cpu, errp)) {
@@ -1159,7 +1153,6 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
static Property ppc405_soc_properties[] = {
DEFINE_PROP_LINK("dram", Ppc405SoCState, dram_mr, TYPE_MEMORY_REGION,
MemoryRegion *),
-DEFINE_PROP_UINT64("ram-size", Ppc405SoCState, ram_size, 0),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 7ec7c7c43d..91d9a4eef3 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -50,10 +50,6 @@
#define PPC440EP_SDRAM_NR_BANKS 4
-static const ram_addr_t ppc440ep_sdram_bank_sizes[] = {
-256 * MiB, 128 * MiB, 64 * MiB, 32 * MiB, 16 * MiB, 8 * MiB, 4 * MiB, 0
-};
-
static hwaddr entry;
static int bamboo_load_device_tree(hwaddr addr,
@@ -168,8 +164,6 @@ static void bamboo_init(MachineState *machine)
unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
MemoryRegion *address_space_mem = get_system_memory();
MemoryRegion *isa = g_new(MemoryRegion, 1);
-Ppc4xxSdramBank *ram_banks = g_new0(Ppc4xxSdramBank,
-PPC440EP_SDRAM_NR_BANKS);
PCIBus *pcibus;
PowerPCCPU *cpu;
CPUPPCState *env;
@@ -204,11 +198,9 @@ static void bamboo_init(MachineState *machine)
qdev_get_gpio_in(DEVICE(cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
-ppc4xx_sdram_banks(machine->ram, PPC440EP_SDRAM_NR_BANKS, ram_banks,
- ppc440ep_sdram_bank_sizes);
/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
ppc4xx_sdram_init(env, qdev_get_gpio_in(uicdev, 14),
- PPC440EP_SDRAM_NR_BANKS, ram_banks);
+ PPC440EP_SDRAM_NR_BANKS, machine->ram);
/* Enable SDRAM memory regions, this should be done by the firmware */
ppc4xx_sdram_enable(env);
diff --git a/hw/ppc/ppc4xx_devs.c
[PULL 36/38] hw/ppc: set machine->fdt in spapr machine
The pSeries machine never bothered with the common machine->fdt attribute. We do all the FDT related work using spapr->fdt_blob. We're going to introduce a QMP/HMP command to dump the FDT, which will rely on setting machine->fdt properly to work across all machine archs/types. Let's set machine->fdt in two places where we manipulate the FDT: spapr_machine_reset() and CAS. There are other places where the FDT is manipulated in the pSeries machines, most notably the hotplug/unplug path. For now we'll acknowledge that we won't have the most accurate representation of the FDT, depending on the current machine state, when using this QMP/HMP fdt command. Making the internal FDT representation always match the actual FDT representation that the guest is using is a problem for another day. spapr->fdt_blob is left untouched for now. To replace it with machine->fdt, since we're migrating spapr->fdt_blob, we would need to migrate machine->fdt as well. This is something that we would like to to do keep our code simpler but it's also a work we'll leave for later. Reviewed-by: David Gibson Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Daniel Henrique Barboza Message-Id: <20220926173855.1159396-14-danielhb...@gmail.com> --- hw/ppc/spapr.c | 3 +++ hw/ppc/spapr_hcall.c | 8 2 files changed, 11 insertions(+) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 8bbaf4f8a4..f79ac85ca1 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -1713,6 +1713,9 @@ static void spapr_machine_reset(MachineState *machine) spapr->fdt_initial_size = spapr->fdt_size; spapr->fdt_blob = fdt; +/* Set machine->fdt for 'dumpdtb' QMP/HMP command */ +machine->fdt = fdt; + /* Set up the entry state */ first_ppc_cpu->env.gpr[5] = 0; diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c index a8d4a6bcf0..891206e893 100644 --- a/hw/ppc/spapr_hcall.c +++ b/hw/ppc/spapr_hcall.c @@ -1256,6 +1256,14 @@ target_ulong do_client_architecture_support(PowerPCCPU *cpu, spapr->fdt_initial_size = spapr->fdt_size; spapr->fdt_blob = fdt; +/* + * Set the machine->fdt pointer again since we just freed + * it above (by freeing spapr->fdt_blob). We set this + * pointer to enable support for the 'dumpdtb' QMP/HMP + * command. + */ +MACHINE(spapr)->fdt = fdt; + return H_SUCCESS; } -- 2.37.3
[PULL 15/38] ppc4xx_sdram: Rename functions to prevent name clashes
From: BALATON Zoltan
Rename functions to avoid name clashes when moving the DDR2 controller
model currently called ppc440_sdram to ppc4xx_devs. This also more
clearly shows which function belongs to which model.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
<9c09d10fbf36940ebbe30d7038d69cf3f2e58371.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc405_boards.c | 2 +-
hw/ppc/ppc440_bamboo.c | 2 +-
hw/ppc/ppc440_uc.c | 67 +
hw/ppc/ppc4xx_devs.c| 46 ++--
hw/ppc/sam460ex.c | 2 +-
include/hw/ppc/ppc4xx.h | 4 +--
6 files changed, 62 insertions(+), 61 deletions(-)
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index b59393d4bd..4092ebc1ab 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -337,7 +337,7 @@ static void ppc405_init(MachineState *machine)
/* Load ELF kernel and rootfs.cpio */
} else if (kernel_filename && !machine->firmware) {
-ppc4xx_sdram_enable(>soc.sdram);
+ppc4xx_sdram_ddr_enable(>soc.sdram);
boot_from_kernel(machine, >soc.cpu);
}
}
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 5c35ba6086..56f47e7509 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -204,7 +204,7 @@ static void bamboo_init(MachineState *machine)
/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, qdev_get_gpio_in(uicdev, 14));
/* Enable SDRAM memory regions, this should be done by the firmware */
-ppc4xx_sdram_enable(PPC4xx_SDRAM_DDR(dev));
+ppc4xx_sdram_ddr_enable(PPC4xx_SDRAM_DDR(dev));
/* PCI */
dev = sysbus_create_varargs(TYPE_PPC4xx_PCI_HOST_BRIDGE,
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 97e6d5f5b2..edd0781eb7 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -505,7 +505,7 @@ enum {
SDRAM_PLBADDUHB = 0x50,
};
-static uint32_t sdram_bcr(hwaddr ram_base, hwaddr ram_size)
+static uint32_t sdram_ddr2_bcr(hwaddr ram_base, hwaddr ram_size)
{
uint32_t bcr;
@@ -550,12 +550,12 @@ static uint32_t sdram_bcr(hwaddr ram_base, hwaddr
ram_size)
return bcr;
}
-static inline hwaddr sdram_base(uint32_t bcr)
+static inline hwaddr sdram_ddr2_base(uint32_t bcr)
{
return (bcr & 0xffe0) << 2;
}
-static uint64_t sdram_size(uint32_t bcr)
+static uint64_t sdram_ddr2_size(uint32_t bcr)
{
uint64_t size;
int sh;
@@ -581,48 +581,49 @@ static void sdram_bank_unmap(Ppc4xxSdramBank *bank)
object_unparent(OBJECT(>container));
}
-static void sdram_set_bcr(ppc440_sdram_t *sdram, int i,
- uint32_t bcr, int enabled)
+static void sdram_ddr2_set_bcr(ppc440_sdram_t *sdram, int i,
+ uint32_t bcr, int enabled)
{
if (sdram->bank[i].bcr & 1) {
/* First unmap RAM if enabled */
-trace_ppc4xx_sdram_unmap(sdram_base(sdram->bank[i].bcr),
- sdram_size(sdram->bank[i].bcr));
+trace_ppc4xx_sdram_unmap(sdram_ddr2_base(sdram->bank[i].bcr),
+ sdram_ddr2_size(sdram->bank[i].bcr));
sdram_bank_unmap(>bank[i]);
}
sdram->bank[i].bcr = bcr & 0xffe0ffc1;
if (enabled && (bcr & 1)) {
-trace_ppc4xx_sdram_map(sdram_base(bcr), sdram_size(bcr));
+trace_ppc4xx_sdram_map(sdram_ddr2_base(bcr), sdram_ddr2_size(bcr));
sdram_bank_map(>bank[i]);
}
}
-static void sdram_map_bcr(ppc440_sdram_t *sdram)
+static void sdram_ddr2_map_bcr(ppc440_sdram_t *sdram)
{
int i;
for (i = 0; i < sdram->nbanks; i++) {
if (sdram->bank[i].size) {
-sdram_set_bcr(sdram, i, sdram_bcr(sdram->bank[i].base,
+sdram_ddr2_set_bcr(sdram, i,
+ sdram_ddr2_bcr(sdram->bank[i].base,
sdram->bank[i].size), 1);
} else {
-sdram_set_bcr(sdram, i, 0, 0);
+sdram_ddr2_set_bcr(sdram, i, 0, 0);
}
}
}
-static void sdram_unmap_bcr(ppc440_sdram_t *sdram)
+static void sdram_ddr2_unmap_bcr(ppc440_sdram_t *sdram)
{
int i;
for (i = 0; i < sdram->nbanks; i++) {
if (sdram->bank[i].size) {
-sdram_set_bcr(sdram, i, sdram->bank[i].bcr & ~1, 0);
+sdram_ddr2_set_bcr(sdram, i, sdram->bank[i].bcr & ~1, 0);
}
}
}
-static uint32_t dcr_read_sdram(void *opaque, int dcrn)
+static uint32_t sdram_ddr2_dcr_read(void *opaque, int dcrn)
{
ppc440_sdram_t *sdram = opaque;
uint32_t ret = 0;
@@ -633,8 +634,8 @@ static uint32_t dcr_read_sdram(void *opaque, int dcrn)
case SDRAM_R2BAS:
case SDRAM_R3BAS:
if (sdram->bank[dcrn - SDRAM_R0BAS].size) {
-ret = sdram_bcr(sdram->bank[dcrn - SDRAM_R0BAS].base,
-
[PULL 11/38] ppc440_sdram: Split off map/unmap of sdram banks for later reuse
From: BALATON Zoltan
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
<23560b6a71682d513f3dd8e9ed3852f51d5eb309.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_uc.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 8eae4ad9f0..900b7ab998 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -23,6 +23,7 @@
#include "sysemu/reset.h"
#include "ppc440.h"
#include "qom/object.h"
+#include "trace.h"
/*/
/* L2 Cache as SRAM */
@@ -563,26 +564,34 @@ static uint64_t sdram_size(uint32_t bcr)
return size;
}
+static void sdram_bank_map(Ppc4xxSdramBank *bank)
+{
+memory_region_init(>container, NULL, "sdram-container", bank->size);
+memory_region_add_subregion(>container, 0, >ram);
+memory_region_add_subregion(get_system_memory(), bank->base,
+>container);
+}
+
+static void sdram_bank_unmap(Ppc4xxSdramBank *bank)
+{
+memory_region_del_subregion(get_system_memory(), >container);
+memory_region_del_subregion(>container, >ram);
+object_unparent(OBJECT(>container));
+}
+
static void sdram_set_bcr(ppc440_sdram_t *sdram, int i,
uint32_t bcr, int enabled)
{
if (sdram->bank[i].bcr & 1) {
/* First unmap RAM if enabled */
-memory_region_del_subregion(get_system_memory(),
->bank[i].container);
-memory_region_del_subregion(>bank[i].container,
->bank[i].ram);
-object_unparent(OBJECT(>bank[i].container));
+trace_ppc4xx_sdram_unmap(sdram_base(sdram->bank[i].bcr),
+ sdram_size(sdram->bank[i].bcr));
+sdram_bank_unmap(>bank[i]);
}
sdram->bank[i].bcr = bcr & 0xffe0ffc1;
if (enabled && (bcr & 1)) {
-memory_region_init(>bank[i].container, NULL, "sdram-container",
- sdram_size(bcr));
-memory_region_add_subregion(>bank[i].container, 0,
->bank[i].ram);
-memory_region_add_subregion(get_system_memory(),
-sdram_base(bcr),
->bank[i].container);
+trace_ppc4xx_sdram_map(sdram_base(bcr), sdram_size(bcr));
+sdram_bank_map(>bank[i]);
}
}
--
2.37.3
[PULL 07/38] ppc440_bamboo: Add missing 4 MiB valid memory size
From: BALATON Zoltan
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<05836e38be84729c1c6b5b609e7aa2ea60435033.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_bamboo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index edfb8c9709..7ec7c7c43d 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -51,7 +51,7 @@
#define PPC440EP_SDRAM_NR_BANKS 4
static const ram_addr_t ppc440ep_sdram_bank_sizes[] = {
-256 * MiB, 128 * MiB, 64 * MiB, 32 * MiB, 16 * MiB, 8 * MiB, 0
+256 * MiB, 128 * MiB, 64 * MiB, 32 * MiB, 16 * MiB, 8 * MiB, 4 * MiB, 0
};
static hwaddr entry;
--
2.37.3
[PULL 02/38] target/ppc: restore powerpc_excp_booke doorbell interrupts
From: Nicholas Piggin
This partially reverts commit 9dc20cc37db9 ("target/ppc: Simplify
powerpc_excp_booke"), which removed DOORI and DOORCI interrupts.
Without this patch, a -cpu e5500 -smp 2 machine booting Linux
crashes with:
qemu: fatal: Invalid PowerPC exception 36. Aborting
Signed-off-by: Nicholas Piggin
Reviewed-by: Cédric Le Goater
Message-Id: <20220924114436.1422786-1-npig...@gmail.com>
Signed-off-by: Daniel Henrique Barboza
---
target/ppc/excp_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 214acf5ac4..43f2480e94 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -1247,6 +1247,12 @@ static void powerpc_excp_booke(PowerPCCPU *cpu, int excp)
case POWERPC_EXCP_SPEU: /* SPE/embedded floating-point unavailable/VPU
*/
env->spr[SPR_BOOKE_ESR] = ESR_SPV;
break;
+case POWERPC_EXCP_DOORI: /* Embedded doorbell interrupt */
+break;
+case POWERPC_EXCP_DOORCI:/* Embedded doorbell critical interrupt */
+srr0 = SPR_BOOKE_CSRR0;
+srr1 = SPR_BOOKE_CSRR1;
+break;
case POWERPC_EXCP_RESET: /* System reset exception */
if (FIELD_EX64(env->msr, MSR, POW)) {
cpu_abort(cs, "Trying to deliver power-saving system reset "
--
2.37.3
[PULL 25/38] hw/ppc/mpc8544ds: Add platform bus
From: Bernhard Beschow Models the real device more closely. Address and size values are taken from mpc8544.dts from the linux-5.17.7 tree. The IRQ range is taken from e500plat.c. Signed-off-by: Bernhard Beschow Reviewed-by: Bin Meng Message-Id: <20221003203142.24355-7-shen...@gmail.com> Signed-off-by: Daniel Henrique Barboza --- hw/ppc/mpc8544ds.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 8e674ad195..9c81477698 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -14,6 +14,7 @@ #include "sysemu/device_tree.h" #include "hw/ppc/openpic.h" #include "qemu/error-report.h" +#include "qemu/units.h" #include "cpu.h" static void mpc8544ds_fixup_devtree(void *fdt) @@ -45,6 +46,11 @@ static void mpc8544ds_machine_class_init(ObjectClass *oc, void *data) pmc->pci_nr_slots = 2; pmc->fixup_devtree = mpc8544ds_fixup_devtree; pmc->mpic_version = OPENPIC_MODEL_FSL_MPIC_20; +pmc->has_platform_bus = true; +pmc->platform_bus_base = 0xFF80ULL; +pmc->platform_bus_size = 8 * MiB; +pmc->platform_bus_first_irq = 5; +pmc->platform_bus_num_irqs = 10; pmc->ccsrbar_base = 0xE000ULL; pmc->pci_mmio_base = 0xC000ULL; pmc->pci_mmio_bus_base = 0xC000ULL; -- 2.37.3
[PULL 35/38] hw/ppc: set machine->fdt in pnv_reset()
This will enable support for the 'dumpdtb' QMP/HMP command for all powernv machines. Reviewed-by: Cédric Le Goater Reviewed-by: Frederic Barrat Signed-off-by: Daniel Henrique Barboza Message-Id: <20220926173855.1159396-13-danielhb...@gmail.com> --- hw/ppc/pnv.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c index 78e00afb9b..40bb573d1a 100644 --- a/hw/ppc/pnv.c +++ b/hw/ppc/pnv.c @@ -678,7 +678,13 @@ static void pnv_reset(MachineState *machine) qemu_fdt_dumpdtb(fdt, fdt_totalsize(fdt)); cpu_physical_memory_write(PNV_FDT_ADDR, fdt, fdt_totalsize(fdt)); -g_free(fdt); +/* + * Set machine->fdt for 'dumpdtb' QMP/HMP command. Free + * the existing machine->fdt to avoid leaking it during + * a reset. + */ +g_free(machine->fdt); +machine->fdt = fdt; } static ISABus *pnv_chip_power8_isa_create(PnvChip *chip, Error **errp) -- 2.37.3
[PULL 29/38] qmp/hmp, device_tree.c: introduce dumpdtb
To save the FDT blob we have the '-machine dumpdtb=' property.
With this property set, the machine saves the FDT in and exit.
The created file can then be converted to plain text dts format using
'dtc'.
There's nothing particularly sophisticated into saving the FDT that
can't be done with the machine at any state, as long as the machine has
a valid FDT to be saved.
The 'dumpdtb' command receives a 'filename' parameter and, if the FDT is
available via current_machine->fdt, save it in dtb format to 'filename'.
In short, this is a '-machine dumpdtb' that can be fired on demand via
QMP/HMP.
This command will always be executed in-band (i.e. holding BQL),
avoiding potential race conditions with machines that might change the
FDT during runtime (e.g. PowerPC 'pseries' machine).
Cc: Dr. David Alan Gilbert
Cc: Markus Armbruster
Cc: Alistair Francis
Cc: David Gibson
Acked-by: Dr. David Alan Gilbert
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220926173855.1159396-2-danielhb...@gmail.com>
---
hmp-commands.hx | 15 +++
include/sysemu/device_tree.h | 1 +
monitor/misc.c | 1 +
qapi/machine.json| 18 ++
softmmu/device_tree.c| 37
5 files changed, 72 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 8ab8000acd..12b6d4e2dc 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1800,3 +1800,18 @@ ERST
.sub_table = hmp_info_cmds,
.flags = "p",
},
+
+#if defined(CONFIG_FDT)
+{
+.name = "dumpdtb",
+.args_type = "filename:F",
+.params = "filename",
+.help = "dump the FDT in dtb format to 'filename'",
+.cmd= hmp_dumpdtb,
+},
+
+SRST
+``dumpdtb`` *filename*
+ Dump the FDT in dtb format to *filename*.
+ERST
+#endif
diff --git a/include/sysemu/device_tree.h b/include/sysemu/device_tree.h
index ef060a9759..e7c5441f56 100644
--- a/include/sysemu/device_tree.h
+++ b/include/sysemu/device_tree.h
@@ -136,6 +136,7 @@ int qemu_fdt_add_path(void *fdt, const char *path);
} while (0)
void qemu_fdt_dumpdtb(void *fdt, int size);
+void hmp_dumpdtb(Monitor *mon, const QDict *qdict);
/**
* qemu_fdt_setprop_sized_cells_from_array:
diff --git a/monitor/misc.c b/monitor/misc.c
index 6436a8786b..205487e2b9 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -49,6 +49,7 @@
#include "sysemu/blockdev.h"
#include "sysemu/sysemu.h"
#include "sysemu/tpm.h"
+#include "sysemu/device_tree.h"
#include "qapi/qmp/qdict.h"
#include "qapi/qmp/qerror.h"
#include "qapi/qmp/qstring.h"
diff --git a/qapi/machine.json b/qapi/machine.json
index abb2f48808..b9228a5e46 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -1664,3 +1664,21 @@
'*size': 'size',
'*max-size': 'size',
'*slots': 'uint64' } }
+
+##
+# @dumpdtb:
+#
+# Save the FDT in dtb format.
+#
+# @filename: name of the dtb file to be created
+#
+# Since: 7.2
+#
+# Example:
+# {"execute": "dumpdtb"}
+#"arguments": { "filename": "fdt.dtb" } }
+#
+##
+{ 'command': 'dumpdtb',
+ 'data': { 'filename': 'str' },
+ 'if': 'CONFIG_FDT' }
diff --git a/softmmu/device_tree.c b/softmmu/device_tree.c
index 6ca3fad285..ce74f3d48d 100644
--- a/softmmu/device_tree.c
+++ b/softmmu/device_tree.c
@@ -26,6 +26,9 @@
#include "hw/loader.h"
#include "hw/boards.h"
#include "qemu/config-file.h"
+#include "qapi/qapi-commands-machine.h"
+#include "qapi/qmp/qdict.h"
+#include "monitor/hmp.h"
#include
@@ -643,3 +646,37 @@ out:
g_free(propcells);
return ret;
}
+
+void qmp_dumpdtb(const char *filename, Error **errp)
+{
+g_autoptr(GError) err = NULL;
+uint32_t size;
+
+if (!current_machine->fdt) {
+error_setg(errp, "This machine doesn't have a FDT");
+return;
+}
+
+size = fdt_totalsize(current_machine->fdt);
+
+g_assert(size > 0);
+
+if (!g_file_set_contents(filename, current_machine->fdt, size, )) {
+error_setg(errp, "Error saving FDT to file %s: %s",
+ filename, err->message);
+}
+}
+
+void hmp_dumpdtb(Monitor *mon, const QDict *qdict)
+{
+const char *filename = qdict_get_str(qdict, "filename");
+Error *local_err = NULL;
+
+qmp_dumpdtb(filename, _err);
+
+if (hmp_handle_error(mon, local_err)) {
+return;
+}
+
+info_report("dtb dumped to %s", filename);
+}
--
2.37.3
[PULL 19/38] ppc440_uc.c: Remove unneeded parenthesis
From: BALATON Zoltan
Remove unneeded parenthesis around case labels.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<19db326bea989c03e08f2853f789315bbe806fe9.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_uc.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 57274b56dd..5fbf44009e 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -499,34 +499,34 @@ static uint32_t sdram_ddr2_bcr(hwaddr ram_base, hwaddr
ram_size)
uint32_t bcr;
switch (ram_size) {
-case (8 * MiB):
+case 8 * MiB:
bcr = 0xffc0;
break;
-case (16 * MiB):
+case 16 * MiB:
bcr = 0xff80;
break;
-case (32 * MiB):
+case 32 * MiB:
bcr = 0xff00;
break;
-case (64 * MiB):
+case 64 * MiB:
bcr = 0xfe00;
break;
-case (128 * MiB):
+case 128 * MiB:
bcr = 0xfc00;
break;
-case (256 * MiB):
+case 256 * MiB:
bcr = 0xf800;
break;
-case (512 * MiB):
+case 512 * MiB:
bcr = 0xf000;
break;
-case (1 * GiB):
+case 1 * GiB:
bcr = 0xe000;
break;
-case (2 * GiB):
+case 2 * GiB:
bcr = 0xc000;
break;
-case (4 * GiB):
+case 4 * GiB:
bcr = 0x8000;
break;
default:
--
2.37.3
[PULL 14/38] ppc440_sdram: Rename local variable for readability
From: BALATON Zoltan
Rename local sdram variable in ppc440_sdram_init to s for readability.
Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Message-Id:
<7351b80fa321c32a6229e685dfdc940232f8b788.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_uc.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index e8bc088c8f..97e6d5f5b2 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -734,40 +734,40 @@ static void sdram_reset(void *opaque)
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
Ppc4xxSdramBank *ram_banks)
{
-ppc440_sdram_t *sdram;
+ppc440_sdram_t *s;
int i;
-sdram = g_malloc0(sizeof(*sdram));
-sdram->nbanks = nbanks;
+s = g_malloc0(sizeof(*s));
+s->nbanks = nbanks;
for (i = 0; i < nbanks; i++) {
-sdram->bank[i].ram = ram_banks[i].ram;
-sdram->bank[i].base = ram_banks[i].base;
-sdram->bank[i].size = ram_banks[i].size;
+s->bank[i].ram = ram_banks[i].ram;
+s->bank[i].base = ram_banks[i].base;
+s->bank[i].size = ram_banks[i].size;
}
-qemu_register_reset(_reset, sdram);
+qemu_register_reset(_reset, s);
ppc_dcr_register(env, SDRAM0_CFGADDR,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM0_CFGDATA,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_R0BAS,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_R1BAS,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_R2BAS,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_R3BAS,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_CONF1HB,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_PLBADDULL,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_CONF1LL,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_CONFPATHB,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM_PLBADDUHB,
- sdram, _read_sdram, _write_sdram);
+ s, _read_sdram, _write_sdram);
}
void ppc440_sdram_enable(CPUPPCState *env)
--
2.37.3
[PULL 12/38] ppc440_sdram: Implement enable bit in the DDR2 SDRAM controller
From: BALATON Zoltan
To allow removing the do_init hack we need to improve the DDR2 SDRAM
controller model to handle the enable/disable bit that it ignored so
far.
Signed-off-by: BALATON Zoltan
Reviewed-by: Daniel Henrique Barboza
Message-Id:
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_uc.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 900b7ab998..3fbfe4ad13 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -485,6 +485,7 @@ void ppc4xx_sdr_init(CPUPPCState *env)
/* SDRAM controller */
typedef struct ppc440_sdram_t {
uint32_t addr;
+uint32_t mcopt2;
int nbanks;
Ppc4xxSdramBank bank[4];
} ppc440_sdram_t;
@@ -600,7 +601,7 @@ static void sdram_map_bcr(ppc440_sdram_t *sdram)
int i;
for (i = 0; i < sdram->nbanks; i++) {
-if (sdram->bank[i].size != 0) {
+if (sdram->bank[i].size) {
sdram_set_bcr(sdram, i, sdram_bcr(sdram->bank[i].base,
sdram->bank[i].size), 1);
} else {
@@ -609,6 +610,17 @@ static void sdram_map_bcr(ppc440_sdram_t *sdram)
}
}
+static void sdram_unmap_bcr(ppc440_sdram_t *sdram)
+{
+int i;
+
+for (i = 0; i < sdram->nbanks; i++) {
+if (sdram->bank[i].size) {
+sdram_set_bcr(sdram, i, sdram->bank[i].bcr & ~1, 0);
+}
+}
+}
+
static uint32_t dcr_read_sdram(void *opaque, int dcrn)
{
ppc440_sdram_t *sdram = opaque;
@@ -640,7 +652,7 @@ static uint32_t dcr_read_sdram(void *opaque, int dcrn)
ret = 0x8000;
break;
case 0x21: /* SDRAM_MCOPT2 */
-ret = 0x0800;
+ret = sdram->mcopt2;
break;
case 0x40: /* SDRAM_MB0CF */
ret = 0x8001;
@@ -662,6 +674,8 @@ static uint32_t dcr_read_sdram(void *opaque, int dcrn)
return ret;
}
+#define SDRAM_DDR2_MCOPT2_DCEN BIT(27)
+
static void dcr_write_sdram(void *opaque, int dcrn, uint32_t val)
{
ppc440_sdram_t *sdram = opaque;
@@ -684,6 +698,21 @@ static void dcr_write_sdram(void *opaque, int dcrn,
uint32_t val)
switch (sdram->addr) {
case 0x00: /* B0CR */
break;
+case 0x21: /* SDRAM_MCOPT2 */
+if (!(sdram->mcopt2 & SDRAM_DDR2_MCOPT2_DCEN) &&
+(val & SDRAM_DDR2_MCOPT2_DCEN)) {
+trace_ppc4xx_sdram_enable("enable");
+/* validate all RAM mappings */
+sdram_map_bcr(sdram);
+sdram->mcopt2 |= SDRAM_DDR2_MCOPT2_DCEN;
+} else if ((sdram->mcopt2 & SDRAM_DDR2_MCOPT2_DCEN) &&
+ !(val & SDRAM_DDR2_MCOPT2_DCEN)) {
+trace_ppc4xx_sdram_enable("disable");
+/* invalidate all RAM mappings */
+sdram_unmap_bcr(sdram);
+sdram->mcopt2 &= ~SDRAM_DDR2_MCOPT2_DCEN;
+}
+break;
default:
break;
}
@@ -698,6 +727,7 @@ static void sdram_reset(void *opaque)
ppc440_sdram_t *sdram = opaque;
sdram->addr = 0;
+sdram->mcopt2 = SDRAM_DDR2_MCOPT2_DCEN;
}
void ppc440_sdram_init(CPUPPCState *env, int nbanks,
--
2.37.3
[PULL 10/38] ppc4xx_sdram: Drop extra zeros for readability
From: BALATON Zoltan
Constants that are written zero padded for no good reason are hard to
read, it's easier to see what is meant if it's just 0 or 1 instead.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
<93974622c3d398c7d3a3488b678b74c3807849de.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc4xx_devs.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index 3d700e5c85..02ac8ff335 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -54,31 +54,31 @@ static uint32_t sdram_ddr_bcr(hwaddr ram_base, hwaddr
ram_size)
switch (ram_size) {
case 4 * MiB:
-bcr = 0x;
+bcr = 0;
break;
case 8 * MiB:
-bcr = 0x0002;
+bcr = 0x2;
break;
case 16 * MiB:
-bcr = 0x0004;
+bcr = 0x4;
break;
case 32 * MiB:
-bcr = 0x0006;
+bcr = 0x6;
break;
case 64 * MiB:
-bcr = 0x0008;
+bcr = 0x8;
break;
case 128 * MiB:
-bcr = 0x000A;
+bcr = 0xA;
break;
case 256 * MiB:
-bcr = 0x000C;
+bcr = 0xC;
break;
default:
qemu_log_mask(LOG_GUEST_ERROR,
"%s: invalid RAM size 0x%" HWADDR_PRIx "\n", __func__,
ram_size);
-return 0x;
+return 0;
}
bcr |= ram_base & 0xFF80;
bcr |= 1;
@@ -109,7 +109,7 @@ static target_ulong sdram_size(uint32_t bcr)
static void sdram_set_bcr(Ppc4xxSdramDdrState *sdram, int i,
uint32_t bcr, int enabled)
{
-if (sdram->bank[i].bcr & 0x0001) {
+if (sdram->bank[i].bcr & 1) {
/* Unmap RAM */
trace_ppc4xx_sdram_unmap(sdram_base(sdram->bank[i].bcr),
sdram_size(sdram->bank[i].bcr));
@@ -120,7 +120,7 @@ static void sdram_set_bcr(Ppc4xxSdramDdrState *sdram, int i,
object_unparent(OBJECT(>bank[i].container));
}
sdram->bank[i].bcr = bcr & 0xFFDEE001;
-if (enabled && (bcr & 0x0001)) {
+if (enabled && (bcr & 1)) {
trace_ppc4xx_sdram_map(sdram_base(bcr), sdram_size(bcr));
memory_region_init(>bank[i].container, NULL, "sdram-container",
sdram_size(bcr));
@@ -141,7 +141,7 @@ static void sdram_map_bcr(Ppc4xxSdramDdrState *sdram)
sdram_set_bcr(sdram, i, sdram_ddr_bcr(sdram->bank[i].base,
sdram->bank[i].size), 1);
} else {
-sdram_set_bcr(sdram, i, 0x, 0);
+sdram_set_bcr(sdram, i, 0, 0);
}
}
}
@@ -218,7 +218,7 @@ static uint32_t sdram_ddr_dcr_read(void *opaque, int dcrn)
break;
default:
/* Avoid gcc warning */
-ret = 0x;
+ret = 0;
break;
}
@@ -311,18 +311,18 @@ static void ppc4xx_sdram_ddr_reset(DeviceState *dev)
{
Ppc4xxSdramDdrState *sdram = PPC4xx_SDRAM_DDR(dev);
-sdram->addr = 0x;
-sdram->bear = 0x;
-sdram->besr0 = 0x; /* No error */
-sdram->besr1 = 0x; /* No error */
-sdram->cfg = 0x;
-sdram->ecccfg = 0x; /* No ECC */
-sdram->eccesr = 0x; /* No error */
+sdram->addr = 0;
+sdram->bear = 0;
+sdram->besr0 = 0; /* No error */
+sdram->besr1 = 0; /* No error */
+sdram->cfg = 0;
+sdram->ecccfg = 0; /* No ECC */
+sdram->eccesr = 0; /* No error */
sdram->pmit = 0x07C0;
sdram->rtr = 0x05F0;
sdram->tr = 0x00854009;
/* We pre-initialize RAM banks */
-sdram->status = 0x;
+sdram->status = 0;
sdram->cfg = 0x0080;
}
--
2.37.3
[PULL 05/38] ppc4xx_sdram: Get rid of the init RAM hack
From: BALATON Zoltan
The do_init parameter of ppc4xx_sdram_init() is used to map memory
regions that is normally done by the firmware by programming the SDRAM
controller. Do this from board code emulating what firmware would do
when booting a kernel directly from -kernel without a firmware so we
can get rid of this do_init hack.
Signed-off-by: BALATON Zoltan
Reviewed-by: Daniel Henrique Barboza
Message-Id:
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc405.h | 1 -
hw/ppc/ppc405_boards.c | 3 +--
hw/ppc/ppc405_uc.c | 4 +---
hw/ppc/ppc440_bamboo.c | 4 +++-
hw/ppc/ppc4xx_devs.c| 12 +++-
include/hw/ppc/ppc4xx.h | 5 +++--
6 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 1e558c7831..756865621b 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -169,7 +169,6 @@ struct Ppc405SoCState {
/* Public */
MemoryRegion ram_banks[2];
hwaddr ram_bases[2], ram_sizes[2];
-bool do_dram_init;
MemoryRegion *dram_mr;
hwaddr ram_size;
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 083f12b23e..1eaeca8806 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -288,8 +288,6 @@ static void ppc405_init(MachineState *machine)
machine->ram_size, _fatal);
object_property_set_link(OBJECT(>soc), "dram",
OBJECT(machine->ram), _abort);
-object_property_set_bool(OBJECT(>soc), "dram-init",
- kernel_filename != NULL, _abort);
object_property_set_uint(OBJECT(>soc), "sys-clk", ,
_abort);
qdev_realize(DEVICE(>soc), NULL, _fatal);
@@ -349,6 +347,7 @@ static void ppc405_init(MachineState *machine)
/* Load ELF kernel and rootfs.cpio */
} else if (kernel_filename && !machine->firmware) {
+ppc4xx_sdram_enable(>soc.cpu.env);
boot_from_kernel(machine, >soc.cpu);
}
}
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 2ca42fdef6..1e02347e57 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1081,8 +1081,7 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
s->ram_bases[0], s->ram_sizes[0]);
ppc4xx_sdram_init(env, qdev_get_gpio_in(DEVICE(>uic), 17), 1,
- s->ram_banks, s->ram_bases, s->ram_sizes,
- s->do_dram_init);
+ s->ram_banks, s->ram_bases, s->ram_sizes);
/* External bus controller */
if (!ppc4xx_dcr_realize(PPC4xx_DCR_DEVICE(>ebc), >cpu, errp)) {
@@ -1160,7 +1159,6 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
static Property ppc405_soc_properties[] = {
DEFINE_PROP_LINK("dram", Ppc405SoCState, dram_mr, TYPE_MEMORY_REGION,
MemoryRegion *),
-DEFINE_PROP_BOOL("dram-init", Ppc405SoCState, do_dram_init, 0),
DEFINE_PROP_UINT64("ram-size", Ppc405SoCState, ram_size, 0),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 5ec82fa8c2..409a8840da 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -211,7 +211,9 @@ static void bamboo_init(MachineState *machine)
ppc4xx_sdram_init(env,
qdev_get_gpio_in(uicdev, 14),
PPC440EP_SDRAM_NR_BANKS, ram_memories,
- ram_bases, ram_sizes, 1);
+ ram_bases, ram_sizes);
+/* Enable SDRAM memory regions, this should be done by the firmware */
+ppc4xx_sdram_enable(env);
/* PCI */
dev = sysbus_create_varargs(TYPE_PPC4xx_PCI_HOST_BRIDGE,
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index 1226ec4aa9..3475589679 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -350,8 +350,7 @@ static void sdram_reset(void *opaque)
void ppc4xx_sdram_init(CPUPPCState *env, qemu_irq irq, int nbanks,
MemoryRegion *ram_memories,
hwaddr *ram_bases,
- hwaddr *ram_sizes,
- int do_init)
+ hwaddr *ram_sizes)
{
ppc4xx_sdram_t *sdram;
int i;
@@ -369,9 +368,12 @@ void ppc4xx_sdram_init(CPUPPCState *env, qemu_irq irq, int
nbanks,
sdram, _read_sdram, _write_sdram);
ppc_dcr_register(env, SDRAM0_CFGDATA,
sdram, _read_sdram, _write_sdram);
-if (do_init) {
-sdram_map_bcr(sdram);
-}
+}
+
+void ppc4xx_sdram_enable(CPUPPCState *env)
+{
+ppc_dcr_write(env->dcr_env, SDRAM0_CFGADDR, 0x20);
+ppc_dcr_write(env->dcr_env, SDRAM0_CFGDATA, 0x8000);
}
/*
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 2af0d60577..13b3229851 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -37,6 +37,8 @@ typedef struct {
uint32_t bcr;
} Ppc4xxSdramBank;
+void ppc4xx_sdram_enable(CPUPPCState *env);
+
[PULL 04/38] ppc4xx: Introduce Ppc4xxSdramBank struct
From: BALATON Zoltan
Instead of storing sdram bank parameters in unrelated arrays put them
in a struct so it's clear they belong to the same bank and simplify
the state struct using this bank type.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
<5eb82d0424c584b2b9e6f7bc51560f8189ed21bb.1664021647.git.bala...@eik.bme.hu>
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/ppc440_uc.c | 49 +-
hw/ppc/ppc4xx_devs.c| 59 -
include/hw/ppc/ppc4xx.h | 8 ++
3 files changed, 61 insertions(+), 55 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 53e981ddf4..db4e29 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -16,7 +16,7 @@
#include "qemu/module.h"
#include "hw/irq.h"
#include "exec/memory.h"
-#include "hw/ppc/ppc.h"
+#include "hw/ppc/ppc4xx.h"
#include "hw/qdev-properties.h"
#include "hw/pci/pci.h"
#include "sysemu/block-backend.h"
@@ -485,11 +485,7 @@ void ppc4xx_sdr_init(CPUPPCState *env)
typedef struct ppc440_sdram_t {
uint32_t addr;
int nbanks;
-MemoryRegion containers[4]; /* used for clipping */
-MemoryRegion *ram_memories;
-hwaddr ram_bases[4];
-hwaddr ram_sizes[4];
-uint32_t bcr[4];
+Ppc4xxSdramBank bank[4];
} ppc440_sdram_t;
enum {
@@ -570,23 +566,23 @@ static uint64_t sdram_size(uint32_t bcr)
static void sdram_set_bcr(ppc440_sdram_t *sdram, int i,
uint32_t bcr, int enabled)
{
-if (sdram->bcr[i] & 1) {
+if (sdram->bank[i].bcr & 1) {
/* First unmap RAM if enabled */
memory_region_del_subregion(get_system_memory(),
->containers[i]);
-memory_region_del_subregion(>containers[i],
->ram_memories[i]);
-object_unparent(OBJECT(>containers[i]));
+>bank[i].container);
+memory_region_del_subregion(>bank[i].container,
+>bank[i].ram);
+object_unparent(OBJECT(>bank[i].container));
}
-sdram->bcr[i] = bcr & 0xffe0ffc1;
+sdram->bank[i].bcr = bcr & 0xffe0ffc1;
if (enabled && (bcr & 1)) {
-memory_region_init(>containers[i], NULL, "sdram-containers",
+memory_region_init(>bank[i].container, NULL, "sdram-container",
sdram_size(bcr));
-memory_region_add_subregion(>containers[i], 0,
->ram_memories[i]);
+memory_region_add_subregion(>bank[i].container, 0,
+>bank[i].ram);
memory_region_add_subregion(get_system_memory(),
sdram_base(bcr),
->containers[i]);
+>bank[i].container);
}
}
@@ -595,9 +591,9 @@ static void sdram_map_bcr(ppc440_sdram_t *sdram)
int i;
for (i = 0; i < sdram->nbanks; i++) {
-if (sdram->ram_sizes[i] != 0) {
-sdram_set_bcr(sdram, i, sdram_bcr(sdram->ram_bases[i],
- sdram->ram_sizes[i]), 1);
+if (sdram->bank[i].size != 0) {
+sdram_set_bcr(sdram, i, sdram_bcr(sdram->bank[i].base,
+ sdram->bank[i].size), 1);
} else {
sdram_set_bcr(sdram, i, 0, 0);
}
@@ -614,9 +610,9 @@ static uint32_t dcr_read_sdram(void *opaque, int dcrn)
case SDRAM_R1BAS:
case SDRAM_R2BAS:
case SDRAM_R3BAS:
-if (sdram->ram_sizes[dcrn - SDRAM_R0BAS]) {
-ret = sdram_bcr(sdram->ram_bases[dcrn - SDRAM_R0BAS],
-sdram->ram_sizes[dcrn - SDRAM_R0BAS]);
+if (sdram->bank[dcrn - SDRAM_R0BAS].size) {
+ret = sdram_bcr(sdram->bank[dcrn - SDRAM_R0BAS].base,
+sdram->bank[dcrn - SDRAM_R0BAS].size);
}
break;
case SDRAM_CONF1HB:
@@ -701,12 +697,15 @@ void ppc440_sdram_init(CPUPPCState *env, int nbanks,
int do_init)
{
ppc440_sdram_t *sdram;
+int i;
sdram = g_malloc0(sizeof(*sdram));
sdram->nbanks = nbanks;
-sdram->ram_memories = ram_memories;
-memcpy(sdram->ram_bases, ram_bases, nbanks * sizeof(hwaddr));
-memcpy(sdram->ram_sizes, ram_sizes, nbanks * sizeof(hwaddr));
+for (i = 0; i < nbanks; i++) {
+sdram->bank[i].ram = ram_memories[i];
+sdram->bank[i].base = ram_bases[i];
+sdram->bank[i].size = ram_sizes[i];
+}
qemu_register_reset(_reset, sdram);
ppc_dcr_register(env, SDRAM0_CFGADDR,
sdram, _read_sdram, _write_sdram);
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index b4cd10f735..1226ec4aa9 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -42,10 +42,7 @@ typedef struct ppc4xx_sdram_t ppc4xx_sdram_t;
struct ppc4xx_sdram_t
[PULL 00/38] ppc queue
The following changes since commit 5c2439a92ce4a1c5a53070bd803d6f7647e702ca: Merge tag 'pull-riscv-to-apply-20221014' of https://github.com/alistair23/qemu into staging (2022-10-16 15:53:13 -0400) are available in the Git repository at: https://gitlab.com/danielhb/qemu.git tags/pull-ppc-20221017 for you to fetch changes up to 719b718ce27f52b2da600cc1abf6a41ac54dfa36: hw/riscv: set machine->fdt in spike_board_init() (2022-10-17 16:15:10 -0300) ppc patch queue for 2022-10-17: This queue contains improvements in the e500 and ppc4xx boards, changes in the maintainership of the project, a new QMP/HMP command and bug fixes: - Cedric is stepping back from qemu-ppc maintainership; - ppc4xx_sdram: QOMification and clean ups; - e500: add new types of flash and clean ups; - QMP/HMP: introduce dumpdtb command; - spapr_pci, booke doorbell interrupt and xvcmp* bit fixes; The 'dumpdtb' implementation is also making changes to RISC-V files that were acked by Alistair Francis and are being included in this queue. BALATON Zoltan (17): ppc440_bamboo: Remove unnecessary memsets ppc4xx: Introduce Ppc4xxSdramBank struct ppc4xx_sdram: Get rid of the init RAM hack ppc4xx: Use Ppc4xxSdramBank in ppc4xx_sdram_banks() ppc440_bamboo: Add missing 4 MiB valid memory size ppc4xx_sdram: Move size check to ppc4xx_sdram_init() ppc4xx_sdram: QOM'ify ppc4xx_sdram: Drop extra zeros for readability ppc440_sdram: Split off map/unmap of sdram banks for later reuse ppc440_sdram: Implement enable bit in the DDR2 SDRAM controller ppc440_sdram: Get rid of the init RAM hack ppc440_sdram: Rename local variable for readability ppc4xx_sdram: Rename functions to prevent name clashes ppc440_sdram: Move RAM size check to ppc440_sdram_init ppc440_sdram: QOM'ify ppc440_uc.c: Move some macros to ppc4xx.h ppc440_uc.c: Remove unneeded parenthesis Bernhard Beschow (7): hw/ppc/meson: Allow e500 boards to be enabled separately hw/gpio/meson: Introduce dedicated config switch for hw/gpio/mpc8xxx docs/system/ppc/ppce500: Add heading for networking chapter hw/ppc/e500: Reduce usage of sysbus API hw/ppc/mpc8544ds: Rename wrongly named method hw/ppc/mpc8544ds: Add platform bus hw/ppc/e500: Remove if statement which is now always true Cédric Le Goater (1): MAINTAINERS: step back from PPC Daniel Henrique Barboza (10): qmp/hmp, device_tree.c: introduce dumpdtb hw/nios2: set machine->fdt in nios2_load_dtb() hw/ppc: set machine->fdt in bamboo_load_device_tree() hw/ppc: set machine->fdt in sam460ex_load_device_tree() hw/ppc: set machine->fdt in xilinx_load_device_tree() hw/ppc: set machine->fdt in pegasos2_machine_reset() hw/ppc: set machine->fdt in pnv_reset() hw/ppc: set machine->fdt in spapr machine hw/riscv: set machine->fdt in sifive_u_machine_init() hw/riscv: set machine->fdt in spike_board_init() Nicholas Piggin (1): target/ppc: restore powerpc_excp_booke doorbell interrupts Peter Maydell (1): hw/ppc/spapr_pci.c: Use device_cold_reset() rather than device_legacy_reset() Víctor Colombo (1): target/ppc: Fix xvcmp* clearing FI bit MAINTAINERS | 10 +- configs/devices/ppc-softmmu/default.mak | 3 +- docs/system/ppc/ppce500.rst | 3 + hmp-commands.hx | 15 ++ hw/gpio/Kconfig | 3 + hw/gpio/meson.build | 2 +- hw/nios2/boot.c | 8 +- hw/nios2/meson.build| 2 +- hw/ppc/Kconfig | 9 ++ hw/ppc/e500.c | 30 ++-- hw/ppc/e500.h | 1 - hw/ppc/e500plat.c | 1 - hw/ppc/meson.build | 6 +- hw/ppc/mpc8544ds.c | 9 +- hw/ppc/pegasos2.c | 4 + hw/ppc/pnv.c| 8 +- hw/ppc/ppc405.h | 8 +- hw/ppc/ppc405_boards.c | 13 +- hw/ppc/ppc405_uc.c | 33 ++-- hw/ppc/ppc440.h | 4 - hw/ppc/ppc440_bamboo.c | 50 +++ hw/ppc/ppc440_uc.c | 257 hw/ppc/ppc4xx_devs.c| 241 +++--- hw/ppc/sam460ex.c | 65 hw/ppc/spapr.c | 3 + hw/ppc/spapr_hcall.c| 8 + hw/ppc/spapr_pci.c | 2 +- hw/ppc/virtex_ml507.c | 25 ++-- hw/riscv/sifive_u.c | 3 + hw/riscv/spike.c|
[PULL 01/38] MAINTAINERS: step back from PPC
From: Cédric Le Goater I am not active anymore on the PPC maintainership, degrade my self as standard Reviewer. Also degrade PowerNV and XIVE status since I am not funded for this work. Signed-off-by: Cédric Le Goater Reviewed-by: Greg Kurz Reviewed-by: David Gibson Reviewed-by: Alex Bennée Message-Id: <20220929180946.848721-1-...@kaod.org> Signed-off-by: Daniel Henrique Barboza --- MAINTAINERS | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8ae2e43c83..d86d21ae4e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -267,8 +267,8 @@ F: hw/openrisc/ F: tests/tcg/openrisc/ PowerPC TCG CPUs -M: Cédric Le Goater M: Daniel Henrique Barboza +R: Cédric Le Goater R: David Gibson R: Greg Kurz L: qemu-...@nongnu.org @@ -392,8 +392,8 @@ F: target/mips/kvm* F: target/mips/sysemu/ PPC KVM CPUs -M: Cédric Le Goater M: Daniel Henrique Barboza +R: Cédric Le Goater R: David Gibson R: Greg Kurz S: Maintained @@ -1365,8 +1365,8 @@ F: include/hw/rtc/m48t59.h F: tests/avocado/ppc_prep_40p.py sPAPR (pseries) -M: Cédric Le Goater M: Daniel Henrique Barboza +R: Cédric Le Goater R: David Gibson R: Greg Kurz L: qemu-...@nongnu.org @@ -1387,7 +1387,7 @@ F: tests/avocado/ppc_pseries.py PowerNV (Non-Virtualized) M: Cédric Le Goater L: qemu-...@nongnu.org -S: Maintained +S: Odd Fixes F: docs/system/ppc/powernv.rst F: hw/ppc/pnv* F: hw/intc/pnv* @@ -2333,7 +2333,7 @@ T: git https://github.com/philmd/qemu.git fw_cfg-next XIVE M: Cédric Le Goater L: qemu-...@nongnu.org -S: Supported +S: Odd Fixes F: hw/*/*xive* F: include/hw/*/*xive* F: docs/*/*xive* -- 2.37.3
[PATCH v2] nbd/client: Use smarter assert
Assigning strlen() to a uint32_t and then asserting that it isn't too
large doesn't catch the case of an input string 4G in length.
Thankfully, the incoming strings can never be that large: if the
export name or query is reflecting a string the client got from the
server, we already guarantee that we dropped the NBD connection if the
server sent more than 32M in a single reply to our NBD_OPT_* request;
if the export name is coming from qemu, nbd_receive_negotiate()
asserted that strlen(info->name) <= NBD_MAX_STRING_SIZE; and
similarly, a query string via x->dirty_bitmap coming from the user was
bounds-checked in either qemu-nbd or by the limitations of QMP.
Still, it doesn't hurt to be more explicit in how we write our
assertions to not have to analyze whether inadvertent wraparound is
possible.
Fixes: 93676c88 ("nbd: Don't send oversize strings", v4.2.0)
Reported-by: Dr. David Alan Gilbert
Signed-off-by: Eric Blake
---
v2: update subject line and commit message to reflect file being
touched; adjust a second nearby assertion with the same issue
nbd/client.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nbd/client.c b/nbd/client.c
index 30d5383cb1..90a6b7b38b 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -658,11 +658,11 @@ static int nbd_send_meta_query(QIOChannel *ioc, uint32_t
opt,
char *p;
data_len = sizeof(export_len) + export_len + sizeof(queries);
-assert(export_len <= NBD_MAX_STRING_SIZE);
+assert(strlen(export) <= NBD_MAX_STRING_SIZE);
if (query) {
query_len = strlen(query);
data_len += sizeof(query_len) + query_len;
-assert(query_len <= NBD_MAX_STRING_SIZE);
+assert(strlen(query) <= NBD_MAX_STRING_SIZE);
} else {
assert(opt == NBD_OPT_LIST_META_CONTEXT);
}
--
2.37.3
Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
Hi, > > > Using both private_fd and userspace_addr is only needed in TDX and other > > > confidential computing scenarios, pKVM may only use private_fd if the fd > > > can also be mmaped as a whole to userspace as Sean suggested. > > > > That does work in practice, for now at least, and is what I do in my > > current port. However, the naming and how the API is defined as > > implied by the name and the documentation. By calling the field > > private_fd, it does imply that it should not be mapped, which is also > > what api.rst says in PATCH v8 5/8. My worry is that in that case pKVM > > would be mis/ab-using this interface, and that future changes could > > cause unforeseen issues for pKVM. > > That is fairly enough. We can change the naming and the documents. > > > > > Maybe renaming this to something like "guest_fp", and specifying in > > the documentation that it can be restricted, e.g., instead of "the > > content of the private memory is invisible to userspace" something > > along the lines of "the content of the guest memory may be restricted > > to userspace". > > Some other candidates in my mind: > - restricted_fd: to pair with the mm side restricted_memfd > - protected_fd: as Sean suggested before > - fd: how it's explained relies on the memslot.flag. All these sound good, since they all capture the potential use cases. Restricted might be the most logical choice if that's going to also become the name for the mem_fd. Thanks, /fuad > Thanks, > Chao > > > > What do you think? > > > > Cheers, > > /fuad > > > > > > > > Thanks, > > > Chao > > > > > > > > Cheers, > > > > /fuad
Re: [PATCH] nbd/server: Use smarter assert
Given the file touched by this patch[1],
The subject should use 'nbd/client:'
On Mon, Oct 17, 2022 at 12:37:27PM -0500, Eric Blake wrote:
> Assigning strlen() to a uint32_t and then asserting that it isn't too
> large doesn't catch the case of an input string 4G in length.
> Thankfully, the incoming string can never be that large: if the export
> name is reflecting what the client asked about, we already guarantee
and this should be 'is reflecting a name provided by the server'...
> that we drop the NBD connection if the client tries to send more than
> 32M in a single NBD_OPT_* request; and if the export name is coming
...'if the server tries to send more than 32M in a reply to a single
NBD_OPT_* request from the client'
> from qemu, nbd_receive_negotiate() asserted that strlen(info->name) <=
> NBD_MAX_STRING_SIZE. Still, it doesn't hurt to be more explicit in
> how we write our assertion that we are aware that no wraparound is
> possible.
>
> Fixes: 93676c88 ("nbd: Don't send oversize strings", v4.2.0)
> Reported-by: Dr. David Alan Gilbert
> Signed-off-by: Eric Blake
> ---
> nbd/client.c | 2 +-
[1] this patch is to the client, not the server.
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/nbd/client.c b/nbd/client.c
> index 60c9f4941a..b601ee97e5 100644
> --- a/nbd/client.c
> +++ b/nbd/client.c
> @@ -658,7 +658,7 @@ static int nbd_send_meta_query(QIOChannel *ioc, uint32_t
> opt,
> char *p;
>
> data_len = sizeof(export_len) + export_len + sizeof(queries);
> -assert(export_len <= NBD_MAX_STRING_SIZE);
> +assert(strlen(export) <= NBD_MAX_STRING_SIZE);
> if (query) {
> query_len = strlen(query);
> data_len += sizeof(query_len) + query_len;
assert(query_len <= NBD_MAX_STRING_SIZE);
and this assertion on query_len could use the same treatment (similar
analysis as to why callers are never passing in a 4G string, but it
doesn't hurt to be explicit in the assertion). v2 coming up.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: [PATCH v4 2/2] target/riscv: Enable Zicbo[m,z,p] instructions
On Wed, Mar 16, 2022 at 1:01 AM Anup Patel wrote:
>
> On Wed, Feb 16, 2022 at 9:18 PM Christoph Muellner
> wrote:
> >
> > The RISC-V base cache management operation ISA extension has been
> > ratified. This patch adds support for the defined instructions.
> >
> > The cmo.prefetch instructions are nops for QEMU (no emulation of the memory
> > hierarchy, no illegal instructions, no permission faults, no traps),
> > therefore there's only a comment where they would be decoded.
> >
> > The other cbo* instructions are moved into an overlap group to
> > resolve the overlapping pattern with the LQ instruction.
> > The cbo* instructions perform permission checks and raise exceptions
> > according to the specification.
> >
> > The cache block sizes (for cbom and cboz) are configurable.
> >
> > Co-developed-by: Philipp Tomsich
> > Signed-off-by: Christoph Muellner
>
> Can you rebase this series upon Atish's "target/riscv: Add isa extenstion
> strings to the device tree" patch ?
>
> Also, please add cmo extensions in the generated ISA string.
>
I couldn't find a v5. Is this the latest version or did I miss something ?
> Regards,
> Anup
>
> > ---
> > target/riscv/cpu.c | 4 +
> > target/riscv/cpu.h | 4 +
> > target/riscv/helper.h | 5 ++
> > target/riscv/insn32.decode | 16 +++-
> > target/riscv/insn_trans/trans_rvzicbo.c.inc | 57
> > target/riscv/op_helper.c| 97 +
> > target/riscv/translate.c| 1 +
> > 7 files changed, 183 insertions(+), 1 deletion(-)
> > create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index 39ffb883fc..04500fe352 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -764,6 +764,10 @@ static Property riscv_cpu_properties[] = {
> > DEFINE_PROP_BOOL("Counters", RISCVCPU, cfg.ext_counters, true),
> > DEFINE_PROP_BOOL("Zifencei", RISCVCPU, cfg.ext_ifencei, true),
> > DEFINE_PROP_BOOL("Zicsr", RISCVCPU, cfg.ext_icsr, true),
> > +DEFINE_PROP_BOOL("zicbom", RISCVCPU, cfg.ext_icbom, true),
> > +DEFINE_PROP_BOOL("zicboz", RISCVCPU, cfg.ext_icboz, true),
> > +DEFINE_PROP_UINT16("cbom_blocksize", RISCVCPU, cfg.cbom_blocksize, 64),
> > +DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
> > DEFINE_PROP_BOOL("Zfh", RISCVCPU, cfg.ext_zfh, false),
> > DEFINE_PROP_BOOL("Zfhmin", RISCVCPU, cfg.ext_zfhmin, false),
> > DEFINE_PROP_BOOL("Zve32f", RISCVCPU, cfg.ext_zve32f, false),
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index fe80caeec0..5fda1fc7be 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -368,6 +368,8 @@ struct RISCVCPUConfig {
> > bool ext_counters;
> > bool ext_ifencei;
> > bool ext_icsr;
> > +bool ext_icbom;
> > +bool ext_icboz;
> > bool ext_zfh;
> > bool ext_zfhmin;
> > bool ext_zve32f;
> > @@ -382,6 +384,8 @@ struct RISCVCPUConfig {
> > char *vext_spec;
> > uint16_t vlen;
> > uint16_t elen;
> > +uint16_t cbom_blocksize;
> > +uint16_t cboz_blocksize;
> > bool mmu;
> > bool pmp;
> > bool epmp;
> > diff --git a/target/riscv/helper.h b/target/riscv/helper.h
> > index 72cc2582f4..ef1944da8f 100644
> > --- a/target/riscv/helper.h
> > +++ b/target/riscv/helper.h
> > @@ -92,6 +92,11 @@ DEF_HELPER_FLAGS_2(fcvt_h_l, TCG_CALL_NO_RWG, i64, env,
> > tl)
> > DEF_HELPER_FLAGS_2(fcvt_h_lu, TCG_CALL_NO_RWG, i64, env, tl)
> > DEF_HELPER_FLAGS_1(fclass_h, TCG_CALL_NO_RWG_SE, tl, i64)
> >
> > +/* Cache-block operations */
> > +DEF_HELPER_2(cbo_clean_flush, void, env, tl)
> > +DEF_HELPER_2(cbo_inval, void, env, tl)
> > +DEF_HELPER_2(cbo_zero, void, env, tl)
> > +
> > /* Special functions */
> > DEF_HELPER_2(csrr, tl, env, int)
> > DEF_HELPER_3(csrw, void, env, int, tl)
> > diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
> > index 5bbedc254c..d5f8329970 100644
> > --- a/target/riscv/insn32.decode
> > +++ b/target/riscv/insn32.decode
> > @@ -128,6 +128,7 @@ addi . 000 . 0010011 @i
> > slti . 010 . 0010011 @i
> > sltiu . 011 . 0010011 @i
> > xori . 100 . 0010011 @i
> > +# cbo.prefetch_{i,r,m} instructions are ori with rd=x0 and not decoded.
> > ori . 110 . 0010011 @i
> > andi . 111 . 0010011 @i
> > slli 0. ... 001 . 0010011 @sh
> > @@ -168,7 +169,20 @@ sraw 010 . . 101 . 0111011 @r
> >
> > # *** RV128I Base Instruction Set (in addition to RV64I) ***
> > ldu . 111 . 011 @i
> > -lq . 010 . 000 @i
> > +{
> > + [
> > +# *** RV32 Zicbom Standard Extension ***
> >
[PATCH 4/4] hw/usb: fix tab indentation
The TABs should be replaced with spaces, to make sure that we have a
consistent coding style with an indentation of 4 spaces everywhere.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/370
Signed-off-by: amarjargal
---
hw/usb/dev-hub.c | 86 +-
hw/usb/dev-network.c | 286 +++
hw/usb/dev-wacom.c |4 +-
hw/usb/hcd-musb.c | 328
hw/usb/quirks-pl2303-ids.h | 180 ++--
include/hw/usb.h | 118 +--
include/hw/usb/dwc2-regs.h | 1628 ++--
7 files changed, 1315 insertions(+), 1315 deletions(-)
diff --git a/hw/usb/dev-hub.c b/hw/usb/dev-hub.c
index e35813d772..2873c327b5 100644
--- a/hw/usb/dev-hub.c
+++ b/hw/usb/dev-hub.c
@@ -54,46 +54,46 @@ struct USBHubState {
#define TYPE_USB_HUB "usb-hub"
OBJECT_DECLARE_SIMPLE_TYPE(USBHubState, USB_HUB)
-#define ClearHubFeature(0x2000 | USB_REQ_CLEAR_FEATURE)
-#define ClearPortFeature (0x2300 | USB_REQ_CLEAR_FEATURE)
-#define GetHubDescriptor (0xa000 | USB_REQ_GET_DESCRIPTOR)
-#define GetHubStatus (0xa000 | USB_REQ_GET_STATUS)
-#define GetPortStatus (0xa300 | USB_REQ_GET_STATUS)
-#define SetHubFeature (0x2000 | USB_REQ_SET_FEATURE)
-#define SetPortFeature (0x2300 | USB_REQ_SET_FEATURE)
-
-#define PORT_STAT_CONNECTION 0x0001
-#define PORT_STAT_ENABLE 0x0002
-#define PORT_STAT_SUSPEND 0x0004
-#define PORT_STAT_OVERCURRENT 0x0008
-#define PORT_STAT_RESET0x0010
-#define PORT_STAT_POWER0x0100
-#define PORT_STAT_LOW_SPEED0x0200
+#define ClearHubFeature (0x2000 | USB_REQ_CLEAR_FEATURE)
+#define ClearPortFeature(0x2300 | USB_REQ_CLEAR_FEATURE)
+#define GetHubDescriptor(0xa000 | USB_REQ_GET_DESCRIPTOR)
+#define GetHubStatus(0xa000 | USB_REQ_GET_STATUS)
+#define GetPortStatus (0xa300 | USB_REQ_GET_STATUS)
+#define SetHubFeature (0x2000 | USB_REQ_SET_FEATURE)
+#define SetPortFeature (0x2300 | USB_REQ_SET_FEATURE)
+
+#define PORT_STAT_CONNECTION0x0001
+#define PORT_STAT_ENABLE0x0002
+#define PORT_STAT_SUSPEND 0x0004
+#define PORT_STAT_OVERCURRENT 0x0008
+#define PORT_STAT_RESET 0x0010
+#define PORT_STAT_POWER 0x0100
+#define PORT_STAT_LOW_SPEED 0x0200
#define PORT_STAT_HIGH_SPEED0x0400
#define PORT_STAT_TEST 0x0800
#define PORT_STAT_INDICATOR 0x1000
-#define PORT_STAT_C_CONNECTION 0x0001
-#define PORT_STAT_C_ENABLE 0x0002
-#define PORT_STAT_C_SUSPEND0x0004
-#define PORT_STAT_C_OVERCURRENT0x0008
-#define PORT_STAT_C_RESET 0x0010
-
-#define PORT_CONNECTION0
-#define PORT_ENABLE1
-#define PORT_SUSPEND 2
-#define PORT_OVERCURRENT 3
-#define PORT_RESET 4
-#define PORT_POWER 8
-#define PORT_LOWSPEED 9
-#define PORT_HIGHSPEED 10
-#define PORT_C_CONNECTION 16
-#define PORT_C_ENABLE 17
-#define PORT_C_SUSPEND 18
-#define PORT_C_OVERCURRENT 19
-#define PORT_C_RESET 20
-#define PORT_TEST 21
-#define PORT_INDICATOR 22
+#define PORT_STAT_C_CONNECTION0x0001
+#define PORT_STAT_C_ENABLE0x0002
+#define PORT_STAT_C_SUSPEND 0x0004
+#define PORT_STAT_C_OVERCURRENT 0x0008
+#define PORT_STAT_C_RESET 0x0010
+
+#define PORT_CONNECTION 0
+#define PORT_ENABLE 1
+#define PORT_SUSPEND 2
+#define PORT_OVERCURRENT 3
+#define PORT_RESET4
+#define PORT_POWER8
+#define PORT_LOWSPEED 9
+#define PORT_HIGHSPEED10
+#define PORT_C_CONNECTION 16
+#define PORT_C_ENABLE 17
+#define PORT_C_SUSPEND18
+#define PORT_C_OVERCURRENT19
+#define PORT_C_RESET 20
+#define PORT_TEST 21
+#define PORT_INDICATOR22
/* same as Linux kernel root hubs */
@@ -155,13 +155,13 @@ static const USBDesc desc_hub = {
static const uint8_t qemu_hub_hub_descriptor[] =
{
-0x00, /* u8 bLength; patched in later */
-0x29, /* u8 bDescriptorType; Hub-descriptor */
-0x00, /* u8 bNbrPorts; (patched later) */
-0x0a, /* u16 wHubCharacteristics; */
-0x00, /* (per-port OC, no power switching) */
-0x01, /* u8 bPwrOn2pwrGood; 2ms */
-0x00 /* u8 bHubContrCurrent; 0 mA */
+0x00,/* u8 bLength; patched in later */
+0x29,/* u8 bDescriptorType; Hub-descriptor */
+0x00,/* u8 bNbrPorts; (patched later) */
+0x0a,/* u16 wHubCharacteristics; */
+0x00,/* (per-port OC, no power switching) */
+0x01,/* u8 bPwrOn2pwrGood; 2ms */
+0x00/* u8 bHubContrCurrent; 0 mA */
/* DeviceRemovable and
[PATCH 2/4] hw/audio: fix tab indentation into spaces
The TABs should be replaced with spaces, to make sure that we have a
consistent coding style with an indentation of 4 spaces everywhere.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/370
Signed-off-by: amarjargal
---
hw/audio/fmopl.c | 1664 ++---
hw/audio/fmopl.h | 138 +--
hw/audio/intel-hda-defs.h | 1008 +++---
hw/audio/wm8750.c | 270 +++---
4 files changed, 1540 insertions(+), 1540 deletions(-)
diff --git a/hw/audio/fmopl.c b/hw/audio/fmopl.c
index 8a71a569fa..fd7371638d 100644
--- a/hw/audio/fmopl.c
+++ b/hw/audio/fmopl.c
@@ -9,9 +9,9 @@
*/
/*
- preliminary :
- Problem :
- note:
+preliminary :
+Problem :
+note:
*/
/* This version of fmopl.c is a fork of the MAME one, relicensed under the
LGPL.
@@ -32,7 +32,7 @@
#include "qemu/osdep.h"
#include
-//#include "driver.h" /* use M.A.M.E. */
+//#include "driver.h"/* use M.A.M.E. */
#include "fmopl.h"
#ifndef PI
#define PI 3.14159265358979323846
@@ -53,14 +53,14 @@ static int opl_dbg_maxchip,opl_dbg_chip;
#define DELTAT_MIXING_LEVEL (1) /* DELTA-T ADPCM MIXING LEVEL */
-#define FREQ_BITS 24 /* frequency turn */
+#define FREQ_BITS 24/* frequency turn */
/* counter bits = 20 , octerve 7 */
#define FREQ_RATE (1<<(FREQ_BITS-20))
#define TL_BITS(FREQ_BITS+2)
/* final output shift , limit minimum and maximum */
-#define OPL_OUTSB (TL_BITS+3-16) /* OPL output final shift 16bit
*/
+#define OPL_OUTSB (TL_BITS+3-16)/* OPL output final shift 16bit */
#define OPL_MAXOUT (0x7fff<=LOG_LEVEL ) logerror x
#define LOG(n,x)
@@ -237,204 +237,204 @@ static int32_t feedback2; /* connect for
SLOT 2 */
/* - subroutines - */
static inline int Limit( int val, int max, int min ) {
- if ( val > max )
- val = max;
- else if ( val < min )
- val = min;
+if ( val > max )
+val = max;
+else if ( val < min )
+val = min;
- return val;
+return val;
}
/* status set and IRQ handling */
static inline void OPL_STATUS_SET(FM_OPL *OPL,int flag)
{
- /* set status flag */
- OPL->status |= flag;
- if(!(OPL->status & 0x80))
- {
- if(OPL->status & OPL->statusmask)
- { /* IRQ on */
- OPL->status |= 0x80;
- }
- }
+/* set status flag */
+OPL->status |= flag;
+if(!(OPL->status & 0x80))
+{
+if(OPL->status & OPL->statusmask)
+{/* IRQ on */
+OPL->status |= 0x80;
+}
+}
}
/* status reset and IRQ handling */
static inline void OPL_STATUS_RESET(FM_OPL *OPL,int flag)
{
- /* reset status flag */
- OPL->status &=~flag;
- if((OPL->status & 0x80))
- {
- if (!(OPL->status & OPL->statusmask) )
- {
- OPL->status &= 0x7f;
- }
- }
+/* reset status flag */
+OPL->status &=~flag;
+if((OPL->status & 0x80))
+{
+if (!(OPL->status & OPL->statusmask) )
+{
+OPL->status &= 0x7f;
+}
+}
}
/* IRQ mask set */
static inline void OPL_STATUSMASK_SET(FM_OPL *OPL,int flag)
{
- OPL->statusmask = flag;
- /* IRQ handling check */
- OPL_STATUS_SET(OPL,0);
- OPL_STATUS_RESET(OPL,0);
+OPL->statusmask = flag;
+/* IRQ handling check */
+OPL_STATUS_SET(OPL,0);
+OPL_STATUS_RESET(OPL,0);
}
/* - key on - */
static inline void OPL_KEYON(OPL_SLOT *SLOT)
{
- /* sin wave restart */
- SLOT->Cnt = 0;
- /* set attack */
- SLOT->evm = ENV_MOD_AR;
- SLOT->evs = SLOT->evsa;
- SLOT->evc = EG_AST;
- SLOT->eve = EG_AED;
+/* sin wave restart */
+SLOT->Cnt = 0;
+/* set attack */
+SLOT->evm = ENV_MOD_AR;
+SLOT->evs = SLOT->evsa;
+SLOT->evc = EG_AST;
+SLOT->eve = EG_AED;
}
/* - key off - */
static inline void OPL_KEYOFF(OPL_SLOT *SLOT)
{
- if( SLOT->evm > ENV_MOD_RR)
- {
- /* set envelope counter from envleope output */
- SLOT->evm = ENV_MOD_RR;
- if( !(SLOT->evc_DST) )
- //SLOT->evc =
(ENV_CURVE[SLOT->evc>>ENV_BITS]eve = EG_DED;
- SLOT->evs = SLOT->evsr;
- }
+if( SLOT->evm > ENV_MOD_RR)
+{
+/* set envelope counter from envleope output */
+SLOT->evm = ENV_MOD_RR;
+if( !(SLOT->evc_DST) )
+//SLOT->evc = (ENV_CURVE[SLOT->evc>>ENV_BITS]eve = EG_DED;
+SLOT->evs = SLOT->evsr;
+}
}
/* -- calcrate Envelope Generator & Phase Generator -- */
/* return : envelope output */
static inline uint32_t OPL_CALC_SLOT(
[PATCH 0/4] ui:hw: fix tab indentation
There are still a lot of old files in the QEMU UI, graphics, audio and USB code base that use TABs for indentation instead of using 4 spaces in these files. The TABs should be replaced with spaces, to make sure that we have a consistent coding style with an indentation of 4 spaces everywhere. amarjargal (4): ui: fix tab indentation hw/audio: fix tab indentation into spaces hw/display: fix tab indentation hw/usb: fix tab indentation hw/audio/fmopl.c | 1664 +++--- hw/audio/fmopl.h | 138 +- hw/audio/intel-hda-defs.h| 1008 ++-- hw/audio/wm8750.c| 270 +- hw/display/blizzard.c| 352 +- hw/display/cirrus_vga.c | 1602 +++--- hw/display/omap_dss.c| 598 +-- hw/display/omap_lcdc.c | 24 +- hw/display/pxa2xx_lcd.c | 196 +- hw/display/tc6393xb.c| 74 +- hw/display/vga.c |6 +- hw/display/vga_regs.h|6 +- hw/display/xenfb.c | 260 +- hw/usb/dev-hub.c | 86 +- hw/usb/dev-network.c | 286 +- hw/usb/dev-wacom.c |4 +- hw/usb/hcd-musb.c| 328 +- hw/usb/quirks-pl2303-ids.h | 180 +- include/hw/usb.h | 118 +- include/hw/usb/dwc2-regs.h | 1628 +++--- ui/vgafont.h | 9214 +- ui/vnc-enc-zywrle-template.c | 20 +- ui/vnc-enc-zywrle.h | 16 +- ui/vnc_keysym.h |2 +- 24 files changed, 9040 insertions(+), 9040 deletions(-) -- 2.25.1
[PATCH v3 2/2] hw: misc: edu: rename local vars in edu_check_range
This serves to make the local variables a bit less ambiguous.
The latter two arguments are named to match DMA_START, and
DMA_SIZE.
Signed-off-by: Chris Friedt
---
hw/misc/edu.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index b3de8d206a..52afbd792a 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -103,24 +103,24 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
}
}
-static void edu_check_range(uint64_t addr, uint64_t size1,
-uint64_t start, uint64_t size2)
+static void edu_check_range(uint64_t xfer_start, uint64_t xfer_size,
+uint64_t dma_start, uint64_t dma_size)
{
-uint64_t end1 = addr + size1;
-uint64_t end2 = start + size2;
+uint64_t xfer_end = xfer_start + xfer_size;
+uint64_t dma_end = dma_start + dma_size;
/*
* 1. ensure we aren't overflowing
- * 2. ensure that [addr, end1) is within [start, size2)
+ * 2. ensure that xfer is within dma address range
*/
-if (end2 >= start && end1 >= addr &&
-addr >= start && end1 <= end2) {
+if (dma_end >= dma_start && xfer_end >= xfer_start &&
+xfer_start >= dma_start && xfer_end <= dma_end) {
return;
}
hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
" out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
-addr, end1 - 1, start, end2 - 1);
+xfer_start, xfer_end - 1, dma_start, dma_end - 1);
}
static dma_addr_t edu_clamp_addr(const EduState *edu, dma_addr_t addr)
--
2.36.1
[PATCH v3 1/2] hw: misc: edu: fix 2 off-by-one errors
In the case that size1 was zero, because of the explicit
'end1 > addr' check, the range check would fail and the error
message would read as shown below. The correct comparison
is 'end1 >= addr'.
EDU: DMA range 0x4-0x3 out of bounds (0x4-0x40fff)!
At the opposite end, in the case that size1 was 4096, within()
would fail because of the non-inclusive check 'end1 < end2',
which should have been 'end1 <= end2'. The error message would
previously say
EDU: DMA range 0x4-0x40fff out of bounds (0x4-0x40fff)!
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1254
Signed-off-by: Chris Friedt
---
hw/misc/edu.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index e935c418d4..b3de8d206a 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -103,19 +103,18 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
}
}
-static bool within(uint64_t addr, uint64_t start, uint64_t end)
-{
-return start <= addr && addr < end;
-}
-
-static void edu_check_range(uint64_t addr, uint64_t size1, uint64_t start,
-uint64_t size2)
+static void edu_check_range(uint64_t addr, uint64_t size1,
+uint64_t start, uint64_t size2)
{
uint64_t end1 = addr + size1;
uint64_t end2 = start + size2;
-if (within(addr, start, end2) &&
-end1 > addr && within(end1, start, end2)) {
+/*
+ * 1. ensure we aren't overflowing
+ * 2. ensure that [addr, end1) is within [start, size2)
+ */
+if (end2 >= start && end1 >= addr &&
+addr >= start && end1 <= end2) {
return;
}
--
2.36.1
Re: [PATCH] nbd/server: Use smarter assert
* Eric Blake (ebl...@redhat.com) wrote:
> Assigning strlen() to a uint32_t and then asserting that it isn't too
> large doesn't catch the case of an input string 4G in length.
> Thankfully, the incoming string can never be that large: if the export
> name is reflecting what the client asked about, we already guarantee
> that we drop the NBD connection if the client tries to send more than
> 32M in a single NBD_OPT_* request; and if the export name is coming
> from qemu, nbd_receive_negotiate() asserted that strlen(info->name) <=
> NBD_MAX_STRING_SIZE. Still, it doesn't hurt to be more explicit in
> how we write our assertion that we are aware that no wraparound is
> possible.
>
> Fixes: 93676c88 ("nbd: Don't send oversize strings", v4.2.0)
> Reported-by: Dr. David Alan Gilbert
> Signed-off-by: Eric Blake
Reviewed-by: Dr. David Alan Gilbert
> ---
> nbd/client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/nbd/client.c b/nbd/client.c
> index 60c9f4941a..b601ee97e5 100644
> --- a/nbd/client.c
> +++ b/nbd/client.c
> @@ -658,7 +658,7 @@ static int nbd_send_meta_query(QIOChannel *ioc, uint32_t
> opt,
> char *p;
>
> data_len = sizeof(export_len) + export_len + sizeof(queries);
> -assert(export_len <= NBD_MAX_STRING_SIZE);
> +assert(strlen(export) <= NBD_MAX_STRING_SIZE);
> if (query) {
> query_len = strlen(query);
> data_len += sizeof(query_len) + query_len;
> --
> 2.37.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PATCH] nbd/server: Use smarter assert
Assigning strlen() to a uint32_t and then asserting that it isn't too
large doesn't catch the case of an input string 4G in length.
Thankfully, the incoming string can never be that large: if the export
name is reflecting what the client asked about, we already guarantee
that we drop the NBD connection if the client tries to send more than
32M in a single NBD_OPT_* request; and if the export name is coming
from qemu, nbd_receive_negotiate() asserted that strlen(info->name) <=
NBD_MAX_STRING_SIZE. Still, it doesn't hurt to be more explicit in
how we write our assertion that we are aware that no wraparound is
possible.
Fixes: 93676c88 ("nbd: Don't send oversize strings", v4.2.0)
Reported-by: Dr. David Alan Gilbert
Signed-off-by: Eric Blake
---
nbd/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nbd/client.c b/nbd/client.c
index 60c9f4941a..b601ee97e5 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -658,7 +658,7 @@ static int nbd_send_meta_query(QIOChannel *ioc, uint32_t
opt,
char *p;
data_len = sizeof(export_len) + export_len + sizeof(queries);
-assert(export_len <= NBD_MAX_STRING_SIZE);
+assert(strlen(export) <= NBD_MAX_STRING_SIZE);
if (query) {
query_len = strlen(query);
data_len += sizeof(query_len) + query_len;
--
2.37.3
Re: [PATCH v3] qapi/qmp: Add timestamps to qmp command responses
Denis Plotnikov writes: > On 14.10.2022 16:19, Daniel P. Berrangé wrote: >> On Fri, Oct 14, 2022 at 02:57:06PM +0200, Markus Armbruster wrote: >>> Daniel P. Berrangé writes: >>> On Fri, Oct 14, 2022 at 11:31:13AM +0200, Markus Armbruster wrote: > Daniel P. Berrangé writes: > >> On Thu, Oct 13, 2022 at 05:00:26PM +0200, Markus Armbruster wrote: >>> Denis Plotnikov writes: >>> Add "start" & "end" time values to qmp command responses. >>> Please spell it QMP. More of the same below. >>> These time values are added to let the qemu management layer get the exact command execution time without any other time variance which might be brought by other parts of management layer or qemu internals. This is particulary useful for the management layer logging for later problems resolving. >>> I'm still having difficulties seeing the value add over existing >>> tracepoints and logging. >>> >>> Can you tell me about a problem you cracked (or could have cracked) with >>> the help of this? >> Consider your QMP client is logging all commands and replies in its >> own logfile (libvirt can do this). Having this start/end timestamps >> included means the QMP client log is self contained. > A QMP client can include client-side timestamps in its log. What value > is being added by server-side timestamps? According to the commit > message, it's for getting "the exact command execution time without any > other time variance which might be brought by other parts of management > layer or qemu internals." Why is that useful? In particular, why is > excluding network and QEMU queueing delays (inbound and outbound) > useful? Lets, say some commands normally runs in ~100ms, but occasionally runs in 2secs, and you want to understand why. A first step is understanding whether a given command itself is slow at executing, or whether its execution has merely been delayed because some other aspect of QEMU has delayed its execution. If the server timestamps show it was very fast, then that indicates delayed processing. Thus instead of debugging the slow command, I can think about what scenarios would be responsible for the delay. Perhaps a previous QMP command was very slow, or maybe there is simply a large volume of QMP commands backlogged, or some part of QEMU got blocked. Another case would be a command that is normally fast, and sometimes is slower, but still relatively fast. The network and queueing side might be a significant enough proportion of the total time to obscure the slowdown. If you can eliminate the non-execution time, you can see the performance trends over time to spot the subtle slowdowns and detect abnormal behaviour before it becomes too terrible. >>> This is troubleshooting. Asking for better troubleshooting tools is >>> fair. >>> >>> However, the proposed timestamps provide much more limited insight than >>> existing tracepoints. For instance, enabling >> tracepoints are absolutely great and let you get a hell of alot >> more information, *provided* you are in a position to actually >> use tracepoints. This is, unfortunately, frequently not the case >> when supporting real world production deployments. > > Exactly!!! Thanks for the pointing out! >> >> Bug reports from customers typically include little more than a >> log file they got from the mgmt client at time the problem happened. >> The problem experianced may no longer exist, so asking them to run >> a tracepoint script is not possible. They may also be reluctant to >> actually run tracepoint scripts on a production system, or simply >> lack the ability todo so at all, due to constraints of the deployment >> environment. Logs from libvirt are something that are collected by >> default for many mgmt apps, or can be turned on by the user with >> minimal risk of disruption. >> >> Overall, there's a compelling desire to be proactive in collecting >> information ahead of time, that might be useful in diagnosing >> future bug reports. > > This is the main reason. When you encounter a problem one of the first > questions is "Was there something similar in the past. Another question > is how often does it happen. > > With the timestamps these questions answering becomes easier. > > Another thing is that with the qmp command timestamps you can build a > monitoring system which will report about the cases when > execution_time_from_mgmt_perspective - excution_time_qmp_command > > some_threshold which in turn proactively tell you about the potential > problems. And then you'll start using the qmp tracepoints (and other > means) to figure out the real reason of the execution time variance. > > Thanks, Denis > >> >> So it isn't an 'either / or' decision of QMP reply logs vs use of >> tracepoints, both are
Re: [v2] hw: misc: edu: fix 2 off-by-one errors
Peter Maydell writes: > On Mon, 17 Oct 2022 at 14:50, Alexander Bulekov wrote: >> >> On 221015 1710, Chris Friedt wrote: >> > From: Christopher Friedt >> > >> > In the case that size1 was zero, because of the explicit >> > 'end1 > addr' check, the range check would fail and the error >> > message would read as shown below. The correct comparison >> > is 'end1 >= addr' (or 'addr <= end1'). >> > >> > EDU: DMA range 0x4-0x3 out of bounds (0x4-0x40fff)! >> > >> > At the opposite end, in the case that size1 was 4096, within() >> > would fail because of the non-inclusive check 'end1 < end2', >> > which should have been 'end1 <= end2'. The error message would >> > previously say >> > >> > EDU: DMA range 0x4-0x40fff out of bounds (0x4-0x40fff)! >> > >> > This change >> > 1. renames local variables to be more less ambiguous >> > 2. fixes the two off-by-one errors described above. >> > >> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1254 >> > >> > Signed-off-by: Christopher Friedt >> >> Reviewed-by: Alexander Bulekov >> >> As a side-note, seems strange that edu_check_range will abort the entire >> VM if the check fails, rather than handling the error more elegantly. > > Yes, this is bad for a device model, though we have a lot of > older device models that still do it. The preferred pattern is: > * for situations which are "if this happens there is a >bug in QEMU itself", use assert. hw_error() is a kind of >assert that prints a bunch of guest register state: sometimes >you want that, but more often you just want normal assert() > * for situations where the guest has misprogrammed the device, >log that with qemu_log_mask(LOG_GUEST_ERROR, ...) >and continue with whatever the real hardware would do, or >some reasonable choice if the h/w spec is vague > * for situations where the guest is correct but is trying to >get the device to do something our model doesn't implement >yet, same as above but with LOG_UNIMP. > > Probably most hw_error() uses in the codebase should be > replaced with one of the above options. We should probably document this best practice somewhere in docs/devel but I guess we really need a "guide to writing device emulation" section. > > thanks > -- PMM -- Alex Bennée
Re: [PATCH v6 02/10] dump: Write ELF section headers right after ELF header
Janosch Frank writes: > On 10/17/22 14:49, Marc Hartmayer wrote: >> Janosch Frank writes: >> >>> Let's start bundling the writes of the headers and of the data so we >>> have a clear ordering between them. Since the ELF header uses offsets >>> to the headers we can freely order them. >>> >>> Signed-off-by: Janosch Frank >>> --- >>> dump/dump.c | 31 ++- >>> 1 file changed, 14 insertions(+), 17 deletions(-) >>> >>> diff --git a/dump/dump.c b/dump/dump.c >>> index e7a3b54ebe..b168a25321 100644 >>> --- a/dump/dump.c >>> +++ b/dump/dump.c >>> @@ -583,6 +583,8 @@ static void dump_begin(DumpState *s, Error **errp) >>>* -- >>>* | elf header | >>>* -- >>> + * | sctn_hdr | >>> + * -- >> >> While you’re at it, I would suggest to add the location for the program >> headers (phdr) as well. This would it make easier to understand the >> memory layout & the code below as well. >> >> I guess it looks like: >> >> … >> --- >> | sctn_hdr | >> --- >> | prog_hdr | >> --- >> … >> >> >> […snip] >> > > > They are already in there, have a look at the PT_* entries. I've left > them like this because I assumed that the original author wanted to make > a point by having them like this. Makes sense - I mistakenly assumed that these were the actual segment contents. […snip]
[RFC PATCH v2] hw/cxl: Initial emulated CXL poison injection support
Inject poison using qmp command cxl-inject-poison to
add an entry to the poison list.
For now, the poison is not returned CXL.mem reads, but only via
the mailbox command Get Poison List.
See CXL rev 3.0, sec 8.2.9.8.4.1 Get Poison list (Opcode 4300h)
Kernel patches to use this interface here:
https://lore.kernel.org/linux-cxl/cover.1665606782.git.alison.schofi...@intel.com/
RFC for now as likely the implementation will change as
support for mailbox based poison injection and media scanning are added.
To inject poison using qmp (telnet to the qmp port)
{ "execute": "qmp_capabilities" }
{ "execute": "cxl-inject-poison",
"arguments": {
"path": "/machine/peripheral/cxl-pmem0",
"start": 2048,
"length": 256
}
}
Adjusted to select a device on your machine.
Signed-off-by: Jonathan Cameron
---
v2:
Moved to QMP to allow for single command.
Update reference in coverletter
Part of purpose for sending this out at this point is to illustrate how
simple it would be to added per event injection support to Ira's patch
set on CXL event injection.
Slightly odd base for now as the tree is a state of flux.
Replace the existing poison injection patch on tree
at gitlab.com/jic23/qemu/ cxl-2022-10-14
I'll post a new version of that tree shortly with today's date.
---
hw/cxl/cxl-mailbox-utils.c | 85 +
hw/mem/cxl_type3.c | 34 +++
hw/mem/cxl_type3_stubs.c| 6 +++
hw/mem/meson.build | 2 +
include/hw/cxl/cxl_device.h | 13 ++
qapi/cxl.json | 17
qapi/meson.build| 1 +
qapi/qapi-schema.json | 1 +
8 files changed, 159 insertions(+)
diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
index bc1bb18844..c7e1a88b44 100644
--- a/hw/cxl/cxl-mailbox-utils.c
+++ b/hw/cxl/cxl-mailbox-utils.c
@@ -59,6 +59,8 @@ enum {
#define GET_PARTITION_INFO 0x0
#define GET_LSA 0x2
#define SET_LSA 0x3
+MEDIA_AND_POISON = 0x43,
+#define GET_POISON_LIST0x0
};
/* 8.2.8.4.5.1 Command Return Codes */
@@ -296,6 +298,7 @@ static ret_code cmd_identify_memory_device(struct cxl_cmd
*cmd,
id->total_capacity = size / (256 << 20);
id->persistent_capacity = size / (256 << 20);
id->lsa_size = cvc->get_lsa_size(ct3d);
+id->poison_list_max_mer[1] = 0x1; /* 256 poison records */
*len = sizeof(*id);
return CXL_MBOX_SUCCESS;
@@ -382,6 +385,86 @@ static ret_code cmd_ccls_set_lsa(struct cxl_cmd *cmd,
return CXL_MBOX_SUCCESS;
}
+/*
+ * This is very inefficient, but good enough for now!
+ * Also thed payload will always fit, so no need to handle the MORE flag and
+ * make this stateful.
+ */
+static ret_code cmd_media_get_poison_list(struct cxl_cmd *cmd,
+ CXLDeviceState *cxl_dstate,
+ uint16_t *len)
+{
+struct get_poison_list_pl {
+uint64_t pa;
+uint64_t length;
+} QEMU_PACKED;
+
+struct get_poison_list_out_pl {
+uint8_t flags;
+uint8_t rsvd1;
+uint64_t overflow_timestamp;
+uint16_t count;
+uint8_t rsvd2[0x14];
+struct {
+uint64_t addr;
+uint32_t length;
+uint32_t resv;
+} QEMU_PACKED records[];
+} QEMU_PACKED;
+
+struct get_poison_list_pl *in = (void *)cmd->payload;
+struct get_poison_list_out_pl *out = (void *)cmd->payload;
+CXLType3Dev *ct3d = container_of(cxl_dstate, CXLType3Dev, cxl_dstate);
+CXLType3Class *cvc = CXL_TYPE3_GET_CLASS(ct3d);
+uint16_t record_count = 0, i = 0;
+uint64_t query_start = in->pa;
+uint64_t query_length = in->length;
+CXLPoisonList *poison_list;
+CXLPoison *ent;
+uint16_t out_pl_len;
+
+poison_list = cvc->get_poison_list(ct3d);
+
+QLIST_FOREACH(ent, poison_list, node) {
+/* Check for no overlap */
+if (ent->start >= query_start + query_length ||
+ent->start + ent->length <= query_start) {
+continue;
+}
+if (record_count == 256) {
+/* For now just return 256 max */
+break;
+}
+record_count++;
+}
+out_pl_len = sizeof(*out) + record_count * sizeof(out->records[0]);
+assert(out_pl_len <= CXL_MAILBOX_MAX_PAYLOAD_SIZE);
+
+memset(out, 0, out_pl_len);
+QLIST_FOREACH(ent, poison_list, node) {
+uint64_t start, stop;
+
+/* Check for no overlap */
+if (ent->start >= query_start + query_length ||
+ent->start + ent->length <= query_start) {
+continue;
+}
+if (i == 256) {
+break;
+}
+/* Deal with overlap */
+start = MAX(ent->start & 0xffc0, query_start);
+stop = MIN((ent->start & 0xffc0) + ent->length,
+ query_start + query_length);
+out->records[i].addr
Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
On 10/17/2022 6:19 PM, Kirill A . Shutemov wrote:
On Mon, Oct 17, 2022 at 03:00:21PM +0200, Vlastimil Babka wrote:
On 9/15/22 16:29, Chao Peng wrote:
From: "Kirill A. Shutemov"
KVM can use memfd-provided memory for guest memory. For normal userspace
accessible memory, KVM userspace (e.g. QEMU) mmaps the memfd into its
virtual address space and then tells KVM to use the virtual address to
setup the mapping in the secondary page table (e.g. EPT).
With confidential computing technologies like Intel TDX, the
memfd-provided memory may be encrypted with special key for special
software domain (e.g. KVM guest) and is not expected to be directly
accessed by userspace. Precisely, userspace access to such encrypted
memory may lead to host crash so it should be prevented.
This patch introduces userspace inaccessible memfd (created with
MFD_INACCESSIBLE). Its memory is inaccessible from userspace through
ordinary MMU access (e.g. read/write/mmap) but can be accessed via
in-kernel interface so KVM can directly interact with core-mm without
the need to map the memory into KVM userspace.
It provides semantics required for KVM guest private(encrypted) memory
support that a file descriptor with this flag set is going to be used as
the source of guest memory in confidential computing environments such
as Intel TDX/AMD SEV.
KVM userspace is still in charge of the lifecycle of the memfd. It
should pass the opened fd to KVM. KVM uses the kernel APIs newly added
in this patch to obtain the physical memory address and then populate
the secondary page table entries.
The userspace inaccessible memfd can be fallocate-ed and hole-punched
from userspace. When hole-punching happens, KVM can get notified through
inaccessible_notifier it then gets chance to remove any mapped entries
of the range in the secondary page tables.
The userspace inaccessible memfd itself is implemented as a shim layer
on top of real memory file systems like tmpfs/hugetlbfs but this patch
only implemented tmpfs. The allocated memory is currently marked as
unmovable and unevictable, this is required for current confidential
usage. But in future this might be changed.
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Chao Peng
---
...
+static long inaccessible_fallocate(struct file *file, int mode,
+ loff_t offset, loff_t len)
+{
+ struct inaccessible_data *data = file->f_mapping->private_data;
+ struct file *memfd = data->memfd;
+ int ret;
+
+ if (mode & FALLOC_FL_PUNCH_HOLE) {
+ if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
+ return -EINVAL;
+ }
+
+ ret = memfd->f_op->fallocate(memfd, mode, offset, len);
+ inaccessible_notifier_invalidate(data, offset, offset + len);
Wonder if invalidate should precede the actual hole punch, otherwise we open
a window where the page tables point to memory no longer valid?
Yes, you are right. Thanks for catching this.
I also noticed this. But then thought the memory would be anyways zeroed
(hole punched) before this call?
+ return ret;
+}
+
...
+
+static struct file_system_type inaccessible_fs = {
+ .owner = THIS_MODULE,
+ .name = "[inaccessible]",
Dunno where exactly is this name visible, but shouldn't it better be
"[memfd:inaccessible]"?
Maybe. And skip brackets.
+ .init_fs_context = inaccessible_init_fs_context,
+ .kill_sb= kill_anon_super,
+};
+
Re: [PATCH v5 00/18] tests/qtest: Enable running qtest on Windows
On Monday, October 17, 2022 5:00:56 PM CEST Bin Meng wrote: > Hi Alex, > > On Fri, Oct 7, 2022 at 1:31 PM Bin Meng wrote: > > On Fri, Oct 7, 2022 at 4:35 AM Alex Bennée wrote: > > > Bin Meng writes: > > > > In preparation to adding virtio-9p support on Windows, this series > > > > enables running qtest on Windows, so that we can run the virtio-9p > > > > tests on Windows to make sure it does not break accidently. > > > > > > I'm happy to take this whole series through my testing/next however I > > > don't have working CI for the month so need to wait for my minutes to > > > reset. Have you done a full CI run* with this? > > > > Yes, gitlab CI passed. > > > > > (*make sure any CI run is only on a repo forked from > > > https://gitlab.com/qemu-project as you won't get the discount cost > > > factor otherwise) > > Patch 4 and 10 are already applied in the mainline by Thomas. > > Daniel will queue patch 14, 15, 16. > > Could you please help queue patch 1, 2, 3, 5, 6, 7, 9, 13 from this series? I already had patch 6 queued on my end: https://github.com/cschoenebeck/qemu/commits/9p.next Next 9p PR end of this week. But if somebody else is faster then I'll just drop it later on. Best regards, Christian Schoenebeck
Re: [v2] hw: misc: edu: fix 2 off-by-one errors
On Mon, Oct 17, 2022 at 2:23 AM Jiri Slaby wrote: > On 15. 10. 22, 23:10, Chris Friedt wrote: > > From: Christopher Friedt > This should be split into two patches. This way, it's hard to review. I can do that :-) Thanks for the review
Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
On Mon, Oct 17, 2022 at 03:00:21PM +0200, Vlastimil Babka wrote:
> On 9/15/22 16:29, Chao Peng wrote:
> > From: "Kirill A. Shutemov"
> >
> > KVM can use memfd-provided memory for guest memory. For normal userspace
> > accessible memory, KVM userspace (e.g. QEMU) mmaps the memfd into its
> > virtual address space and then tells KVM to use the virtual address to
> > setup the mapping in the secondary page table (e.g. EPT).
> >
> > With confidential computing technologies like Intel TDX, the
> > memfd-provided memory may be encrypted with special key for special
> > software domain (e.g. KVM guest) and is not expected to be directly
> > accessed by userspace. Precisely, userspace access to such encrypted
> > memory may lead to host crash so it should be prevented.
> >
> > This patch introduces userspace inaccessible memfd (created with
> > MFD_INACCESSIBLE). Its memory is inaccessible from userspace through
> > ordinary MMU access (e.g. read/write/mmap) but can be accessed via
> > in-kernel interface so KVM can directly interact with core-mm without
> > the need to map the memory into KVM userspace.
> >
> > It provides semantics required for KVM guest private(encrypted) memory
> > support that a file descriptor with this flag set is going to be used as
> > the source of guest memory in confidential computing environments such
> > as Intel TDX/AMD SEV.
> >
> > KVM userspace is still in charge of the lifecycle of the memfd. It
> > should pass the opened fd to KVM. KVM uses the kernel APIs newly added
> > in this patch to obtain the physical memory address and then populate
> > the secondary page table entries.
> >
> > The userspace inaccessible memfd can be fallocate-ed and hole-punched
> > from userspace. When hole-punching happens, KVM can get notified through
> > inaccessible_notifier it then gets chance to remove any mapped entries
> > of the range in the secondary page tables.
> >
> > The userspace inaccessible memfd itself is implemented as a shim layer
> > on top of real memory file systems like tmpfs/hugetlbfs but this patch
> > only implemented tmpfs. The allocated memory is currently marked as
> > unmovable and unevictable, this is required for current confidential
> > usage. But in future this might be changed.
> >
> > Signed-off-by: Kirill A. Shutemov
> > Signed-off-by: Chao Peng
> > ---
>
> ...
>
> > +static long inaccessible_fallocate(struct file *file, int mode,
> > + loff_t offset, loff_t len)
> > +{
> > + struct inaccessible_data *data = file->f_mapping->private_data;
> > + struct file *memfd = data->memfd;
> > + int ret;
> > +
> > + if (mode & FALLOC_FL_PUNCH_HOLE) {
> > + if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
> > + return -EINVAL;
> > + }
> > +
> > + ret = memfd->f_op->fallocate(memfd, mode, offset, len);
> > + inaccessible_notifier_invalidate(data, offset, offset + len);
>
> Wonder if invalidate should precede the actual hole punch, otherwise we open
> a window where the page tables point to memory no longer valid?
Yes, you are right. Thanks for catching this.
> > + return ret;
> > +}
> > +
>
> ...
>
> > +
> > +static struct file_system_type inaccessible_fs = {
> > + .owner = THIS_MODULE,
> > + .name = "[inaccessible]",
>
> Dunno where exactly is this name visible, but shouldn't it better be
> "[memfd:inaccessible]"?
Maybe. And skip brackets.
>
> > + .init_fs_context = inaccessible_init_fs_context,
> > + .kill_sb= kill_anon_super,
> > +};
> > +
>
--
Kiryl Shutsemau / Kirill A. Shutemov
Re: [RFC PATCH 3/6] hw/cxl/cxl-events: Add CXL mock events
On Thu, 13 Oct 2022 17:21:56 -0700
Ira Weiny wrote:
> On Tue, Oct 11, 2022 at 11:07:59AM +0100, Jonathan Cameron wrote:
> > On Mon, 10 Oct 2022 15:29:41 -0700
> > ira.we...@intel.com wrote:
> >
> > > From: Ira Weiny
> > >
> > > To facilitate testing of guest software add mock events and code to
> > > support iterating through the event logs.
> > >
> > > Signed-off-by: Ira Weiny
> >
> > Various comments inline, but biggest one is I'd like to see
> > a much more flexible injection interface. Happy to help code one
> > up if that is useful.
>
> Quick response to this.
>
> I thought about holding off and doing something like that but this got the irq
> testing in the kernel off the ground.
>
> I think it would be cool to use QMP to submit events as json. That would be
> much more flexible. But would have taken a lot more time.
The qapi code gen infrastructure makes this fairly simple (subject to fighting
with meson - with hindsight the same fight I had with it for other stubs...)
I've moved the poison injection patches over to this and will hopefully send
a RFC v2 of those out tomorrow.
For reference injection of poison now looks like
{ "execute": "cxl-inject-poison",
"arguments": {
"path": "/machine/peripheral/cxl-pmem0",
"start": 2048,
"length": 256
}
}
defined via a new cxl.json that other than comments just contains
{ 'command': 'cxl-inject-poison',
'data' : { 'path': 'str, 'start': 'uint64', 'length': uint64 }}
from that all the json parsing infrastructure is generated and you just
need to provide an implementation of
void qmp_cxl_inject_poison(const char *path, uint64_t start, uint64_t length,
Error *errp)
Something similar for these events will be very straight forward.
Jonathan
>
> What I did below duplicated the test code cxl-test has. It was pretty quick
> to
> do that.
>
> The biggest issue with is parsing the various events from the json to binary
> blobs.
>
> I'll clean up this patch and see what I can do. But I think having a set of
> statically defined blobs which can be injected would make testing a bit
> easier.
> Less framework to format json input to QMP.
>
> More to come...
>
> Ira
>
> >
> > Jonathan
> >
> >
> > > ---
> > > hw/cxl/cxl-events.c | 248
> > > hw/cxl/meson.build | 1 +
> > > include/hw/cxl/cxl_device.h | 19 +++
> > > include/hw/cxl/cxl_events.h | 173 +
> > > 4 files changed, 441 insertions(+)
> > > create mode 100644 hw/cxl/cxl-events.c
> > > create mode 100644 include/hw/cxl/cxl_events.h
> > >
> > > diff --git a/hw/cxl/cxl-events.c b/hw/cxl/cxl-events.c
> > > new file mode 100644
> > > index ..c275280bcb64
> > > --- /dev/null
> > > +++ b/hw/cxl/cxl-events.c
> > > @@ -0,0 +1,248 @@
> > > +/*
> > > + * CXL Event processing
> > > + *
> > > + * Copyright(C) 2022 Intel Corporation.
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version 2. See
> > > the
> > > + * COPYING file in the top-level directory.
> > > + */
> > > +
> > > +#include
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "qemu/bswap.h"
> > > +#include "qemu/typedefs.h"
> > > +#include "hw/cxl/cxl.h"
> > > +#include "hw/cxl/cxl_events.h"
> > > +
> > > +struct cxl_event_log *find_event_log(CXLDeviceState *cxlds, int log_type)
> > > +{
> > > +if (log_type >= CXL_EVENT_TYPE_MAX) {
> > > +return NULL;
> > > +}
> > > +return >event_logs[log_type];
> > > +}
> > > +
> > > +struct cxl_event_record_raw *get_cur_event(struct cxl_event_log *log)
> > > +{
> > > +return log->events[log->cur_event];
> > > +}
> > > +
> > > +uint16_t get_cur_event_handle(struct cxl_event_log *log)
> > > +{
> > > +return cpu_to_le16(log->cur_event);
> > > +}
> > > +
> > > +bool log_empty(struct cxl_event_log *log)
> > > +{
> > > +return log->cur_event == log->nr_events;
> > > +}
> > > +
> > > +int log_rec_left(struct cxl_event_log *log)
> > > +{
> > > +return log->nr_events - log->cur_event;
> > > +}
> > > +
> > > +static void event_store_add_event(CXLDeviceState *cxlds,
> > > + enum cxl_event_log_type log_type,
> > > + struct cxl_event_record_raw *event)
> > > +{
> > > +struct cxl_event_log *log;
> > > +
> > > +assert(log_type < CXL_EVENT_TYPE_MAX);
> > > +
> > > +log = >event_logs[log_type];
> > > +assert(log->nr_events < CXL_TEST_EVENT_CNT_MAX);
> > > +
> > > +log->events[log->nr_events] = event;
> > > +log->nr_events++;
> > > +}
> > > +
> > > +uint16_t log_overflow(struct cxl_event_log *log)
> > > +{
> > > +int cnt = log_rec_left(log) - 5;
> >
> > Why -5? Can't we make it actually overflow and drop records
> > if that happens?
> >
> > > +
> > > +if (cnt < 0) {
> > > +return 0;
> > > +}
> > > +return cnt;
> > > +}
> > > +
> > > +#define
Re: Question about TCG backend correctness
On 2022/10/17 18:30, Alex Bennée wrote: LIU Zhiwei writes: Hi folks, For TCG front end, we can test it with tools, such as RISU. But I don't know if there are some tools that can help to verify the correctness of a TCG backend. Can someone share the tools or the experience to debug RISC-V backend? Thanks very much. It's mostly down to inspection or debugging failures. Agree. Sometimes you can attempt to shake out bugs by running a stacked QEMU. e.g. qemu-system-aarch64 on x86 host qemu-system-aarch64 on qemu-system-riscv64 on x86 host and see if the two aarch64 guests run the same. We currently depend on the guest behaviors to test the correctness of TCG backend. And if the guest doesn't behave correctly, it is hard to find the exact bug in backend. Maybe I can run RISU on qemu-aarch64(x86) and qemu-aarch64(risc-v) to check the RISC-V backend. This of course gets very tricky running full OS kernels because as soon as time and async interrupts get involved you will get divergence anyway. This would work best with simple straight line test cases (e.g. check-tcg test cases). I've long wanted to have the ability to have TCG unit tests where a virtual processor could be defined for the purpose of directly exercising TCG. We already have many ISAs as the front end of TCG. Will the virtual processor here be some different? This would be mainly to check tcg_optimize() works correctly but no doubt could be extended to verify the eventual backend output. The problem with implementing such an approach has been the amount of boilerplate needed to define a simple frontend. Sorry, I don't get it. Maybe this will get simpler as we slowly move to a single binary build but there is still quite of lot of things TCG needs to know about the guest it is emulating. If you would like to attempt improve the testing situation for TCG and its backend I'm fully supportive. If I can find a good way, I really like to do some further work. Thanks， Zhiwei
Re: [PATCH 0/4] Allow to pass pre-created VFIO container/group to QEMU
On Mon, 17 Oct 2022 13:54:03 +0300
Andrey Ryabinin wrote:
> These patches add possibility to pass VFIO device to QEMU using file
> descriptors of VFIO container/group, instead of creating those by QEMU.
> This allows to take away permissions to open /dev/vfio/* from QEMU and
> delegate that to managment layer like libvirt.
>
> The VFIO API doen't allow to pass just fd of device, since we also need to
> have
> VFIO container and group. So these patches allow to pass created VFIO
> container/group
> to QEMU via command line/QMP, e.g. like this:
> -object vfio-container,id=ct,fd=5 \
> -object vfio-group,id=grp,fd=6,container=ct \
> -device vfio-pci,host=05:00.0,group=grp
This suggests that management tools need to become intimately familiar
with container and group association restrictions for implicit
dependencies, such as device AddressSpace. We had considered this
before and intentionally chosen to allow QEMU to manage that
relationship. Things like PCI bus type and presence of a vIOMMU factor
into these relationships.
In the above example, what happens in a mixed environment, for example
if we then add '-device vfio-pci,host=06:00.0' to the command line?
Isn't QEMU still going to try to re-use the container if it exists in
the same address space? Potentially this device could also be a member
of the same group. How would the management tool know when to expect
the provided fds be released?
We also have an outstanding RFC for iommufd that already proposes an fd
passing interface, where iommufd removes many of the issues of the vfio
container by supporting multiple address spaces within a single fd
context, avoiding the duplicate locked page accounting issues between
containers, and proposing a direct device fd interface for vfio. Why at
this point in time would we choose to expand the QEMU vfio interface in
this way? Thanks,
Alex
> A bit more detailed example can be found in the test:
> tests/avocado/vfio.py
>
> *Possible future steps*
>
> Also these patches could be a step for making local migration (within one
> host)
> of the QEMU with VFIO devices.
> I've built some prototype on top of these patches to try such idea.
> In short the scheme of such migration is following:
> - migrate source VM to file.
> - retrieve fd numbers of VFIO container/group/device via new property and
> qom-get command
> - get the actual file descriptor via SCM_RIGHTS using new qmp command
> 'returnfd' which
>sends fd from QEMU by the number: { 'command': 'returnfd', 'data': {'fd':
> 'int'}}
> - shutdown source VM
> - launch destination VM, plug VFIO devices using obtained file descriptors.
> - PCI device reset duriing plugging the device avoided with the help of new
> parameter
> on vfio-pci device.
> This is alternative to 'cpr-exec' migration scheme proposed here:
>
> https://lore.kernel.org/qemu-devel/1658851843-236870-1-git-send-email-steven.sist...@oracle.com/
> Unlike cpr-exec it doesn't require new kernel flags
> VFIO_DMA_UNMAP_FLAG_VADDR/VFIO_DMA_MAP_FLAG_VADDR
> And doesn't require new migration mode, just some additional steps from
> management layer.
>
>
> Andrey Ryabinin (4):
> vfio: add vfio-container user createable object
> vfio: add vfio-group user createable object
> vfio: Add 'group' property to 'vfio-pci' device
> tests/avocado/vfio: add test for vfio devices
>
> hw/vfio/ap.c | 2 +-
> hw/vfio/ccw.c | 2 +-
> hw/vfio/common.c | 471 +++---
> hw/vfio/pci.c | 10 +-
> hw/vfio/platform.c| 2 +-
> hw/vfio/trace-events | 4 +-
> include/hw/vfio/vfio-common.h | 10 +-
> qapi/qom.json | 29 +++
> tests/avocado/vfio.py | 156 +++
> 9 files changed, 525 insertions(+), 161 deletions(-)
> create mode 100644 tests/avocado/vfio.py
>
Re: [PATCH V3 4/4] intel-iommu: PASID support
On Mon, Oct 17, 2022 at 03:52:46PM +0800, Jason Wang wrote:
[...]
> > > +struct vtd_iotlb_key {
> > > +uint16_t sid;
> > > +uint32_t pasid;
> > > +uint64_t gfn;
> > > +uint32_t level;
> > > };
> >
> > Nit: maybe re-arrange it a bit?
> >
> >struct vtd_iotlb_key {
> >uint64_t gfn;
> >uint32_t pasid;
> >uint32_t level;
> >uint16_t sid;
> >} __attribute__((__packed__));
> >
> > "packed" should save us 6 bytes for each in this case, maybe also
> > worthwhile but not strongly as we have a limit of 1k objs.
>
> I think it should be fine to rearrange but for 'packed', would this
> cause alignment issues that may cause troubles on some arches?
Do you mean the gfn reading can be split into 2 * 4 bytes? Would that
still work as long as we're protected with a lock when accessing iotlb
(even though it may be slower than aligned access)?
But at least I think you're right it's not always a benefit, so no strong
opinion here to have it packed.
>
> >
> > The name "gfn" seems a bit unfortunate - would "iova" be more suitable? I
> > do see we used it elsewhere too, so we can also leave that for later.
>
> Right, it has been used for VTDIOTLBEntry before this patch. If
> possible I would leave it to be done on top with a separate patch.
Definitely.
Thanks,
--
Peter Xu
Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
On Mon, Oct 17, 2022 at 11:31:19AM +0100, Fuad Tabba wrote: > Hi, > > > > > > > Actually, for pKVM, there is no need for the guest memory to be > > > GUP'able at all if we use the new inaccessible_get_pfn(). > > > > If pKVM can use inaccessible_get_pfn() to get pfn and can avoid GUP (I > > think that is the major concern?), do you see any other gap from > > existing API? > > Actually for this part no, there aren't any gaps and > inaccessible_get_pfn() is sufficient. Thanks for the confirmation. > > > > This of > > > course goes back to what I'd mentioned before in v7; it seems that > > > representing the memslot memory as a file descriptor should be > > > orthogonal to whether the memory is shared or private, rather than a > > > private_fd for private memory and the userspace_addr for shared > > > memory. The host can then map or unmap the shared/private memory using > > > the fd, which allows it more freedom in even choosing to unmap shared > > > memory when not needed, for example. > > > > Using both private_fd and userspace_addr is only needed in TDX and other > > confidential computing scenarios, pKVM may only use private_fd if the fd > > can also be mmaped as a whole to userspace as Sean suggested. > > That does work in practice, for now at least, and is what I do in my > current port. However, the naming and how the API is defined as > implied by the name and the documentation. By calling the field > private_fd, it does imply that it should not be mapped, which is also > what api.rst says in PATCH v8 5/8. My worry is that in that case pKVM > would be mis/ab-using this interface, and that future changes could > cause unforeseen issues for pKVM. That is fairly enough. We can change the naming and the documents. > > Maybe renaming this to something like "guest_fp", and specifying in > the documentation that it can be restricted, e.g., instead of "the > content of the private memory is invisible to userspace" something > along the lines of "the content of the guest memory may be restricted > to userspace". Some other candidates in my mind: - restricted_fd: to pair with the mm side restricted_memfd - protected_fd: as Sean suggested before - fd: how it's explained relies on the memslot.flag. Thanks, Chao > > What do you think? > > Cheers, > /fuad > > > > > Thanks, > > Chao > > > > > > Cheers, > > > /fuad
Re: [PATCH v5 00/18] tests/qtest: Enable running qtest on Windows
Hi Alex, On Fri, Oct 7, 2022 at 1:31 PM Bin Meng wrote: > > On Fri, Oct 7, 2022 at 4:35 AM Alex Bennée wrote: > > > > > > Bin Meng writes: > > > > > In preparation to adding virtio-9p support on Windows, this series > > > enables running qtest on Windows, so that we can run the virtio-9p > > > tests on Windows to make sure it does not break accidently. > > > > I'm happy to take this whole series through my testing/next however I > > don't have working CI for the month so need to wait for my minutes to > > reset. Have you done a full CI run* with this? > > > > Yes, gitlab CI passed. > > > (*make sure any CI run is only on a repo forked from > > https://gitlab.com/qemu-project as you won't get the discount cost > > factor otherwise) > > Patch 4 and 10 are already applied in the mainline by Thomas. Daniel will queue patch 14, 15, 16. Could you please help queue patch 1, 2, 3, 5, 6, 7, 9, 13 from this series? I will rework the rest of the patches. Regards, Bin
Re: [PATCH v8 7/8] KVM: Handle page fault for private memory
On Fri, Oct 14, 2022 at 06:57:20PM +, Sean Christopherson wrote:
> On Thu, Sep 15, 2022, Chao Peng wrote:
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index a0f198cede3d..81ab20003824 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -3028,6 +3028,9 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm,
> > break;
> > }
> >
> > + if (kvm_mem_is_private(kvm, gfn))
>
> Rather than reload the Xarray info, which is unnecessary overhead, pass in
> @is_private. The caller must hold mmu_lock, i.e. invalidations from
> private<->shared conversions will be stalled and will zap the new SPTE if the
> state is changed.
Make sense. TDX/SEV should be easy to query that.
Chao
>
> E.g.
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index d68944f07b4b..44eea47697d8 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3072,8 +3072,8 @@ void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu,
> struct kvm_page_fault *fault
> * Enforce the iTLB multihit workaround after capturing the requested
> * level, which will be used to do precise, accurate accounting.
> */
> - fault->req_level = kvm_mmu_max_mapping_level(vcpu->kvm, slot,
> -fault->gfn,
> fault->max_level);
> + fault->req_level = kvm_mmu_max_mapping_level(vcpu->kvm, slot,
> fault->gfn,
> +fault->max_level,
> fault->is_private);
> if (fault->req_level == PG_LEVEL_4K || fault->huge_page_disallowed)
> return;
>
> @@ -6460,7 +6460,7 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm
> *kvm,
> */
> if (sp->role.direct &&
> sp->role.level < kvm_mmu_max_mapping_level(kvm, slot,
> sp->gfn,
> - PG_LEVEL_NUM))
> {
> + PG_LEVEL_NUM,
> false)) {
> kvm_zap_one_rmap_spte(kvm, rmap_head, sptep);
>
> if (kvm_available_flush_tlb_with_range())
> diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
> index 7670c13ce251..9acdf72537ce 100644
> --- a/arch/x86/kvm/mmu/spte.h
> +++ b/arch/x86/kvm/mmu/spte.h
> @@ -315,6 +315,12 @@ static inline bool is_dirty_spte(u64 spte)
> return dirty_mask ? spte & dirty_mask : spte & PT_WRITABLE_MASK;
> }
>
> +static inline bool is_private_spte(u64 spte)
> +{
> + /* FIXME: Query C-bit/S-bit for SEV/TDX. */
> + return false;
> +}
> +
> static inline u64 get_rsvd_bits(struct rsvd_bits_validate *rsvd_check, u64
> pte,
> int level)
> {
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index 672f0432d777..69ba00157e90 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -1767,8 +1767,9 @@ static void zap_collapsible_spte_range(struct kvm *kvm,
> if (iter.gfn < start || iter.gfn >= end)
> continue;
>
> - max_mapping_level = kvm_mmu_max_mapping_level(kvm, slot,
> - iter.gfn,
> PG_LEVEL_NUM);
> + max_mapping_level = kvm_mmu_max_mapping_level(kvm, slot,
> iter.gfn,
> + PG_LEVEL_NUM,
> +
> is_private_spte(iter.old_spte));
> if (max_mapping_level < iter.level)
> continue;
>
Re: [PATCH v12 3/7] block: add block layer APIs resembling Linux ZonedBlockDevice ioctls
On Sun, Oct 16, 2022 at 10:51:06PM +0800, Sam Li wrote:
> Add a new zoned_host_device BlockDriver. The zoned_host_device option
> accepts only zoned host block devices. By adding zone management
> operations in this new BlockDriver, users can use the new block
> layer APIs including Report Zone and four zone management operations
> (open, close, finish, reset, reset_all).
>
> Qemu-io uses the new APIs to perform zoned storage commands of the device:
> zone_report(zrp), zone_open(zo), zone_close(zc), zone_reset(zrs),
> zone_finish(zf).
>
> For example, to test zone_report, use following command:
> $ ./build/qemu-io --image-opts -n driver=zoned_host_device,
> filename=/dev/nullb0
> -c "zrp offset nr_zones"
>
> Signed-off-by: Sam Li
> Reviewed-by: Hannes Reinecke
> ---
> block/block-backend.c | 148 +
> block/file-posix.c| 335 ++
> block/io.c| 41
> include/block/block-io.h | 7 +
> include/block/block_int-common.h | 24 +++
> include/block/raw-aio.h | 6 +-
> include/sysemu/block-backend-io.h | 18 ++
> meson.build | 4 +
> qapi/block-core.json | 8 +-
> qemu-io-cmds.c| 149 +
> 10 files changed, 737 insertions(+), 3 deletions(-)
>
> diff --git a/block/block-backend.c b/block/block-backend.c
> index aa4adf06ae..1c618e9c68 100644
> --- a/block/block-backend.c
> +++ b/block/block-backend.c
> @@ -1431,6 +1431,15 @@ typedef struct BlkRwCo {
> void *iobuf;
> int ret;
> BdrvRequestFlags flags;
> +union {
> +struct {
> +unsigned int *nr_zones;
> +BlockZoneDescriptor *zones;
> +} zone_report;
> +struct {
> +unsigned long op;
> +} zone_mgmt;
> +};
> } BlkRwCo;
>
> int blk_make_zero(BlockBackend *blk, BdrvRequestFlags flags)
> @@ -1775,6 +1784,145 @@ int coroutine_fn blk_co_flush(BlockBackend *blk)
> return ret;
> }
>
> +static void coroutine_fn blk_aio_zone_report_entry(void *opaque)
> +{
> +BlkAioEmAIOCB *acb = opaque;
> +BlkRwCo *rwco = >rwco;
> +
> +rwco->ret = blk_co_zone_report(rwco->blk, rwco->offset,
> + rwco->zone_report.nr_zones,
> + rwco->zone_report.zones);
> +blk_aio_complete(acb);
> +}
> +
> +BlockAIOCB *blk_aio_zone_report(BlockBackend *blk, int64_t offset,
> +unsigned int *nr_zones,
> +BlockZoneDescriptor *zones,
> +BlockCompletionFunc *cb, void *opaque)
> +{
> +BlkAioEmAIOCB *acb;
> +Coroutine *co;
> +IO_CODE();
> +
> +blk_inc_in_flight(blk);
> +acb = blk_aio_get(_aio_em_aiocb_info, blk, cb, opaque);
> +acb->rwco = (BlkRwCo) {
> +.blk= blk,
> +.offset = offset,
> +.ret= NOT_DONE,
> +.zone_report = {
> +.zones = zones,
> +.nr_zones = nr_zones,
> +},
> +};
> +acb->has_returned = false;
> +
> +co = qemu_coroutine_create(blk_aio_zone_report_entry, acb);
> +bdrv_coroutine_enter(blk_bs(blk), co);
> +
> +acb->has_returned = true;
> +if (acb->rwco.ret != NOT_DONE) {
> +replay_bh_schedule_oneshot_event(blk_get_aio_context(blk),
> + blk_aio_complete_bh, acb);
> +}
> +
> +return >common;
> +}
> +
> +static void coroutine_fn blk_aio_zone_mgmt_entry(void *opaque)
> +{
> +BlkAioEmAIOCB *acb = opaque;
> +BlkRwCo *rwco = >rwco;
> +
> +rwco->ret = blk_co_zone_mgmt(rwco->blk, rwco->zone_mgmt.op,
> + rwco->offset, acb->bytes);
> +blk_aio_complete(acb);
> +}
> +
> +BlockAIOCB *blk_aio_zone_mgmt(BlockBackend *blk, BlockZoneOp op,
> + int64_t offset, int64_t len,
> + BlockCompletionFunc *cb, void *opaque) {
> +BlkAioEmAIOCB *acb;
> +Coroutine *co;
> +IO_CODE();
> +
> +blk_inc_in_flight(blk);
> +acb = blk_aio_get(_aio_em_aiocb_info, blk, cb, opaque);
> +acb->rwco = (BlkRwCo) {
> +.blk= blk,
> +.offset = offset,
> +.ret= NOT_DONE,
> +.zone_mgmt = {
> +.op = op,
> +},
> +};
> +acb->bytes = len;
> +acb->has_returned = false;
> +
> +co = qemu_coroutine_create(blk_aio_zone_mgmt_entry, acb);
> +bdrv_coroutine_enter(blk_bs(blk), co);
> +
> +acb->has_returned = true;
> +if (acb->rwco.ret != NOT_DONE) {
> +replay_bh_schedule_oneshot_event(blk_get_aio_context(blk),
> + blk_aio_complete_bh, acb);
> +}
> +
> +return >common;
> +}
> +
> +/*
> + * Send a zone_report command.
> + * offset is a byte offset from the start of the device. No alignment
> + * required for offset.
> + * nr_zones represents IN maximum and OUT
Re: [PATCH 1/2] tests/qtest: migration-test: Fix [-Werror=format-overflow=] build warning
On 17/10/2022 15.56, Bin Meng wrote:
On Mon, Oct 17, 2022 at 8:28 PM Markus Armbruster wrote:
Bin Meng writes:
From: Bin Meng
When tmpfs is NULL, a build warning is seen with GCC 9.3.0.
It's strange that GCC 11.2.0 on Ubuntu 22.04 does not catch this,
neither did the QEMU CI.
Reported-by: Shengjiang Wu
Fixes: e5553c1b8d28 ("tests/qtest: migration-test: Avoid using hardcoded /tmp")
Signed-off-by: Bin Meng
---
tests/qtest/migration-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index ef4427ff4d..83a8998e40 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -2481,7 +2481,7 @@ int main(int argc, char **argv)
tmpfs = g_dir_make_tmp("migration-test-XX", );
if (!tmpfs) {
-g_test_message("g_dir_make_tmp on path (%s): %s", tmpfs,
+g_test_message("g_dir_make_tmp on path (%s): %s", g_get_tmp_dir(),
err->message);
}
g_assert(tmpfs);
Thomas posted the same fix as "[PATCH] tests/qtest/migration-test: Do
not try to print NULL pointer string". You guys figure out which one
you like better :)
Oops, almost the same time :)
Will let Thomas decide.
The improvement of the error message in your v2 makes a lot of sense - I'll
queue that version.
Thomas
Re: [v2] hw: misc: edu: fix 2 off-by-one errors
On Mon, 17 Oct 2022 at 14:50, Alexander Bulekov wrote: > > On 221015 1710, Chris Friedt wrote: > > From: Christopher Friedt > > > > In the case that size1 was zero, because of the explicit > > 'end1 > addr' check, the range check would fail and the error > > message would read as shown below. The correct comparison > > is 'end1 >= addr' (or 'addr <= end1'). > > > > EDU: DMA range 0x4-0x3 out of bounds (0x4-0x40fff)! > > > > At the opposite end, in the case that size1 was 4096, within() > > would fail because of the non-inclusive check 'end1 < end2', > > which should have been 'end1 <= end2'. The error message would > > previously say > > > > EDU: DMA range 0x4-0x40fff out of bounds (0x4-0x40fff)! > > > > This change > > 1. renames local variables to be more less ambiguous > > 2. fixes the two off-by-one errors described above. > > > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1254 > > > > Signed-off-by: Christopher Friedt > > Reviewed-by: Alexander Bulekov > > As a side-note, seems strange that edu_check_range will abort the entire > VM if the check fails, rather than handling the error more elegantly. Yes, this is bad for a device model, though we have a lot of older device models that still do it. The preferred pattern is: * for situations which are "if this happens there is a bug in QEMU itself", use assert. hw_error() is a kind of assert that prints a bunch of guest register state: sometimes you want that, but more often you just want normal assert() * for situations where the guest has misprogrammed the device, log that with qemu_log_mask(LOG_GUEST_ERROR, ...) and continue with whatever the real hardware would do, or some reasonable choice if the h/w spec is vague * for situations where the guest is correct but is trying to get the device to do something our model doesn't implement yet, same as above but with LOG_UNIMP. Probably most hw_error() uses in the codebase should be replaced with one of the above options. thanks -- PMM
Re: [PATCH] hw/hyperv/hyperv.c: Use device_cold_reset() instead of device_legacy_reset()
On 13.10.2022 21:39, Maciej S. Szmigiero wrote: On 13.10.2022 19:18, Peter Maydell wrote: The semantic difference between the deprecated device_legacy_reset() function and the newer device_cold_reset() function is that the new function resets both the device itself and any qbuses it owns, whereas the legacy function resets just the device itself and nothing else. In hyperv_synic_reset() we reset a SynICState, which has no qbuses, so for this purpose the two functions behave identically and we can stop using the deprecated one. Signed-off-by: Peter Maydell --- NB: tested only with 'make check' and 'make check-avocado', which may well not exercise this. In general the patch LGTM, but I will runtime-test it on Monday just to be sure. Tested and works fine on QEMU with SynIC reset fix [1] applied, so: Reviewed-by: Maciej S. Szmigiero Thanks, Maciej [1]: https://lore.kernel.org/qemu-devel/cb57cee2e29b20d06f81dce054cbcea8b5d497e8.1664552976.git.maciej.szmigi...@oracle.com/
