MMaciej S. Szmigieromemory-device: Support empty memory devices
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
memory-device: Support empty memory devices Let's support empty memory devices -- memory devices that don't have a memory device region in the current configuration. hv-balloon with an optional memdev is the primary use case. Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> | 2 年前 | |
hw/mem: Stubbed out NPCM7xx Memory Controller model This just implements the bare minimum to cause the boot block to skip memory initialization. Reviewed-by: Tyrone Ting <kfting@nuvoton.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com> Message-id: 20200911052101.2602693-10-hskinnemoen@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> | 5 年前 | |
nvdimm: Reject writing label data to ROM instead of crashing QEMU Currently, when using a true R/O NVDIMM (ROM memory backend) with a label area, the VM can easily crash QEMU by trying to write to the label area, because the ROM memory is mmap'ed without PROT_WRITE. [root@vm-0 ~]# ndctl disable-region region0 disabled 1 region [root@vm-0 ~]# ndctl zero-labels nmem0 -> QEMU segfaults Let's remember whether we have a ROM memory backend and properly reject the write request: [root@vm-0 ~]# ndctl disable-region region0 disabled 1 region [root@vm-0 ~]# ndctl zero-labels nmem0 zeroed 0 nmem In comparison, on a system with a R/W NVDIMM: [root@vm-0 ~]# ndctl disable-region region0 disabled 1 region [root@vm-0 ~]# ndctl zero-labels nmem0 zeroed 1 nmem For ACPI, just return "unsupported", like if no label exists. For spapr, return "H_P2", similar to when no label area exists. Could we rely on the "unarmed" property? Maybe, but it looks cleaner to only disallow what certainly cannot work. After all "unarmed=on" primarily means: cannot accept persistent writes. In theory, there might be setups where devices with "unarmed=on" set could be used to host non-persistent data (temporary files, system RAM, ...); for example, in Linux, admins can overwrite the "readonly" setting and still write to the device -- which will work as long as we're not using ROM. Allowing writing label data in such configurations can make sense. Message-ID: <20230906120503.359863-2-david@redhat.com> Fixes: dbd730e85987 ("nvdimm: check -object memory-backend-file, readonly=on option") Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> | 2 年前 | |
nvdimm: Add realize, unrealize callbacks to NVDIMMDevice class A new subclass inheriting NVDIMMDevice is going to be introduced in subsequent patches. The new subclass uses the realize and unrealize callbacks. Add them on NVDIMMClass to appropriately call them as part of plug-unplug. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Acked-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <164396253158.109112.1926755104259023743.stgit@ltczzess4.aus.stglabs.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> | 4 年前 | |
memory: add a sparse memory device for fuzzing For testing, it can be useful to simulate an enormous amount of memory (e.g. 2^64 RAM). This adds an MMIO device that acts as sparse memory. When something writes a nonzero value to a sparse-mem address, we allocate a block of memory. For now, since the only user of this device is the fuzzer, we do not track and free zeroed blocks. The device has a very low priority (so it can be mapped beneath actual RAM, and virtual device MMIO regions). Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 5 年前 |