Re: [PATCH 04/10] arm: allwinner-h3: add USB host controller
On 12/2/19 10:09 PM, Niek Linnenbank wrote:
The Allwinner H3 System on Chip contains multiple USB 2.0 bus
connections which provide software access using the Enhanced
Host Controller Interface (EHCI) and Open Host Controller
Interface (OHCI) interfaces. This commit adds support for
both interfaces in the Allwinner H3 System on Chip.
Signed-off-by: Niek Linnenbank
---
hw/arm/allwinner-h3.c| 20
hw/usb/hcd-ehci-sysbus.c | 17 +
hw/usb/hcd-ehci.h| 1 +
Cc'ing Gerd, the maintainer of these files.
Reviewed-by: Philippe Mathieu-Daudé
3 files changed, 38 insertions(+)
diff --git a/hw/arm/allwinner-h3.c b/hw/arm/allwinner-h3.c
index 5566e979ec..afeb49c0ac 100644
--- a/hw/arm/allwinner-h3.c
+++ b/hw/arm/allwinner-h3.c
@@ -26,6 +26,7 @@
#include "hw/sysbus.h"
#include "hw/arm/allwinner-h3.h"
#include "hw/misc/unimp.h"
+#include "hw/usb/hcd-ehci.h"
#include "sysemu/sysemu.h"
static void aw_h3_init(Object *obj)
@@ -183,6 +184,25 @@ static void aw_h3_realize(DeviceState *dev, Error **errp)
}
sysbus_mmio_map(SYS_BUS_DEVICE(&s->ccu), 0, AW_H3_CCU_BASE);
+/* Universal Serial Bus */
+sysbus_create_simple(TYPE_AW_H3_EHCI, AW_H3_EHCI0_BASE,
+ s->irq[AW_H3_GIC_SPI_EHCI0]);
+sysbus_create_simple(TYPE_AW_H3_EHCI, AW_H3_EHCI1_BASE,
+ s->irq[AW_H3_GIC_SPI_EHCI1]);
+sysbus_create_simple(TYPE_AW_H3_EHCI, AW_H3_EHCI2_BASE,
+ s->irq[AW_H3_GIC_SPI_EHCI2]);
+sysbus_create_simple(TYPE_AW_H3_EHCI, AW_H3_EHCI3_BASE,
+ s->irq[AW_H3_GIC_SPI_EHCI3]);
+
+sysbus_create_simple("sysbus-ohci", AW_H3_OHCI0_BASE,
+ s->irq[AW_H3_GIC_SPI_OHCI0]);
+sysbus_create_simple("sysbus-ohci", AW_H3_OHCI1_BASE,
+ s->irq[AW_H3_GIC_SPI_OHCI1]);
+sysbus_create_simple("sysbus-ohci", AW_H3_OHCI2_BASE,
+ s->irq[AW_H3_GIC_SPI_OHCI2]);
+sysbus_create_simple("sysbus-ohci", AW_H3_OHCI3_BASE,
+ s->irq[AW_H3_GIC_SPI_OHCI3]);
+
/* UART */
if (serial_hd(0)) {
serial_mm_init(get_system_memory(), AW_H3_UART0_REG_BASE, 2,
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index 020211fd10..174c3446ef 100644
--- a/hw/usb/hcd-ehci-sysbus.c
+++ b/hw/usb/hcd-ehci-sysbus.c
@@ -145,6 +145,22 @@ static const TypeInfo ehci_exynos4210_type_info = {
.class_init= ehci_exynos4210_class_init,
};
+static void ehci_aw_h3_class_init(ObjectClass *oc, void *data)
+{
+SysBusEHCIClass *sec = SYS_BUS_EHCI_CLASS(oc);
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+sec->capsbase = 0x0;
+sec->opregbase = 0x10;
+set_bit(DEVICE_CATEGORY_USB, dc->categories);
+}
+
+static const TypeInfo ehci_aw_h3_type_info = {
+.name = TYPE_AW_H3_EHCI,
+.parent= TYPE_SYS_BUS_EHCI,
+.class_init= ehci_aw_h3_class_init,
+};
+
static void ehci_tegra2_class_init(ObjectClass *oc, void *data)
{
SysBusEHCIClass *sec = SYS_BUS_EHCI_CLASS(oc);
@@ -267,6 +283,7 @@ static void ehci_sysbus_register_types(void)
type_register_static(&ehci_platform_type_info);
type_register_static(&ehci_xlnx_type_info);
type_register_static(&ehci_exynos4210_type_info);
+type_register_static(&ehci_aw_h3_type_info);
type_register_static(&ehci_tegra2_type_info);
type_register_static(&ehci_ppc4xx_type_info);
type_register_static(&ehci_fusbh200_type_info);
diff --git a/hw/usb/hcd-ehci.h b/hw/usb/hcd-ehci.h
index 0298238f0b..edb59311c4 100644
--- a/hw/usb/hcd-ehci.h
+++ b/hw/usb/hcd-ehci.h
@@ -342,6 +342,7 @@ typedef struct EHCIPCIState {
#define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb"
#define TYPE_PLATFORM_EHCI "platform-ehci-usb"
#define TYPE_EXYNOS4210_EHCI "exynos4210-ehci-usb"
+#define TYPE_AW_H3_EHCI "aw-h3-ehci-usb"
#define TYPE_TEGRA2_EHCI "tegra2-ehci-usb"
#define TYPE_PPC4xx_EHCI "ppc4xx-ehci-usb"
#define TYPE_FUSBH200_EHCI "fusbh200-ehci-usb"
Re: [RFC PATCH 4/9] vfio-pci: register default dynamic-trap-bar-info region
On Tue, Dec 10, 2019 at 05:16:08AM +0800, Alex Williamson wrote: > On Mon, 9 Dec 2019 01:22:12 -0500 > Yan Zhao wrote: > > > On Fri, Dec 06, 2019 at 11:20:38PM +0800, Alex Williamson wrote: > > > On Fri, 6 Dec 2019 01:04:07 -0500 > > > Yan Zhao wrote: > > > > > > > On Fri, Dec 06, 2019 at 07:55:30AM +0800, Alex Williamson wrote: > > > > > On Wed, 4 Dec 2019 22:26:50 -0500 > > > > > Yan Zhao wrote: > > > > > > > > > > > Dynamic trap bar info region is a channel for QEMU and vendor > > > > > > driver to > > > > > > communicate dynamic trap info. It is of type > > > > > > VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and subtype > > > > > > VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO. > > > > > > > > > > > > This region has two fields: dt_fd and trap. > > > > > > When QEMU detects a device regions of this type, it will create an > > > > > > eventfd and write its eventfd id to dt_fd field. > > > > > > When vendor drivre signals this eventfd, QEMU reads trap field of > > > > > > this > > > > > > info region. > > > > > > - If trap is true, QEMU would search the device's PCI BAR > > > > > > regions and disable all the sparse mmaped subregions (if the sparse > > > > > > mmaped subregion is disablable). > > > > > > - If trap is false, QEMU would re-enable those subregions. > > > > > > > > > > > > A typical usage is > > > > > > 1. vendor driver first cuts its bar 0 into several sections, all in > > > > > > a > > > > > > sparse mmap array. So initally, all its bar 0 are passthroughed. > > > > > > 2. vendor driver specifys part of bar 0 sections to be disablable. > > > > > > 3. on migration starts, vendor driver signals dt_fd and set trap to > > > > > > true > > > > > > to notify QEMU disabling the bar 0 sections of disablable flags on. > > > > > > 4. QEMU disables those bar 0 section and hence let vendor driver be > > > > > > able > > > > > > to trap access of bar 0 registers and make dirty page tracking > > > > > > possible. > > > > > > 5. on migration failure, vendor driver signals dt_fd to QEMU again. > > > > > > QEMU reads trap field of this info region which is false and QEMU > > > > > > re-passthrough the whole bar 0 region. > > > > > > > > > > > > Vendor driver specifies whether it supports dynamic-trap-bar-info > > > > > > region > > > > > > through cap VFIO_PCI_DEVICE_CAP_DYNAMIC_TRAP_BAR in > > > > > > vfio_pci_mediate_ops->open(). > > > > > > > > > > > > If vfio-pci detects this cap, it will create a default > > > > > > dynamic_trap_bar_info region on behalf of vendor driver with region > > > > > > len=0 > > > > > > and region->ops=null. > > > > > > Vvendor driver should override this region's len, flags, rw, mmap > > > > > > in its > > > > > > vfio_pci_mediate_ops. > > > > > > > > > > TBH, I don't like this interface at all. Userspace doesn't pass data > > > > > to the kernel via INFO ioctls. We have a SET_IRQS ioctl for > > > > > configuring user signaling with eventfds. I think we only need to > > > > > define an IRQ type that tells the user to re-evaluate the sparse mmap > > > > > information for a region. The user would enumerate the device IRQs > > > > > via > > > > > GET_IRQ_INFO, find one of this type where the IRQ info would also > > > > > indicate which region(s) should be re-evaluated on signaling. The > > > > > user > > > > > would enable that signaling via SET_IRQS and simply re-evaluate the > > > > > > > > > ok. I'll try to switch to this way. Thanks for this suggestion. > > > > > > > > > sparse mmap capability for the associated regions when signaled. > > > > > > > > Do you like the "disablable" flag of sparse mmap ? > > > > I think it's a lightweight way for user to switch mmap state of a whole > > > > region, > > > > otherwise going through a complete flow of GET_REGION_INFO and re-setup > > > > region might be too heavy. > > > > > > No, I don't like the disable-able flag. At what frequency do we expect > > > regions to change? It seems like we'd only change when switching into > > > and out of the _SAVING state, which is rare. It seems easy for > > > userspace, at least QEMU, to drop the entire mmap configuration and > > ok. I'll try this way. > > > > > re-read it. Another concern here is how do we synchronize the event? > > > Are we assuming that this event would occur when a user switch to > > > _SAVING mode on the device? That operation is synchronous, the device > > > must be in saving mode after the write to device state completes, but > > > it seems like this might be trying to add an asynchronous dependency. > > > Will the write to device_state only complete once the user handles the > > > eventfd? How would the kernel know when the mmap re-evaluation is > > > complete. It seems like there are gaps here that the vendor driver > > > could miss traps required for migration because the user hasn't > > > completed the mmap transition yet. Thanks, > > > > > > Alex > > > > yes, this asynchronous event notification will cause
Re: [PATCH 1/2] hw/sd: Configure number of slots exposed by the ASPEED SDHCI model
On 12/10/19 1:52 AM, Andrew Jeffery wrote:
The AST2600 includes a second cut-down version of the SD/MMC controller
found in the AST2500, named the eMMC controller. It's cut down in the
sense that it only supports one slot rather than two, but it brings the
total number of slots supported by the AST2600 to three.
The existing code assumed that the SD controller always provided two
slots. Rework the SDHCI object to expose the number of slots as a
property to be set by the SoC configuration.
Signed-off-by: Andrew Jeffery
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/aspeed.c | 2 +-
hw/arm/aspeed_ast2600.c | 2 ++
hw/arm/aspeed_soc.c | 3 +++
hw/sd/aspeed_sdhci.c | 11 +--
include/hw/sd/aspeed_sdhci.h | 1 +
5 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 028191ff36fc..862549b1f3a9 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -259,7 +259,7 @@ static void aspeed_board_init(MachineState *machine,
cfg->i2c_init(bmc);
}
-for (i = 0; i < ARRAY_SIZE(bmc->soc.sdhci.slots); i++) {
+for (i = 0; i < bmc->soc.sdhci.num_slots; i++) {
SDHCIState *sdhci = &bmc->soc.sdhci.slots[i];
DriveInfo *dinfo = drive_get_next(IF_SD);
BlockBackend *blk;
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 931887ac681f..931ee5aae183 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -208,6 +208,8 @@ static void aspeed_soc_ast2600_init(Object *obj)
sysbus_init_child_obj(obj, "sdc", OBJECT(&s->sdhci), sizeof(s->sdhci),
TYPE_ASPEED_SDHCI);
+object_property_set_int(OBJECT(&s->sdhci), 2, "num-slots", &error_abort);
+
/* Init sd card slot class here so that they're under the correct parent
*/
for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
sysbus_init_child_obj(obj, "sdhci[*]", OBJECT(&s->sdhci.slots[i]),
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index f4fe243458fd..3498f55603f2 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -215,6 +215,9 @@ static void aspeed_soc_init(Object *obj)
sysbus_init_child_obj(obj, "sdc", OBJECT(&s->sdhci), sizeof(s->sdhci),
TYPE_ASPEED_SDHCI);
+object_property_set_int(OBJECT(&s->sdhci), ASPEED_SDHCI_NUM_SLOTS,
+"num-slots", &error_abort);
+
/* Init sd card slot class here so that they're under the correct parent
*/
for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
sysbus_init_child_obj(obj, "sdhci[*]", OBJECT(&s->sdhci.slots[i]),
diff --git a/hw/sd/aspeed_sdhci.c b/hw/sd/aspeed_sdhci.c
index cff3eb7dd21e..939d1510dedb 100644
--- a/hw/sd/aspeed_sdhci.c
+++ b/hw/sd/aspeed_sdhci.c
@@ -13,6 +13,7 @@
#include "qapi/error.h"
#include "hw/irq.h"
#include "migration/vmstate.h"
+#include "hw/qdev-properties.h"
#define ASPEED_SDHCI_INFO0x00
#define ASPEED_SDHCI_INFO_RESET 0x0003
@@ -120,14 +121,14 @@ static void aspeed_sdhci_realize(DeviceState *dev, Error
**errp)
/* Create input irqs for the slots */
qdev_init_gpio_in_named_with_opaque(DEVICE(sbd), aspeed_sdhci_set_irq,
-sdhci, NULL, ASPEED_SDHCI_NUM_SLOTS);
+sdhci, NULL, sdhci->num_slots);
sysbus_init_irq(sbd, &sdhci->irq);
memory_region_init_io(&sdhci->iomem, OBJECT(sdhci), &aspeed_sdhci_ops,
sdhci, TYPE_ASPEED_SDHCI, 0x1000);
sysbus_init_mmio(sbd, &sdhci->iomem);
-for (int i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
+for (int i = 0; i < sdhci->num_slots; ++i) {
Object *sdhci_slot = OBJECT(&sdhci->slots[i]);
SysBusDevice *sbd_slot = SYS_BUS_DEVICE(&sdhci->slots[i]);
@@ -174,6 +175,11 @@ static const VMStateDescription vmstate_aspeed_sdhci = {
},
};
+static Property aspeed_sdhci_properties[] = {
+DEFINE_PROP_UINT8("num-slots", AspeedSDHCIState, num_slots, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
static void aspeed_sdhci_class_init(ObjectClass *classp, void *data)
{
DeviceClass *dc = DEVICE_CLASS(classp);
@@ -181,6 +187,7 @@ static void aspeed_sdhci_class_init(ObjectClass *classp,
void *data)
dc->realize = aspeed_sdhci_realize;
dc->reset = aspeed_sdhci_reset;
dc->vmsd = &vmstate_aspeed_sdhci;
+dc->props = aspeed_sdhci_properties;
}
static TypeInfo aspeed_sdhci_info = {
diff --git a/include/hw/sd/aspeed_sdhci.h b/include/hw/sd/aspeed_sdhci.h
index dfdab4379021..dffbb46946b9 100644
--- a/include/hw/sd/aspeed_sdhci.h
+++ b/include/hw/sd/aspeed_sdhci.h
@@ -24,6 +24,7 @@ typedef struct AspeedSDHCIState {
SysBusDevice parent;
SDHCIState slots[ASPEED_SDHCI_NUM_SLOTS];
+uint8_t num_slots;
MemoryRegion iomem;
qemu_irq irq;
Re: [PATCH] riscv/sifive_u: fix a memory leak in soc_realize()
On 12/10/19 8:14 AM, pannengy...@huawei.com wrote: From: Pan Nengyuan Fix a minor memory leak in riscv_sifive_u_soc_realize() Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- hw/riscv/sifive_u.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c index 0140e95..0e12b3c 100644 --- a/hw/riscv/sifive_u.c +++ b/hw/riscv/sifive_u.c @@ -542,6 +542,7 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, Error **errp) SIFIVE_U_PLIC_CONTEXT_BASE, SIFIVE_U_PLIC_CONTEXT_STRIDE, memmap[SIFIVE_U_PLIC].size); +g_free(plic_hart_config); sifive_uart_create(system_memory, memmap[SIFIVE_U_UART0].base, serial_hd(0), qdev_get_gpio_in(DEVICE(s->plic), SIFIVE_U_UART0_IRQ)); sifive_uart_create(system_memory, memmap[SIFIVE_U_UART1].base, Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] hw/usb: Introduce Kconfig switches for the CCID card devices
On 12/10/19 8:20 AM, Thomas Huth wrote: In our downstream distribution of QEMU, we need more fine-grained control on the set of CCID card devices that we want to include. So let's introduce some proper Kconfig switches that it is easier to disable them without modifying the corresponding Makefile.objs. Signed-off-by: Thomas Huth --- hw/usb/Kconfig | 10 ++ hw/usb/Makefile.objs | 7 +-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig index 555e09377b..1358847eba 100644 --- a/hw/usb/Kconfig +++ b/hw/usb/Kconfig @@ -96,3 +96,13 @@ config USB_STORAGE_MTP bool default y depends on USB + +config CCID_PASSTHRU +bool +default y +depends on USB_SMARTCARD + +config CCID_EMULATED +bool +default y +depends on USB_SMARTCARD diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs index 303ac084a0..ebe103fb3d 100644 --- a/hw/usb/Makefile.objs +++ b/hw/usb/Makefile.objs @@ -29,11 +29,14 @@ common-obj-$(CONFIG_USB_BLUETOOTH)+= dev-bluetooth.o ifeq ($(CONFIG_USB_SMARTCARD),y) common-obj-y += dev-smartcard-reader.o -common-obj-$(CONFIG_SMARTCARD)+= smartcard.mo -smartcard.mo-objs := ccid-card-passthru.o ccid-card-emulated.o +ifeq ($(CONFIG_SMARTCARD),y) We don't need the 'ifeq ($(CONFIG_SMARTCARD),y)' ... endif anymore. +common-obj-$(call lor,$(CONFIG_CCID_PASSTHRU),$(CONFIG_CCID_EMULATED)) += smartcard.mo +smartcard.mo-objs := $(call lif,$(CONFIG_CCID_PASSTHRU),ccid-card-passthru.o) \ + $(call lif,$(CONFIG_CCID_EMULATED),ccid-card-emulated.o) smartcard.mo-cflags := $(SMARTCARD_CFLAGS) smartcard.mo-libs := $(SMARTCARD_LIBS) endif +endif ifeq ($(CONFIG_POSIX),y) common-obj-$(CONFIG_USB_STORAGE_MTP) += dev-mtp.o
Re: [PATCH v8 08/21] 9pfs: well form error hint helpers
Vladimir Sementsov-Ogievskiy writes: > Make error_append_security_model_hint and > error_append_socket_sockfd_hint hint append helpers well formed: > switch errp paramter to Error *const * type, as it has uncommon > behavior: not change the pointer to return error, but operate on > already existent error object. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > Acked-by: Greg Kurz Let's adapt PATCH 03's commit message, like this: 9pfs: make Error **errp const where it is appropriate Mostly, Error ** is for returning error from the function, so the callee sets it. However error_append_security_model_hint and error_append_socket_sockfd_hint get already filled errp parameter. They don't change the pointer itself, only change the internal state of referenced Error object. So we can make it Error *const * errp, to stress the behavior. It will also help coccinelle script (in future) to distinguish such cases from common errp usage. With something like that: Reviewed-by: Markus Armbruster
[PATCH] hw/usb: Introduce Kconfig switches for the CCID card devices
In our downstream distribution of QEMU, we need more fine-grained control on the set of CCID card devices that we want to include. So let's introduce some proper Kconfig switches that it is easier to disable them without modifying the corresponding Makefile.objs. Signed-off-by: Thomas Huth --- hw/usb/Kconfig | 10 ++ hw/usb/Makefile.objs | 7 +-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig index 555e09377b..1358847eba 100644 --- a/hw/usb/Kconfig +++ b/hw/usb/Kconfig @@ -96,3 +96,13 @@ config USB_STORAGE_MTP bool default y depends on USB + +config CCID_PASSTHRU +bool +default y +depends on USB_SMARTCARD + +config CCID_EMULATED +bool +default y +depends on USB_SMARTCARD diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs index 303ac084a0..ebe103fb3d 100644 --- a/hw/usb/Makefile.objs +++ b/hw/usb/Makefile.objs @@ -29,11 +29,14 @@ common-obj-$(CONFIG_USB_BLUETOOTH)+= dev-bluetooth.o ifeq ($(CONFIG_USB_SMARTCARD),y) common-obj-y += dev-smartcard-reader.o -common-obj-$(CONFIG_SMARTCARD)+= smartcard.mo -smartcard.mo-objs := ccid-card-passthru.o ccid-card-emulated.o +ifeq ($(CONFIG_SMARTCARD),y) +common-obj-$(call lor,$(CONFIG_CCID_PASSTHRU),$(CONFIG_CCID_EMULATED)) += smartcard.mo +smartcard.mo-objs := $(call lif,$(CONFIG_CCID_PASSTHRU),ccid-card-passthru.o) \ + $(call lif,$(CONFIG_CCID_EMULATED),ccid-card-emulated.o) smartcard.mo-cflags := $(SMARTCARD_CFLAGS) smartcard.mo-libs := $(SMARTCARD_LIBS) endif +endif ifeq ($(CONFIG_POSIX),y) common-obj-$(CONFIG_USB_STORAGE_MTP) += dev-mtp.o -- 2.18.1
Re: [PATCH v8 07/21] ppc: well form kvmppc_hint_smt_possible error hint helper
Vladimir Sementsov-Ogievskiy writes: > Make kvmppc_hint_smt_possible hint append helper well formed: > switch errp paramter to Error *const * type, as it has uncommon > behavior: not change the pointer to return error, but operate on > already existent error object. > Rename function to be kvmppc_error_append_*_hint. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > Reviewed-by: Greg Kurz Let's adapt PATCH 03's commit message, like this: ppc: make Error **errp const where it is appropriate Mostly, Error ** is for returning error from the function, so the callee sets it. However kvmppc_hint_smt_possible gets already filled errp parameter. It doesn't change the pointer itself, only change the internal state of referenced Error object. So we can make it Error *const * errp, to stress the behavior. It will also help coccinelle script (in future) to distinguish such cases from common errp usage. While there, rename the function to kvmppc_error_append_smt_possible_hint(). With something like that: Reviewed-by: Markus Armbruster
Re: [PATCH v38 11/22] target/avr: Add instruction disassembly function
You are right. See at the bottom of the file. There is a comment about it
Sent from my cell phone, please ignore typos
On Tue, Dec 10, 2019, 6:21 AM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Monday, December 9, 2019, Michael Rolnik wrote:
>
>> Hi Aleksandar.
>>
>> 1. all instructions are 16 bit long except CALL & JMP they are 32 bit long
>>
>
> Accordingto the doc, LDS and STS also have 32-bit coding.
>
>
>
>> 2. next_word_used is set to true by next_word when called by append_16
>> when CALL & JMP are parsed
>>
>> Regards,
>> Michael Rolnik
>>
>> On Mon, Dec 9, 2019 at 8:10 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sunday, December 8, 2019, Michael Rolnik wrote:
>>>
Provide function disassembles executed instruction when `-d in_asm` is
provided
Example:
`./avr-softmmu/qemu-system-avr -bios
free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf -d in_asm` will produce
something like the following
```
...
IN:
0x014a: CALL 0x3808
IN: main
0x3808: CALL 0x4b4
IN: vParTestInitialise
0x04b4: LDI r24, 255
0x04b6: STS r24, 0
0x04b8: MULS r16, r20
0x04ba: OUT $1, r24
0x04bc: LDS r24, 0
0x04be: MULS r16, r20
0x04c0: OUT $2, r24
0x04c2: RET
...
```
Signed-off-by: Michael Rolnik
Suggested-by: Richard Henderson
Suggested-by: Philippe Mathieu-Daudé
Suggested-by: Aleksandar Markovic
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
target/avr/cpu.h | 1 +
target/avr/cpu.c | 2 +-
target/avr/disas.c | 226 +
target/avr/translate.c | 11 ++
4 files changed, 239 insertions(+), 1 deletion(-)
create mode 100644 target/avr/disas.c
diff --git a/target/avr/cpu.h b/target/avr/cpu.h
index c217eefeb4..a8a3e7ade6 100644
--- a/target/avr/cpu.h
+++ b/target/avr/cpu.h
@@ -178,6 +178,7 @@ bool avr_cpu_exec_interrupt(CPUState *cpu, int
int_req);
hwaddr avr_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
int avr_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
int avr_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
+int avr_print_insn(bfd_vma addr, disassemble_info *info);
static inline int avr_feature(CPUAVRState *env, int feature)
{
diff --git a/target/avr/cpu.c b/target/avr/cpu.c
index c5cafcae3c..be4b921e4d 100644
--- a/target/avr/cpu.c
+++ b/target/avr/cpu.c
@@ -83,7 +83,7 @@ static void avr_cpu_reset(CPUState *cs)
static void avr_cpu_disas_set_info(CPUState *cpu, disassemble_info
*info)
{
info->mach = bfd_arch_avr;
-info->print_insn = NULL;
+info->print_insn = avr_print_insn;
}
static void avr_cpu_realizefn(DeviceState *dev, Error **errp)
diff --git a/target/avr/disas.c b/target/avr/disas.c
new file mode 100644
index 00..22863d2eb1
--- /dev/null
+++ b/target/avr/disas.c
@@ -0,0 +1,226 @@
+/*
+ * AVR disassembler
+ *
+ * Copyright (c) 2019 Richard Henderson
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+
+typedef struct {
+disassemble_info *info;
+uint16_t next_word;
+bool next_word_used;
+} DisasContext;
+
+static int to_regs_16_31_by_one(DisasContext *ctx, int indx)
+{
+return 16 + (indx % 16);
+}
+
+static int to_regs_16_23_by_one(DisasContext *ctx, int indx)
+{
+return 16 + (indx % 8);
+}
+static int to_regs_24_30_by_two(DisasContext *ctx, int indx)
+{
+return 24 + (indx % 4) * 2;
+}
+static int to_regs_00_30_by_two(DisasContext *ctx, int indx)
+{
+return (indx % 16) * 2;
+}
+
+static uint16_t next_word(DisasContext *ctx)
+{
+
[PATCH] riscv/sifive_u: fix a memory leak in soc_realize()
From: Pan Nengyuan Fix a minor memory leak in riscv_sifive_u_soc_realize() Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- hw/riscv/sifive_u.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c index 0140e95..0e12b3c 100644 --- a/hw/riscv/sifive_u.c +++ b/hw/riscv/sifive_u.c @@ -542,6 +542,7 @@ static void riscv_sifive_u_soc_realize(DeviceState *dev, Error **errp) SIFIVE_U_PLIC_CONTEXT_BASE, SIFIVE_U_PLIC_CONTEXT_STRIDE, memmap[SIFIVE_U_PLIC].size); +g_free(plic_hart_config); sifive_uart_create(system_memory, memmap[SIFIVE_U_UART0].base, serial_hd(0), qdev_get_gpio_in(DEVICE(s->plic), SIFIVE_U_UART0_IRQ)); sifive_uart_create(system_memory, memmap[SIFIVE_U_UART1].base, -- 2.7.2.windows.1
Re: [PATCH v8 06/21] qdev-monitor: well form error hint helpers
Markus Armbruster writes: > Vladimir Sementsov-Ogievskiy writes: > >> Make qbus_list_bus and qbus_list_dev hint append helpers well formed: >> switch errp paramter to Error *const * type, as it has uncommon >> behavior: not change the pointer to return error, but operate on >> already existent error object. >> Rename functions to be error_append_*_hint. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy > > "well form error hint helpers" tells me nothing. PATCH 03 does the same > (less function renames), and is titled "make Error **errp const where it > is appropriate". I like that better. No big deal, and certainly not > worth a respin by itself. I'm happy to touch up commit messages in my > tree. Let's adapt PATCH 03's commit message, like this: qdev-monitor: make Error **errp const where it is appropriate Mostly, Error ** is for returning error from the function, so the callee sets it. However qbus_list_bus and qbus_list_dev get already filled errp parameter. They don't change the pointer itself, only change the internal state of referenced Error object. So we can make it Error *const * errp, to stress the behavior. It will also help coccinelle script (in future) to distinguish such cases from common errp usage. While there, rename the functions to qbus_error_append_bus_list_hint(), qbus_error_append_dev_list_hint(). With something like that: Reviewed-by: Markus Armbruster
Re: [PATCH] configure: Use lld --image-base for --disable-pie user mode binaries
On 2019-12-01, Fangrui Song wrote: Thanks for reviewing this patch! On 2019-12-01, Richard Henderson wrote: On 11/27/19 6:36 PM, Fangrui Song wrote: On 2019-11-20, Fangrui Song wrote: On 2019-11-15, Fangrui Song wrote: For lld, --image-base is the preferred way to set the base address. lld does not actually implement -Ttext-segment, but treats it as an alias for -Ttext. -Ttext-segment=0x6000 combined with --no-rosegment can create a 1.6GB executable. Fix the problem by using --image-base for lld. GNU ld and gold will still get -Ttext-segment. Also delete the ld --verbose fallback introduced in 2013, which is no longer relevant or correct (the default linker script has changed). Signed-off-by: Fangrui Song --- configure | 33 - 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/configure b/configure index 6099be1d84..2d45af0d09 100755 --- a/configure +++ b/configure @@ -6336,43 +6336,34 @@ fi # Probe for the need for relocating the user-only binary. if ( [ "$linux_user" = yes ] || [ "$bsd_user" = yes ] ) && [ "$pie" = no ]; then - textseg_addr= + image_base= case "$cpu" in arm | i386 | ppc* | s390* | sparc* | x86_64 | x32) - # ??? Rationale for choosing this address - textseg_addr=0x6000 + # An arbitrary address that makes it unlikely to collide with user + # programs. Please don't replace this ??? with an arbitrary rationale, which clearly doesn't apply to all of these hosts. In https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg04646.html it was suggested to move the comment around a bit. I am not puzzled where and what I should say in the comment. Can you (or other maintainers) kindly edit the comment for me? I do not know enough about qemu to provide a good rationale here. + image_base=0x6000 ;; mips) # A 256M aligned address, high in the address space, with enough # room for the code_gen_buffer above it before the stack. This is the only one with a proper rationale. That said, I'm not sure that the proper way to handle this issue with lld is to drop this code entirely. The patch changes a feature that lld does not support: -Ttext-segment, to use --image-base instead. Due to the prevalence of -z separate-code in GNU ld, -Ttext-segment is no longer appropriate. I suggested that GNU linkers implement the feature https://sourceware.org/bugzilla/show_bug.cgi?id=25207 . What gets deleted is the sed script. As I explained in the commit message, it is no longer relevant. It probably applies to an old GNU ld that FreeBSD used. FreeBSD has switched to lld now. The best way to handle the underlying issue -- address conflict between interpreter and guest binary -- is PIE, for which this code is skipped. After that, we go to some pain to choose a guest_base address that allows the guest binary to load around the interpreter's reserved addresses. So what's left that this messing about with link addresses buys us? I agree that --enable-pie will be a better solution, but dropping the support now will break at least FreeBSD. Its kernel supports running an ET_DYN executable but it does not perform address randomization. --disable-pie also appears to be used by ChromeOS developers who reported https://bugs.llvm.org/show_bug.cgi?id=43997 . I can communicate to them that migrating to --enable-pie is the way going forward. Ping? There is another very good reason that we need to keep --disable-pie for a while. Many users build statically linked qemu user mode binaries. -static-pie requires newer toolchain: * GCC 8 or clang 9 * binutils>=2.29 * glibc>=2.27 or musl Dropping support for GCC<8 does not sound a good idea in the year of 2019. (It may be in a few years.)
Re: [PATCH v1 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest
On Tue, Dec 10, 2019 at 04:05:36PM +1100, David Gibson wrote: > On Tue, Dec 10, 2019 at 03:03:01PM +1100, Alexey Kardashevskiy wrote: > > > > > > On 10/12/2019 14:50, Bharata B Rao wrote: > > > On Tue, Dec 10, 2019 at 02:28:51PM +1100, David Gibson wrote: > > >> On Mon, Dec 09, 2019 at 12:30:12PM +0530, Bharata B Rao wrote: > > >>> A pseries guest can be run as a secure guest on Ultravisor-enabled > > >>> POWER platforms. When such a secure guest is reset, we need to > > >>> release/reset a few resources both on ultravisor and hypervisor side. > > >>> This is achieved by invoking this new ioctl KVM_PPC_SVM_OFF from the > > >>> machine reset path. > > >>> > > >>> As part of this ioctl, the secure guest is essentially transitioned > > >>> back to normal mode so that it can reboot like a regular guest and > > >>> become secure again. > > >>> > > >>> This ioctl has no effect when invoked for a normal guest. > > >>> > > >>> Signed-off-by: Bharata B Rao > > >>> --- > > >>> hw/ppc/spapr.c | 1 + > > >>> target/ppc/kvm.c | 7 +++ > > >>> target/ppc/kvm_ppc.h | 6 ++ > > >>> 3 files changed, 14 insertions(+) > > >>> > > >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > >>> index f11422fc41..4c7ad3400d 100644 > > >>> --- a/hw/ppc/spapr.c > > >>> +++ b/hw/ppc/spapr.c > > >>> @@ -1597,6 +1597,7 @@ static void spapr_machine_reset(MachineState > > >>> *machine) > > >>> void *fdt; > > >>> int rc; > > >>> > > >>> +kvmppc_svm_off(); > > >> > > >> If you're going to have this return an error value, you should really > > >> check it here. > > > > > > I could, by spapr_machine_reset() and the callers don't propagate the > > > errors up. So may be I could print a warning instead when ioctl fails? > > > > An error here means you cannot restart the machine and should probably > > suspend, or try until it is not EBUSY (==all threads have stopped?). > > Right, if this fails, something has gone badly wrong. You should > absolutely print a message, and in fact it might be appropriate to > quit outright. IIUC the way PEF resets work, a failure here means you > won't be able to boot after the reset, since the guest memory will > still be inaccessible to the host. Correct. I will send next version with a message and abort() added in the ioctl failure path. Regards, Bharata.
Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update
Hi We would like to give a short update to the community about the multi-process project. Firstly, we appreciate the feedback and all productive discussions we had at KVM 2019 forum. As an outcome of the conference, we have switched gears and are investigating the ways of using the muser framework in our project. At this moment we are working on the evaluation and a first prototype of qemu-multiprocess based on muser framework. We first heard about it at the conference from the presentation given by Thanos Makatos and Swapnil Ingle from Nutanix. Their presentation is available https://static.sched.com/hosted_files/kvmforum2019/3b/muser.pdf along with github link to the source repo. After the conversation we had with a group of people including Felipe Franciosi, Stefan Hajnoczi, Daniel Berrangé, Konrad Wilk, Peter Maydell, John Jonson and few others (apologies if some names are missing), we have gathered important answers on how to move forward with qemu-multiprocess. At this moment we are working on the first stage of the project with help of the Nutanix developers. The questions we have gathered so far will be addressed with muser and Qemu developers after we finish the first stage and make sure we understand what it will take for us to move onto the next stage. We will also incorporate relevant review from Stefan that he provided on the series 4 of the patchset. Thank you Stefan. If anyone have any further suggestions or questions about the status, please reply to this email. Thank you JJ, Jag & Elena On Thu, Oct 24, 2019 at 05:08:41AM -0400, Jagannathan Raman wrote: > Started with the presentation in October 2017 made by Marc-Andre (Red Hat) > and Konrad Wilk (Oracle) [1], and continued by Jag's BoF at KVM Forum 2018, > the multi-process project is now a prototype and presented in this patchset. > John & Elena will present the status of this project in KVM Forum 2019. > > This first series enables the emulation of lsi53c895a in a separate process. > > We posted the Proof Of Concept patches [2] before the BoF session in 2018. > Subsequently, we posted RFC v1 [3], RFC v2 [4] and RFC v3 [5] of this series. > > We want to present version 4 of this series, which incorporates the feedback > we received for v3 & adds support for live migrating the remote process. > > Following people contributed to this patchset: > > John G Johnson > Jagannathan Raman > Elena Ufimtseva > Kanth Ghatraju > > For full concept writeup about QEMU disaggregation refer to > docs/devel/qemu-multiprocess.rst. Please refer to > docs/qemu-multiprocess.txt for usage information. > > We are planning on making the following improvements in the future: > - Performance improvements > - Libvirt support > - Enforcement of security policies > - blockdev support > > We welcome all your ideas, concerns, and questions for this patchset. > > Thank you! > > [1]: > http://events17.linuxfoundation.org/sites/events/files/slides/KVM%20FORUM%20multi-process.pdf > [1]: https://www.youtube.com/watch?v=Kq1-coHh7lg > [2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg566538.html > [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg602285.html > [4]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg624877.html > [5]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg642000.html > > Elena Ufimtseva (22): > multi-process: add a command line option for debug file > multi-process: introduce proxy object > mutli-process: build remote command line args > multi-process: configure remote side devices > multi-process: add qdev_proxy_add to create proxy devices > multi-process: remote: add setup_devices and setup_drive msg > processing > multi-process: remote: use fd for socket from parent process > multi-process: remote: add create_done condition > multi-process: add processing of remote drive and device command line > multi-process: refractor vl.c code to re-use in remote > multi-process: add remote option > multi-process: add remote options parser > multi-process: add parse_cmdline in remote process > multi-process: send heartbeat messages to remote > multi-process: handle heartbeat messages in remote process > multi-process/mon: choose HMP commands based on target > multi-process/mig: Load VMSD in the proxy object > multi-process/mig: refactor runstate_check into common file > multi-process/mig: Synchronize runstate of remote process > multi-process/mig: Restore the VMSD in remote process > multi-process: Enable support for multiple devices in remote > multi-process: add configure and usage information > > Jagannathan Raman (26): > multi-process: memory: alloc RAM from file at offset > multi-process: util: Add qemu_thread_cancel() to cancel running thread > multi-process: Add stub functions to facilate build of multi-process > multi-process: Add config option for multi-process QEMU > multi-process: build system for remote device process > multi
Re: [for-5.0 3/4] spapr: Clean up RMA size calculation
On Tue, Dec 03, 2019 at 04:06:46PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 03/12/2019 14:44, Alexey Kardashevskiy wrote:
> >
> >
> > On 29/11/2019 12:35, David Gibson wrote:
> >> Move the calculation of the Real Mode Area (RMA) size into a helper
> >> function. While we're there clean it up and correct it in a few ways:
> >> * Add comments making it clearer where the various constraints come from
> >> * Remove a pointless check that the RMA fits within Node 0 (we've just
> >> clamped it so that it does)
> >> * The 16GiB limit we apply is only correct for POWER8, but there is also
> >> a 1TiB limit that applies on POWER9.
> >>
> >> Signed-off-by: David Gibson
> >> ---
> >> hw/ppc/spapr.c | 57 +++---
> >> 1 file changed, 35 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >> index 52c39daa99..7efd4f2b85 100644
> >> --- a/hw/ppc/spapr.c
> >> +++ b/hw/ppc/spapr.c
> >> @@ -2664,6 +2664,40 @@ static PCIHostState *spapr_create_default_phb(void)
> >> return PCI_HOST_BRIDGE(dev);
> >> }
> >>
> >> +static hwaddr spapr_rma_size(SpaprMachineState *spapr, Error **errp)
> >> +{
> >> +MachineState *machine = MACHINE(spapr);
> >> +hwaddr rma_size = machine->ram_size;
> >> +hwaddr node0_size = spapr_node0_size(machine);
> >> +
> >> +/* RMA has to fit in the first NUMA node */
> >> +rma_size = MIN(rma_size, node0_size);
> >> +
> >> +/*
> >> + * VRMA access is via a special 1TiB SLB mapping, so the RMA can
> >> + * never exceed that
> >> + */
> >> +rma_size = MIN(rma_size, TiB);
> >> +
> >> +/*
> >> + * RMA size is controlled in hardware by LPCR[RMLS]. On POWER8
> >
> >
> > RMA is controlled by LPCR on P8 but the RMLS bits on P9 are reserved
> > (also reserved in PowerISA 3.0).
> >
> >
> >> + * the largest RMA that can be specified there is 16GiB
> >
> >
> > The P8 user manual says:
> > ===
> > The following RMO sizes are available for the POWER8 processor.
> > The RMLS[34:37] field in the LPCR defines the RMO sizes, as described below.
> > 1000 - 32 MB
> > 0011 - 64 MB
> > 0111 - 128 MB
> > 0100 - 256 MB
> > 0010 - 1 GB
> > 0001 - 16 GB
> > - 256 GB
> > ===
> >
> > The maximum seems to be 256GiB.
>
>
> Ah, update from Paul - we do not actually use what LPCR[RMLS] controls -
> Real Mode Offset Register (RMOR).
Ah... I realized where the 16GiB limit was coming from.
We don't use RMLS with KVM, but we *do* use it under TCG. The softmmu
code isn't aware of PAPR specific stuff at this point and just
consults the LPCR to handle real mode accesses. And the TCG
implementation only supports up to 16GiB, even though POWER8 supports
more.
And, AFAICT that limit will apply for a POWER9 guest in hash mode as
well. Not for initial boot, because we run in radix mode until we
determine that the guest wants hash, but if we drop back to real mode
after boot, this might matter.
I'm going to have to think about how to sort that mess out.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] usb-host: remove 'remote wakeup' flag from configuration descriptor
On Tue, Dec 10, 2019 at 12:32 AM Eduardo Habkost wrote:
>
> On Tue, Dec 03, 2019 at 09:07:15PM +0200, Yuri Benditovich wrote:
> > If the redirected device has this capability, Windows guest may
> > place the device into D2 and expect it to wake when the device
> > becomes active, but this will never happen. For example, when
> > internal Bluetooth adapter is redirected, keyboards and mice
> > connected to it do not work. Current commit removes this
> > capability (starting from machine 4.2)
> > Set 'usb-host.suppress-remote-wake' property to 'off' to keep
> > 'remote wake' as is or to 'on' to remove 'remote wake' on
> > 4.1 or earlier.
> >
> > Signed-off-by: Yuri Benditovich
> > ---
> > hw/core/machine.c| 1 +
> > hw/usb/host-libusb.c | 20
> > hw/usb/trace-events | 1 +
> > 3 files changed, 22 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 1689ad3bf8..8c0eaad091 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -29,6 +29,7 @@
> >
> > GlobalProperty hw_compat_4_1[] = {
> > { "virtio-pci", "x-pcie-flr-init", "off" },
> > +{ "usb-host", "suppress-remote-wake", "off" },
> > };
> > const size_t hw_compat_4_1_len = G_N_ELEMENTS(hw_compat_4_1);
>
> In case this doesn't get merged in QEMU 4.2.0, the patch needs to
> be updated to change hw_compat_4_2 instead (after applying the
> 5.0 machine type patch[1]).
Of course I will resubmit if needed.
>
> [1] https://patchew.org/QEMU/20191112104811.30323-1-coh...@redhat.com/
>
> --
> Eduardo
>
Re: [for-5.0 3/4] spapr: Clean up RMA size calculation
On Tue, Dec 03, 2019 at 02:44:06PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 29/11/2019 12:35, David Gibson wrote:
> > Move the calculation of the Real Mode Area (RMA) size into a helper
> > function. While we're there clean it up and correct it in a few ways:
> > * Add comments making it clearer where the various constraints come from
> > * Remove a pointless check that the RMA fits within Node 0 (we've just
> > clamped it so that it does)
> > * The 16GiB limit we apply is only correct for POWER8, but there is also
> > a 1TiB limit that applies on POWER9.
> >
> > Signed-off-by: David Gibson
> > ---
> > hw/ppc/spapr.c | 57 +++---
> > 1 file changed, 35 insertions(+), 22 deletions(-)
> >
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 52c39daa99..7efd4f2b85 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -2664,6 +2664,40 @@ static PCIHostState *spapr_create_default_phb(void)
> > return PCI_HOST_BRIDGE(dev);
> > }
> >
> > +static hwaddr spapr_rma_size(SpaprMachineState *spapr, Error **errp)
> > +{
> > +MachineState *machine = MACHINE(spapr);
> > +hwaddr rma_size = machine->ram_size;
> > +hwaddr node0_size = spapr_node0_size(machine);
> > +
> > +/* RMA has to fit in the first NUMA node */
> > +rma_size = MIN(rma_size, node0_size);
> > +
> > +/*
> > + * VRMA access is via a special 1TiB SLB mapping, so the RMA can
> > + * never exceed that
> > + */
> > +rma_size = MIN(rma_size, TiB);
> > +
> > +/*
> > + * RMA size is controlled in hardware by LPCR[RMLS]. On POWER8
>
>
> RMA is controlled by LPCR on P8 but the RMLS bits on P9 are reserved
> (also reserved in PowerISA 3.0).
>
>
> > + * the largest RMA that can be specified there is 16GiB
>
>
> The P8 user manual says:
> ===
> The following RMO sizes are available for the POWER8 processor.
> The RMLS[34:37] field in the LPCR defines the RMO sizes, as described below.
> 1000 - 32 MB
> 0011 - 64 MB
> 0111 - 128 MB
> 0100 - 256 MB
> 0010 - 1 GB
> 0001 - 16 GB
> - 256 GB
> ===
>
> The maximum seems to be 256GiB.
Huh. Ok, looks like I was wrong about where that 16GiB clamp came
from originally. I wonder where it *did* come from, or if it's simply
wrong.
> > + */
> > +if (!ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00,
> > + 0, spapr->max_compat_pvr)) {
> > +rma_size = MIN(rma_size, 16 * GiB);
> > +}
> > +
> > +if (rma_size < (MIN_RMA_SLOF * MiB)) {
>
>
> nit: it is time to redefine MIN_RMA_SLOF to use MiBs imho :)
Yeah, I'd thought about that too. I've added a patch to clean that up.
>
>
> > +error_setg(errp,
> > +"pSeries SLOF firmware requires >= %ldMiB guest RMA (Real Mode Area)",
> > + MIN_RMA_SLOF);
>
> Something went wrong with formatting here.
Actually, that's intentional. The idea is to keep the string on one
line for greppability, without going too far to the right. I believe
that's a generally accepted exception to the usual formatting rules in
qemu.
>
> Otherwise looks good. Thanks,
>
>
>
> > +return -1;
> > +}
> > +
> > +return rma_size;
> > +}
> > +
> > /* pSeries LPAR / sPAPR hardware init */
> > static void spapr_machine_init(MachineState *machine)
> > {
> > @@ -2675,7 +2709,6 @@ static void spapr_machine_init(MachineState *machine)
> > int i;
> > MemoryRegion *sysmem = get_system_memory();
> > MemoryRegion *ram = g_new(MemoryRegion, 1);
> > -hwaddr node0_size = spapr_node0_size(machine);
> > long load_limit, fw_size;
> > char *filename;
> > Error *resize_hpt_err = NULL;
> > @@ -2715,20 +2748,7 @@ static void spapr_machine_init(MachineState *machine)
> > exit(1);
> > }
> >
> > -spapr->rma_size = node0_size;
> > -
> > -/* Actually we don't support unbounded RMA anymore since we added
> > - * proper emulation of HV mode. The max we can get is 16G which
> > - * also happens to be what we configure for PAPR mode so make sure
> > - * we don't do anything bigger than that
> > - */
> > -spapr->rma_size = MIN(spapr->rma_size, 0x4ull);
> > -
> > -if (spapr->rma_size > node0_size) {
> > -error_report("Numa node 0 has to span the RMA (%#08"HWADDR_PRIx")",
> > - spapr->rma_size);
> > -exit(1);
> > -}
> > +spapr->rma_size = spapr_rma_size(spapr, &error_fatal);
> >
> > /* Setup a load limit for the ramdisk leaving room for SLOF and FDT */
> > load_limit = MIN(spapr->rma_size, RTAS_MAX_ADDR) - FW_OVERHEAD;
> > @@ -2956,13 +2976,6 @@ static void spapr_machine_init(MachineState *machine)
> > }
> > }
> >
> > -if (spapr->rma_size < (MIN_RMA_SLOF * MiB)) {
> > -error_report(
> > -"pSeries SLOF firmware requires >= %ldM guest RMA (Real Mode
> > Area memory)",
> > -MIN_RMA_SLOF)
Re: [PATCH 2/2] tests/acceptance: Makes linux_initrd and empty_cpu_model use QEMUMachine
On Tue, Nov 12, 2019 at 08:58:01AM -0500, Wainer dos Santos Moschetta wrote:
> On linux_initrd and empty_cpu_model tests the same effect of
> calling QEMU through run() to inspect the terminated process is
> achieved with a sequence of set_qmp_monitor() / launch() / wait()
> commands on an QEMUMachine object. This patch changes those
> tests to use QEMUMachine instead, so they follow the same pattern
> to launch QEMU found on other acceptance tests.
>
> Signed-off-by: Wainer dos Santos Moschetta
> ---
> tests/acceptance/empty_cpu_model.py | 13 +++--
> tests/acceptance/linux_initrd.py| 13 +++--
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/tests/acceptance/empty_cpu_model.py
> b/tests/acceptance/empty_cpu_model.py
> index 3f4f663582..8c20a4ef4a 100644
> --- a/tests/acceptance/empty_cpu_model.py
> +++ b/tests/acceptance/empty_cpu_model.py
> @@ -7,13 +7,14 @@
> #
> # This work is licensed under the terms of the GNU GPL, version 2 or
> # later. See the COPYING file in the top-level directory.
> -import subprocess
> from avocado_qemu import Test
>
> class EmptyCPUModel(Test):
> def test(self):
> -cmd = [self.qemu_bin, '-S', '-display', 'none', '-machine', 'none',
> '-cpu', '']
> -r = subprocess.run(cmd, stderr=subprocess.PIPE,
> stdout=subprocess.PIPE)
> -self.assertEquals(r.returncode, 1, "QEMU exit code should be 1")
> -self.assertEquals(r.stdout, b'', "QEMU stdout should be empty")
> -self.assertNotEquals(r.stderr, b'', "QEMU stderr shouldn't be empty")
> +self.vm.add_args('-S', '-display', 'none', '-machine', 'none',
> + '-cpu', '')
> +self.vm.set_qmp_monitor(disabled=True)
> +self.vm.launch()
> +self.vm.wait()
> +self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be
> 1")
> +self.assertRegex(self.vm.get_log(), r'-cpu option cannot be empty')
> diff --git a/tests/acceptance/linux_initrd.py
> b/tests/acceptance/linux_initrd.py
> index c61d9826a4..158ec4d46c 100644
> --- a/tests/acceptance/linux_initrd.py
> +++ b/tests/acceptance/linux_initrd.py
> @@ -10,7 +10,6 @@
>
> import logging
> import tempfile
> -from avocado.utils.process import run
>
> from avocado_qemu import Test
>
> @@ -41,13 +40,15 @@ class LinuxInitrd(Test):
> initrd.seek(max_size)
> initrd.write(b'\0')
> initrd.flush()
> -cmd = "%s -kernel %s -initrd %s -m 4096" % (
> - self.qemu_bin, kernel_path, initrd.name)
> -res = run(cmd, ignore_status=True)
> -self.assertEqual(res.exit_status, 1)
> +self.vm.add_args('-kernel', kernel_path, '-initrd', initrd.name,
> + '-m', '4096')
> +self.vm.set_qmp_monitor(disabled=True)
Like I've said on the previous patch, I'd personally go with
`enabled=True` as the default method signature, so this would become
`enabled=False`, or simply:
self.vm.set_qmp_monitor(False)
But either way,
Reviewed-by: Cleber Rosa
Tested-by: Cleber Rosa
signature.asc
Description: PGP signature
Re: [for-5.0 4/4] spapr: Correct clamping of RMA to Node 0 size
On Tue, Dec 03, 2019 at 03:18:37PM +1100, Alexey Kardashevskiy wrote: > > > On 29/11/2019 12:35, David Gibson wrote: > > The Real Mode Area (RMA) needs to fit within Node 0 in NUMA configurations. > > We use a helper function spapr_node0_size() to calculate this. > > > > But that function doesn't actually get the size of Node 0, it gets the > > minimum size of all nodes, ever since b082d65a300 "spapr: Add a helper for > > node0_size calculation". That was added, apparently, because Node 0 in > > qemu's terms might not have corresponded to Node 0 in PAPR terms (i.e. the > > node with memory at address 0). > > > After looking at this closely, I think the idea was that the first > node(s) may have only CPUs but not memory, in this case > node#0.node_mem==0 and things crash: Ah! Excellent point - I misread what the existing node0_size() function was doing. Corrected for the next spin. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v1 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest
On Tue, Dec 10, 2019 at 03:03:01PM +1100, Alexey Kardashevskiy wrote: > > > On 10/12/2019 14:50, Bharata B Rao wrote: > > On Tue, Dec 10, 2019 at 02:28:51PM +1100, David Gibson wrote: > >> On Mon, Dec 09, 2019 at 12:30:12PM +0530, Bharata B Rao wrote: > >>> A pseries guest can be run as a secure guest on Ultravisor-enabled > >>> POWER platforms. When such a secure guest is reset, we need to > >>> release/reset a few resources both on ultravisor and hypervisor side. > >>> This is achieved by invoking this new ioctl KVM_PPC_SVM_OFF from the > >>> machine reset path. > >>> > >>> As part of this ioctl, the secure guest is essentially transitioned > >>> back to normal mode so that it can reboot like a regular guest and > >>> become secure again. > >>> > >>> This ioctl has no effect when invoked for a normal guest. > >>> > >>> Signed-off-by: Bharata B Rao > >>> --- > >>> hw/ppc/spapr.c | 1 + > >>> target/ppc/kvm.c | 7 +++ > >>> target/ppc/kvm_ppc.h | 6 ++ > >>> 3 files changed, 14 insertions(+) > >>> > >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > >>> index f11422fc41..4c7ad3400d 100644 > >>> --- a/hw/ppc/spapr.c > >>> +++ b/hw/ppc/spapr.c > >>> @@ -1597,6 +1597,7 @@ static void spapr_machine_reset(MachineState > >>> *machine) > >>> void *fdt; > >>> int rc; > >>> > >>> +kvmppc_svm_off(); > >> > >> If you're going to have this return an error value, you should really > >> check it here. > > > > I could, by spapr_machine_reset() and the callers don't propagate the > > errors up. So may be I could print a warning instead when ioctl fails? > > An error here means you cannot restart the machine and should probably > suspend, or try until it is not EBUSY (==all threads have stopped?). Right, if this fails, something has gone badly wrong. You should absolutely print a message, and in fact it might be appropriate to quit outright. IIUC the way PEF resets work, a failure here means you won't be able to boot after the reset, since the guest memory will still be inaccessible to the host. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH 1/2] python/qemu: Add set_qmp_monitor() to QEMUMachine
On Tue, Nov 12, 2019 at 08:58:00AM -0500, Wainer dos Santos Moschetta wrote:
> The QEMUMachine VM has a monitor setup on which an QMP
> connection is always attempted on _post_launch() (executed
> by launch()). In case the QEMU process immediatly exits
> then the qmp.accept() (used to establish the connection) stalls
> until it reaches timeout and consequently an exception raises.
>
> That behavior is undesirable when, for instance, it needs to
> gather information from the QEMU binary ($ qemu -cpu list) or a
> test which launches the VM expecting its failure.
>
> This patch adds the set_qmp_monitor() method to QEMUMachine that
> allows turn off the creation of the monitor machinery on VM launch.
>
> Signed-off-by: Wainer dos Santos Moschetta
> ---
> python/qemu/machine.py | 68 --
> 1 file changed, 45 insertions(+), 23 deletions(-)
>
> diff --git a/python/qemu/machine.py b/python/qemu/machine.py
> index a4631d6934..04ee86e1ba 100644
> --- a/python/qemu/machine.py
> +++ b/python/qemu/machine.py
> @@ -104,6 +104,7 @@ class QEMUMachine(object):
> self._events = []
> self._iolog = None
> self._socket_scm_helper = socket_scm_helper
> +self._qmp_set = True # Enable QMP monitor by default.
> self._qmp = None
> self._qemu_full_args = None
> self._test_dir = test_dir
> @@ -228,15 +229,16 @@ class QEMUMachine(object):
> self._iolog = iolog.read()
>
> def _base_args(self):
> -if isinstance(self._monitor_address, tuple):
> -moncdev = "socket,id=mon,host=%s,port=%s" % (
> +args = ['-display', 'none', '-vga', 'none']
> +if self._qmp_set:
> +if isinstance(self._monitor_address, tuple):
> +moncdev = "socket,id=mon,host=%s,port=%s" % (
> self._monitor_address[0],
> self._monitor_address[1])
> -else:
> -moncdev = 'socket,id=mon,path=%s' % self._vm_monitor
> -args = ['-chardev', moncdev,
> -'-mon', 'chardev=mon,mode=control',
> -'-display', 'none', '-vga', 'none']
> +else:
> +moncdev = 'socket,id=mon,path=%s' % self._vm_monitor
> +args.extend(['-chardev', moncdev, '-mon',
> + 'chardev=mon,mode=control'])
> if self._machine is not None:
> args.extend(['-machine', self._machine])
> if self._console_set:
> @@ -255,20 +257,21 @@ class QEMUMachine(object):
>
> def _pre_launch(self):
> self._temp_dir = tempfile.mkdtemp(dir=self._test_dir)
> -if self._monitor_address is not None:
> -self._vm_monitor = self._monitor_address
> -else:
> -self._vm_monitor = os.path.join(self._sock_dir,
> -self._name + "-monitor.sock")
> -self._remove_files.append(self._vm_monitor)
> self._qemu_log_path = os.path.join(self._temp_dir, self._name +
> ".log")
> self._qemu_log_file = open(self._qemu_log_path, 'wb')
>
> -self._qmp = qmp.QEMUMonitorProtocol(self._vm_monitor,
> -server=True)
> +if self._qmp_set:
> +if self._monitor_address is not None:
> +self._vm_monitor = self._monitor_address
> +else:
> +self._vm_monitor = os.path.join(self._sock_dir,
> +self._name + "-monitor.sock")
> +self._remove_files.append(self._vm_monitor)
> +self._qmp = qmp.QEMUMonitorProtocol(self._vm_monitor,
> server=True)
>
> def _post_launch(self):
> -self._qmp.accept()
> +if self._qmp:
> +self._qmp.accept()
>
> def _post_shutdown(self):
> if self._qemu_log_file is not None:
> @@ -330,7 +333,8 @@ class QEMUMachine(object):
> Wait for the VM to power off
> """
> self._popen.wait()
> -self._qmp.close()
> +if self._qmp:
> +self._qmp.close()
> self._load_io_log()
> self._post_shutdown()
>
> @@ -346,12 +350,13 @@ class QEMUMachine(object):
> self._console_socket = None
>
> if self.is_running():
> -try:
> -if not has_quit:
> -self._qmp.cmd('quit')
> -self._qmp.close()
> -except:
> -self._popen.kill()
> +if self._qmp:
> +try:
> +if not has_quit:
> +self._qmp.cmd('quit')
> +self._qmp.close()
> +except:
> +self._popen.kill()
> self._popen.wait()
>
> self._load_io_log()
> @@ -368,6 +373,23 @@ class QEMUMachine(object):
>
> self._launched = False
>
> +def set_qmp_monitor(self, disabled
Re: [PATCH v38 11/22] target/avr: Add instruction disassembly function
On Monday, December 9, 2019, Michael Rolnik wrote:
> Hi Aleksandar.
>
> 1. all instructions are 16 bit long except CALL & JMP they are 32 bit long
>
Accordingto the doc, LDS and STS also have 32-bit coding.
> 2. next_word_used is set to true by next_word when called by append_16
> when CALL & JMP are parsed
>
> Regards,
> Michael Rolnik
>
> On Mon, Dec 9, 2019 at 8:10 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Sunday, December 8, 2019, Michael Rolnik wrote:
>>
>>> Provide function disassembles executed instruction when `-d in_asm` is
>>> provided
>>>
>>> Example:
>>> `./avr-softmmu/qemu-system-avr -bios
>>> free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf
>>> -d in_asm` will produce something like the following
>>>
>>> ```
>>> ...
>>> IN:
>>> 0x014a: CALL 0x3808
>>>
>>> IN: main
>>> 0x3808: CALL 0x4b4
>>>
>>> IN: vParTestInitialise
>>> 0x04b4: LDI r24, 255
>>> 0x04b6: STS r24, 0
>>> 0x04b8: MULS r16, r20
>>> 0x04ba: OUT $1, r24
>>> 0x04bc: LDS r24, 0
>>> 0x04be: MULS r16, r20
>>> 0x04c0: OUT $2, r24
>>> 0x04c2: RET
>>> ...
>>> ```
>>>
>>> Signed-off-by: Michael Rolnik
>>> Suggested-by: Richard Henderson
>>> Suggested-by: Philippe Mathieu-Daudé
>>> Suggested-by: Aleksandar Markovic
>>> Reviewed-by: Philippe Mathieu-Daudé
>>> Tested-by: Philippe Mathieu-Daudé
>>> ---
>>> target/avr/cpu.h | 1 +
>>> target/avr/cpu.c | 2 +-
>>> target/avr/disas.c | 226 +
>>> target/avr/translate.c | 11 ++
>>> 4 files changed, 239 insertions(+), 1 deletion(-)
>>> create mode 100644 target/avr/disas.c
>>>
>>> diff --git a/target/avr/cpu.h b/target/avr/cpu.h
>>> index c217eefeb4..a8a3e7ade6 100644
>>> --- a/target/avr/cpu.h
>>> +++ b/target/avr/cpu.h
>>> @@ -178,6 +178,7 @@ bool avr_cpu_exec_interrupt(CPUState *cpu, int
>>> int_req);
>>> hwaddr avr_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
>>> int avr_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
>>> int avr_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
>>> +int avr_print_insn(bfd_vma addr, disassemble_info *info);
>>>
>>> static inline int avr_feature(CPUAVRState *env, int feature)
>>> {
>>> diff --git a/target/avr/cpu.c b/target/avr/cpu.c
>>> index c5cafcae3c..be4b921e4d 100644
>>> --- a/target/avr/cpu.c
>>> +++ b/target/avr/cpu.c
>>> @@ -83,7 +83,7 @@ static void avr_cpu_reset(CPUState *cs)
>>> static void avr_cpu_disas_set_info(CPUState *cpu, disassemble_info
>>> *info)
>>> {
>>> info->mach = bfd_arch_avr;
>>> -info->print_insn = NULL;
>>> +info->print_insn = avr_print_insn;
>>> }
>>>
>>> static void avr_cpu_realizefn(DeviceState *dev, Error **errp)
>>> diff --git a/target/avr/disas.c b/target/avr/disas.c
>>> new file mode 100644
>>> index 00..22863d2eb1
>>> --- /dev/null
>>> +++ b/target/avr/disas.c
>>> @@ -0,0 +1,226 @@
>>> +/*
>>> + * AVR disassembler
>>> + *
>>> + * Copyright (c) 2019 Richard Henderson
>>> + * Copyright (c) 2019 Michael Rolnik
>>> + *
>>> + * This program is free software: you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation, either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program. If not, see
Re: [for-5.0 1/4] spapr,ppc: Simplify signature of kvmppc_rma_size()
On Mon, Dec 02, 2019 at 07:18:52PM +0100, Cédric Le Goater wrote:
> > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > index c77f9848ec..09b3bd6443 100644
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -2101,7 +2101,7 @@ void kvmppc_hint_smt_possible(Error **errp)
> >
> >
> > #ifdef TARGET_PPC64
> > -uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int hash_shift)
> > +uint64_t kvmppc_vrma_limit(unsigned int hash_shift)
> > {
> > struct kvm_ppc_smmu_info info;
> > long rampagesize, best_page_shift;
> > @@ -2128,8 +2128,7 @@ uint64_t kvmppc_rma_size(uint64_t current_size,
> > unsigned int hash_shift)
> > }
> > }
> >
> > -return MIN(current_size,
> > - 1ULL << (best_page_shift + hash_shift - 7));
> > +return 1ULL << (best_page_shift + hash_shift - 7));
>
> The closing ')' should be removed.
Oops, that's embarrassing.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH 0/7] target/ppc: Implement KVM support under TCG (final steps)
On Thu, Nov 28, 2019 at 02:46:53PM +0100, Cédric Le Goater wrote: > Hello, > > This is a resend of Suraj's series adding KVM support to the QEMU > PowerNV machine under TCG : > > http://patchwork.ozlabs.org/cover/1094658/ > > I have addressed the comments and kept for later the final patch > adding partition scoped radix tree translation. I need to educate > myself a bit more on the topic first. I've applied 1..4 to ppc-for-5.0, the rest I'm still trying to look at more closely. > > Thanks, > > C. > > Cédric Le Goater (1): > target/ppc: add support for Hypervisor Facility Unavailable Exception > > Suraj Jitindar Singh (6): > target/ppc: Implement the VTB for HV access > target/ppc: Work [S]PURR implementation and add HV support > target/ppc: Add SPR ASDR > target/ppc: Add SPR TBU40 > target/ppc: Add privileged message send facilities > target/ppc: Enforce that the root page directory size must be at least 5 > > include/hw/ppc/ppc.h| 4 +- > target/ppc/cpu.h| 11 > target/ppc/helper.h | 9 +++ > hw/ppc/ppc.c| 46 +++--- > linux-user/ppc/cpu_loop.c | 5 ++ > target/ppc/excp_helper.c| 52 ++-- > target/ppc/misc_helper.c| 46 ++ > target/ppc/mmu-radix64.c| 3 + > target/ppc/timebase_helper.c| 20 ++ > target/ppc/translate.c | 30 + > target/ppc/translate_init.inc.c | 105 +++- > 11 files changed, 297 insertions(+), 34 deletions(-) > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v1 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest
On 10/12/2019 14:50, Bharata B Rao wrote: > On Tue, Dec 10, 2019 at 02:28:51PM +1100, David Gibson wrote: >> On Mon, Dec 09, 2019 at 12:30:12PM +0530, Bharata B Rao wrote: >>> A pseries guest can be run as a secure guest on Ultravisor-enabled >>> POWER platforms. When such a secure guest is reset, we need to >>> release/reset a few resources both on ultravisor and hypervisor side. >>> This is achieved by invoking this new ioctl KVM_PPC_SVM_OFF from the >>> machine reset path. >>> >>> As part of this ioctl, the secure guest is essentially transitioned >>> back to normal mode so that it can reboot like a regular guest and >>> become secure again. >>> >>> This ioctl has no effect when invoked for a normal guest. >>> >>> Signed-off-by: Bharata B Rao >>> --- >>> hw/ppc/spapr.c | 1 + >>> target/ppc/kvm.c | 7 +++ >>> target/ppc/kvm_ppc.h | 6 ++ >>> 3 files changed, 14 insertions(+) >>> >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c >>> index f11422fc41..4c7ad3400d 100644 >>> --- a/hw/ppc/spapr.c >>> +++ b/hw/ppc/spapr.c >>> @@ -1597,6 +1597,7 @@ static void spapr_machine_reset(MachineState *machine) >>> void *fdt; >>> int rc; >>> >>> +kvmppc_svm_off(); >> >> If you're going to have this return an error value, you should really >> check it here. > > I could, by spapr_machine_reset() and the callers don't propagate the > errors up. So may be I could print a warning instead when ioctl fails? An error here means you cannot restart the machine and should probably suspend, or try until it is not EBUSY (==all threads have stopped?). -- Alexey
Re: [PATCH 2/5] ppc/pnv: Introduce a POWER10 PnvChip and a powernv10 machine
On Thu, Dec 05, 2019 at 07:44:51PM +0100, Cédric Le Goater wrote:
> This is an empty shell with the XSCOM bus and cores. The chip controllers
> will come later.
>
> Signed-off-by: Cédric Le Goater
> ---
> include/hw/ppc/pnv.h | 33
> include/hw/ppc/pnv_xscom.h | 19 +
> hw/ppc/pnv.c | 158 +++--
> hw/ppc/pnv_core.c | 10 +++
> hw/ppc/pnv_xscom.c | 23 --
> 5 files changed, 232 insertions(+), 11 deletions(-)
>
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 3a7bc3c57e0d..bfa61edfbabd 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -43,6 +43,7 @@ typedef enum PnvChipType {
> PNV_CHIP_POWER8, /* AKA Venice */
> PNV_CHIP_POWER8NVL, /* AKA Naples */
> PNV_CHIP_POWER9, /* AKA Nimbus */
> +PNV_CHIP_POWER10, /* AKA TBD */
> } PnvChipType;
>
> typedef struct PnvChip {
> @@ -105,6 +106,14 @@ typedef struct Pnv9Chip {
> #define PNV9_PIR2FUSEDCORE(pir) (((pir) >> 3) & 0xf)
> #define PNV9_PIR2CHIP(pir) (((pir) >> 8) & 0x7f)
>
> +#define TYPE_PNV10_CHIP "pnv10-chip"
> +#define PNV10_CHIP(obj) OBJECT_CHECK(Pnv10Chip, (obj), TYPE_PNV10_CHIP)
> +
> +typedef struct Pnv10Chip {
> +/*< private >*/
> +PnvChip parent_obj;
> +} Pnv10Chip;
> +
> typedef struct PnvChipClass {
> /*< private >*/
> SysBusDeviceClass parent_class;
> @@ -144,6 +153,10 @@ typedef struct PnvChipClass {
> #define PNV_CHIP_POWER9(obj) \
> OBJECT_CHECK(PnvChip, (obj), TYPE_PNV_CHIP_POWER9)
>
> +#define TYPE_PNV_CHIP_POWER10 PNV_CHIP_TYPE_NAME("power10_v1.0")
> +#define PNV_CHIP_POWER10(obj) \
> +OBJECT_CHECK(PnvChip, (obj), TYPE_PNV_CHIP_POWER10)
> +
> /*
> * This generates a HW chip id depending on an index, as found on a
> * two socket system with dual chip modules :
> @@ -203,6 +216,16 @@ PnvChip *pnv_get_chip(uint32_t chip_id);
> #define PNV_FDT_ADDR 0x0100
> #define PNV_TIMEBASE_FREQ 51200ULL
>
> +static inline bool pnv_chip_is_power10(const PnvChip *chip)
> +{
> +return PNV_CHIP_GET_CLASS(chip)->chip_type == PNV_CHIP_POWER10;
> +}
> +
> +static inline bool pnv_is_power10(PnvMachineState *pnv)
> +{
> +return pnv_chip_is_power10(pnv->chips[0]);
> +}
It's not in scope for this series, but now that we have P8/9/10
specific chip object types and powernv8/powernv9, we should be able to
remove the ugly chip_type field, and just do object class checks on
the chip and or machine objects themselves.
> +
> /*
> * BMC helpers
> */
> @@ -293,4 +316,14 @@ IPMIBmc *pnv_bmc_create(void);
> #define PNV9_HOMER_SIZE 0x0030ull
> #define PNV9_HOMER_BASE(chip) \
> (0x203ffd80ull + ((uint64_t)PNV_CHIP_INDEX(chip)) * PNV9_HOMER_SIZE)
> +
> +/*
> + * POWER10 MMIO base addresses - 16TB stride per chip
> + */
> +#define PNV10_CHIP_BASE(chip, base) \
> +((base) + ((uint64_t) (chip)->chip_id << 44))
> +
> +#define PNV10_XSCOM_SIZE 0x0004ull
> +#define PNV10_XSCOM_BASE(chip) PNV10_CHIP_BASE(chip,
> 0x00603fcull)
> +
> #endif /* PPC_PNV_H */
> diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
> index 67641ed27800..790eb3d8f3b0 100644
> --- a/include/hw/ppc/pnv_xscom.h
> +++ b/include/hw/ppc/pnv_xscom.h
> @@ -70,6 +70,9 @@ typedef struct PnvXScomInterfaceClass {
> #define PNV_XSCOM_OCC_BASE0x0066000
> #define PNV_XSCOM_OCC_SIZE0x6000
>
> +/*
> + * Layout of the XSCOM PCB addresses (POWER 9)
> + */
> #define PNV9_XSCOM_EC_BASE(core) \
> ((uint64_t)(((core) & 0x1F) + 0x20) << 24)
> #define PNV9_XSCOM_EC_SIZE0x10
> @@ -87,6 +90,22 @@ typedef struct PnvXScomInterfaceClass {
> #define PNV9_XSCOM_XIVE_BASE 0x5013000
> #define PNV9_XSCOM_XIVE_SIZE 0x300
>
> +/*
> + * Layout of the XSCOM PCB addresses (POWER 10)
> + */
> +#define PNV10_XSCOM_EQ_CHIPLET(core) (0x20 + ((core) >> 2))
> +#define PNV10_XSCOM_EQ(chiplet) ((chiplet) << 24)
> +#define PNV10_XSCOM_EC(proc)\
> +((0x2 << 16) | ((1 << (3 - (proc))) << 12))
> +
> +#define PNV10_XSCOM_EQ_BASE(core) \
> +((uint64_t) PNV10_XSCOM_EQ(PNV10_XSCOM_EQ_CHIPLET(core)))
> +#define PNV10_XSCOM_EQ_SIZE0x10
> +
> +#define PNV10_XSCOM_EC_BASE(core) \
> +((uint64_t) PNV10_XSCOM_EQ_BASE(core) | PNV10_XSCOM_EC(core & 0x3))
> +#define PNV10_XSCOM_EC_SIZE0x10
> +
> extern void pnv_xscom_realize(PnvChip *chip, uint64_t size, Error **errp);
> extern int pnv_dt_xscom(PnvChip *chip, void *fdt, int offset);
>
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index fa656858b24a..d99cd72840be 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -317,6 +317,23 @@ static void pnv_chip_power9_dt_populate(PnvChip *chip,
> void *fdt)
> pnv_dt_lpc(chip, fdt, 0);
> }
>
> +static void pnv_chip_power10_dt_populate(PnvChip *chip, void *fdt)
> +{
>
Re: [PATCH 0/5] ppc/pnv: add a POWER10 PnvChip and a powernv10 machine
On Thu, Dec 05, 2019 at 07:44:49PM +0100, Cédric Le Goater wrote: > Hello, > > The POWER10 and POWER9 processors are very similar and this series > adds the basic framework for a POWER10 chip and a machine using this > chip. The PSI and LPC models are provided first because there are no > changes. XIVE needs some adaptation and will come later. Applied to ppc-for-5.0, thanks. > > Thanks, > > C. > > Cédric Le Goater (5): > target/ppc: Add POWER10 DD1.0 model information > ppc/pnv: Introduce a POWER10 PnvChip and a powernv10 machine > ppc/psi: cleanup definitions > ppc/pnv: add a PSI bridge model for POWER10 > ppc/pnv: add a LPC Controller model for POWER10 > > include/hw/ppc/pnv.h| 46 +++ > include/hw/ppc/pnv_lpc.h| 6 +- > include/hw/ppc/pnv_psi.h| 2 + > include/hw/ppc/pnv_xscom.h | 22 > target/ppc/cpu-models.h | 3 + > target/ppc/cpu.h| 1 + > hw/ppc/pnv.c| 192 ++-- > hw/ppc/pnv_core.c | 10 ++ > hw/ppc/pnv_lpc.c| 30 +++-- > hw/ppc/pnv_psi.c| 32 - > hw/ppc/pnv_xscom.c | 23 +++- > target/ppc/compat.c | 21 +++- > target/ppc/cpu-models.c | 3 + > target/ppc/translate_init.inc.c | 215 > 14 files changed, 576 insertions(+), 30 deletions(-) > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v1 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest
On Tue, Dec 10, 2019 at 02:28:51PM +1100, David Gibson wrote: > On Mon, Dec 09, 2019 at 12:30:12PM +0530, Bharata B Rao wrote: > > A pseries guest can be run as a secure guest on Ultravisor-enabled > > POWER platforms. When such a secure guest is reset, we need to > > release/reset a few resources both on ultravisor and hypervisor side. > > This is achieved by invoking this new ioctl KVM_PPC_SVM_OFF from the > > machine reset path. > > > > As part of this ioctl, the secure guest is essentially transitioned > > back to normal mode so that it can reboot like a regular guest and > > become secure again. > > > > This ioctl has no effect when invoked for a normal guest. > > > > Signed-off-by: Bharata B Rao > > --- > > hw/ppc/spapr.c | 1 + > > target/ppc/kvm.c | 7 +++ > > target/ppc/kvm_ppc.h | 6 ++ > > 3 files changed, 14 insertions(+) > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > index f11422fc41..4c7ad3400d 100644 > > --- a/hw/ppc/spapr.c > > +++ b/hw/ppc/spapr.c > > @@ -1597,6 +1597,7 @@ static void spapr_machine_reset(MachineState *machine) > > void *fdt; > > int rc; > > > > +kvmppc_svm_off(); > > If you're going to have this return an error value, you should really > check it here. I could, by spapr_machine_reset() and the callers don't propagate the errors up. So may be I could print a warning instead when ioctl fails? Regards, Bharata.
Re: [for-5.0 PATCH] ppc: Make PPCVirtualHypervisor an incomplete type
On Mon, Dec 09, 2019 at 02:28:00PM +0100, Greg Kurz wrote:
> PPCVirtualHypervisor is an interface instance. It should never be
> dereferenced. Drop the dummy type definition for extra safety, which
> is the common practice with QOM interfaces.
>
> Signed-off-by: Greg Kurz
Applied to ppc-for-5.0.
> ---
> target/ppc/cpu.h |4
> 1 file changed, 4 deletions(-)
>
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index e3e82327b723..ab7d07d66047 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1220,10 +1220,6 @@ PowerPCCPUClass *ppc_cpu_class_by_pvr(uint32_t pvr);
> PowerPCCPUClass *ppc_cpu_class_by_pvr_mask(uint32_t pvr);
> PowerPCCPUClass *ppc_cpu_get_family_class(PowerPCCPUClass *pcc);
>
> -struct PPCVirtualHypervisor {
> -Object parent;
> -};
> -
> struct PPCVirtualHypervisorClass {
> InterfaceClass parent;
> void (*hypercall)(PPCVirtualHypervisor *vhyp, PowerPCCPU *cpu);
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v1 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest
On Mon, Dec 09, 2019 at 12:30:12PM +0530, Bharata B Rao wrote:
> A pseries guest can be run as a secure guest on Ultravisor-enabled
> POWER platforms. When such a secure guest is reset, we need to
> release/reset a few resources both on ultravisor and hypervisor side.
> This is achieved by invoking this new ioctl KVM_PPC_SVM_OFF from the
> machine reset path.
>
> As part of this ioctl, the secure guest is essentially transitioned
> back to normal mode so that it can reboot like a regular guest and
> become secure again.
>
> This ioctl has no effect when invoked for a normal guest.
>
> Signed-off-by: Bharata B Rao
> ---
> hw/ppc/spapr.c | 1 +
> target/ppc/kvm.c | 7 +++
> target/ppc/kvm_ppc.h | 6 ++
> 3 files changed, 14 insertions(+)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index f11422fc41..4c7ad3400d 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1597,6 +1597,7 @@ static void spapr_machine_reset(MachineState *machine)
> void *fdt;
> int rc;
>
> +kvmppc_svm_off();
If you're going to have this return an error value, you should really
check it here.
> spapr_caps_apply(spapr);
>
> first_ppc_cpu = POWERPC_CPU(first_cpu);
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 7406d18945..1a86fa4f0c 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2900,3 +2900,10 @@ void kvmppc_set_reg_tb_offset(PowerPCCPU *cpu, int64_t
> tb_offset)
> kvm_set_one_reg(cs, KVM_REG_PPC_TB_OFFSET, &tb_offset);
> }
> }
> +
> +int kvmppc_svm_off(void)
> +{
> +KVMState *s = KVM_STATE(current_machine->accelerator);
> +
> +return kvm_vm_ioctl(s, KVM_PPC_SVM_OFF);
> +}
> diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
> index 47b08a4030..5cc812e486 100644
> --- a/target/ppc/kvm_ppc.h
> +++ b/target/ppc/kvm_ppc.h
> @@ -37,6 +37,7 @@ int kvmppc_booke_watchdog_enable(PowerPCCPU *cpu);
> target_ulong kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
> bool radix, bool gtse,
> uint64_t proc_tbl);
> +int kvmppc_svm_off(void);
> #ifndef CONFIG_USER_ONLY
> bool kvmppc_spapr_use_multitce(void);
> int kvmppc_spapr_enable_inkernel_multitce(void);
> @@ -201,6 +202,11 @@ static inline target_ulong
> kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
> return 0;
> }
>
> +static inline int kvmppc_svm_off(void)
> +{
> +return 0;
> +}
> +
> static inline void kvmppc_set_reg_ppc_online(PowerPCCPU *cpu,
> unsigned int online)
> {
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH 2/2] analyze-migration.py: replace numpy with python 3.2
On Fri, Dec 06, 2019 at 09:27:23AM -0500, Cleber Rosa wrote:
> On Wed, Nov 27, 2019 at 02:10:38PM +0400, Marc-André Lureau wrote:
> > Use int.from_bytes() from python 3.2 instead.
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > scripts/analyze-migration.py | 35 +++
> > 1 file changed, 19 insertions(+), 16 deletions(-)
> >
> > diff --git a/scripts/analyze-migration.py b/scripts/analyze-migration.py
> > index 2b835d9b70..96a31d3974 100755
> > --- a/scripts/analyze-migration.py
> > +++ b/scripts/analyze-migration.py
> > @@ -1,4 +1,4 @@
> > -#!/usr/bin/env python
> > +#!/usr/bin/env python3
[...]
>
> Marc-André, I couldn't yet pinpoint the reason yet, but this patch
> changes the parsing of bool fields. This is a diff between the output
> pre/post this patch on the same images:
>
> $ diff -u out_x8664_pre out_x8664_post
> --- out_x8664_pre 2019-12-06 09:14:16.128943264 -0500
> +++ out_x8664_post 2019-12-06 09:23:35.861378600 -0500
> @@ -3039,7 +3039,7 @@
> "mac_reg[RADV]": "0x",
> "mac_reg[TADV]": "0x",
> "mac_reg[ITR]": "0x",
> -"mit_irq_level": true
> +"mit_irq_level": false
> },
> "e1000/full_mac_state": {
> "mac_reg": [
> @@ -36010,10 +36010,10 @@
> ],
> "smb_auxctl": "0x02",
> "smb_blkdata": "0x00",
> -"i2c_enable": true,
> +"i2c_enable": false,
> "op_done": true,
> -"in_i2c_block_read": true,
> -"start_transaction_on_status_read": true
> +"in_i2c_block_read": false,
> +"start_transaction_on_status_read": false
> },
> "ar.tmr.timer": "ff ff ff ff ff ff ff ff",
> "ar.tmr.overflow_time": "0x",
>
> This true/false flipping is consistent across various images (tried on
> images generated on a few other targets).
It looks like moving to python3 accidentally fixes a bug.
This is VMSDFieldBool.read:
def read(self):
super(VMSDFieldBool, self).read()
if self.data[0] == 0:
self.data = False
else:
self.data = True
return self.data
On python2, MigrationFile.readvar() returned a string, so the
(self.data[0] == 0) check was never true. This means all boolean
fields were always initialized to True.
On python3, MigrationFile.readvar() returns a bytearray, so the
(self.data[0] == 0) check now works as expected.
--
Eduardo
Re: [RFC PATCH 1/9] vfio/pci: introduce mediate ops to intercept vfio-pci ops
> > > > Currently, yes, i40e has build dependency on vfio-pci.
> > > > It's like this, if i40e decides to support SRIOV and compiles in vf
> > > > related code who depends on vfio-pci, it will also have build dependency
> > > > on vfio-pci. isn't it natural?
> > >
> > > No, this is not natural. There are certainly i40e VF use cases that
> > > have no interest in vfio and having dependencies between the two
> > > modules is unacceptable. I think you probably want to modularize the
> > > i40e vfio support code and then perhaps register a table in vfio-pci
> > > that the vfio-pci code can perform a module request when using a
> > > compatible device. Just and idea, there might be better options. I
> > > will not accept a solution that requires unloading the i40e driver in
> > > order to unload the vfio-pci driver. It's inconvenient with just one
> > > NIC driver, imagine how poorly that scales.
> > >
> > what about this way:
> > mediate driver registers a module notifier and every time when
> > vfio_pci is loaded, register to vfio_pci its mediate ops?
> > (Just like in below sample code)
> > This way vfio-pci is free to unload and this registering only gives
> > vfio-pci a name of what module to request.
> > After that,
> > in vfio_pci_open(), vfio-pci requests the mediate driver. (or puts
> > the mediate driver when mediate driver does not support mediating the
> > device)
> > in vfio_pci_release(), vfio-pci puts the mediate driver.
> >
> > static void register_mediate_ops(void)
> > {
> > int (*func)(struct vfio_pci_mediate_ops *ops) = NULL;
> >
> > func = symbol_get(vfio_pci_register_mediate_ops);
> >
> > if (func) {
> > func(&igd_dt_ops);
> > symbol_put(vfio_pci_register_mediate_ops);
> > }
> > }
> >
> > static int igd_module_notify(struct notifier_block *self,
> > unsigned long val, void *data)
> > {
> > struct module *mod = data;
> > int ret = 0;
> >
> > switch (val) {
> > case MODULE_STATE_LIVE:
> > if (!strcmp(mod->name, "vfio_pci"))
> > register_mediate_ops();
> > break;
> > case MODULE_STATE_GOING:
> > break;
> > default:
> > break;
> > }
> > return ret;
> > }
> >
> > static struct notifier_block igd_module_nb = {
> > .notifier_call = igd_module_notify,
> > .priority = 0,
> > };
> >
> >
> >
> > static int __init igd_dt_init(void)
> > {
> > ...
> > register_mediate_ops();
> > register_module_notifier(&igd_module_nb);
> > ...
> > return 0;
> > }
>
>
> No, this is bad. Please look at MODULE_ALIAS() and request_module() as
> used in the vfio-platform for loading reset driver modules. I think
> the correct approach is that vfio-pci should perform a request_module()
> based on the device being probed. Having the mediation provider
> listening for vfio-pci and registering itself regardless of whether we
> intend to use it assumes that we will want to use it and assumes that
> the mediation provider module is already loaded. We should be able to
> support demand loading of modules that may serve no other purpose than
> providing this mediation. Thanks,
hi Alex
Thanks for this message.
So is it good to create a separate module as mediation provider driver,
and alias its module name to "vfio-pci-mediate-vid-did".
Then when vfio-pci probes the device, it requests module of that name ?
Thanks
Yan
Re: [PATCH 1/2] tests/acceptance: Add PVH boot test
On Mon, Dec 09, 2019 at 12:43:22PM -0200, Wainer dos Santos Moschetta wrote: > > On 12/6/19 2:54 PM, Cleber Rosa wrote: > > On Fri, Dec 06, 2019 at 09:00:11AM -0500, Wainer dos Santos Moschetta wrote: > > > QEMU 4.0 onward is able to boot an uncompressed kernel > > > image by using the x86/HVM direct boot ABI. It needs > > > Linux >= 4.21 built with CONFIG_PVH=y. > > > > > > This introduces an acceptance test which checks an > > > uncompressed Linux kernel image boots properly. > > > > > > Signed-off-by: Wainer dos Santos Moschetta > > > --- > > > tests/acceptance/pvh.py | 48 + > > > 1 file changed, 48 insertions(+) > > > create mode 100644 tests/acceptance/pvh.py > > > > > > diff --git a/tests/acceptance/pvh.py b/tests/acceptance/pvh.py > > > new file mode 100644 > > > index 00..c68489c273 > > > --- /dev/null > > > +++ b/tests/acceptance/pvh.py > > > @@ -0,0 +1,48 @@ > > > +# Copyright (c) 2019 Red Hat, Inc. > > > +# > > > +# Author: > > > +# Wainer dos Santos Moschetta > > > +# > > > +# This work is licensed under the terms of the GNU GPL, version 2 or > > > +# later. See the COPYING file in the top-level directory. > > > + > > > +""" > > > +x86/HVM direct boot acceptance tests. > > > +""" > > > + > > > +from avocado.utils.kernel import KernelBuild > > > +from avocado_qemu import Test > > > +from avocado_qemu import wait_for_console_pattern > > > + > > > + > > > +class Pvh(Test): > > > +""" > > > +Test suite for x86/HVM direct boot feature. > > > + > > > +:avocado: tags=slow,arch=x86_64,machine=q35 This should be: :avocado: tags=slow,arch:x86_64,machine:q35 That is, the separator of key/val is ':', because the equal sign is used to separate the docstring directive type (here it's "tags") from their content. `avocado list -V` should show you the tag keys with all their values inside a parenthesis. That is, for the following docstring directive: :avocado: tags=slow,arch:x86_64,machine:q35,machine:pc You'd get: slow,arch(x86_64),machine(q35,pc) > > > +""" > > > +def test_boot_vmlinux(self): > > > +""" > > > +Boot uncompressed kernel image. > > > +""" > > > +# QEMU can boot a vmlinux image for kernel >= 4.21 built > > > +# with CONFIG_PVH=y > > > +kernel_version = '5.4.1' > > > +kbuild = KernelBuild(kernel_version, work_dir=self.workdir) > > > +try: > > > +kbuild.download() > > > +kbuild.uncompress() > > > +kbuild.configure(targets=['defconfig', 'kvmconfig'], > > > + extra_configs=['CONFIG_PVH=y']) > > I'm aware of the reason why this uses APIs not fulfilled by > > tests/requirements.txt, but, for the general public reviewing/testing > > code with extra requirements, it's a good idea to bump the > > requirements to a version that fulfills the requirement, and comment > > out clearly on the temporary nature of the change (marking the patch). > > Good idea, thanks for the tip. > > > > > For instance, for this requirement, we could have: > > > > diff --git a/tests/requirements.txt b/tests/requirements.txt > > index a2a587223a..5498d67bc1 100644 > > --- a/tests/requirements.txt > > +++ b/tests/requirements.txt > > @@ -1,4 +1,5 @@ > > # Add Python module requirements, one per line, to be installed > > # in the tests/venv Python virtual environment. For more info, > > # refer to: https://pip.pypa.io/en/stable/user_guide/#id1 > > -avocado-framework==72.0 > > +# [REMOVE ME] use post 73.0 Avocado containing the new kernel build APIs > > +-e > > git+https://github.com/avocado-framework/avocado@d6fb24edcf847f09c312b55df3c674c64c79793e#egg=avocado_framework > > > > This will not only help people to test it, but should also make > > it work transparently on CI. > > True. It could had helped me to check the missing packages on Travis to > build the kernel. I'm ashamed to tell how I did it. :) > Don't be, because you did check it. :) > > > > > +kbuild.build() > > As stated in my response to the cover letter, I think we need to move > > this elsewhere. The *very* minimum is to have this in a setUp() > > method, but we should strongly consider other solutions. > > On the proposed implementation the kernel is built only once and only for > this test case. If I move the code to setUp() it will attempt to build the > vmlinux for every case even when not needed (suppose I add a 'boot not > CONFIG_PVH vmlinux to check it properly handle error' case which uses > distro's kernel). Unless I put a guard like 'do not build if already > present' which IMHO is weird. In other words, IMHO setUp() should hold only > code that is share-able across cases. > I was thinking of *this* test setUp(), not avocado_qemu.Test.setUp(). Anyway, looking at the other options we talked about, I was able to boot a vmlinux image from a "mainstream distro" kernel package[1] that already has CONFIG_PVH
Re: [PATCH v2 1/3] virtio: add ability to delete vq through a pointer
On 2019/12/10 0:58, Michael S. Tsirkin wrote:
> On Mon, Dec 09, 2019 at 11:43:20AM -0500, Michael S. Tsirkin wrote:
>> On Wed, Dec 04, 2019 at 03:31:54PM +0800, pannengy...@huawei.com wrote:
>>> From: Pan Nengyuan
>>>
>>> Devices tend to maintain vq pointers, allow deleting them trough a vq
>>> pointer.
>>
>> You want to also mention something about clearing
>> .used_elems to avoid chances of double free.
>>
>>> Signed-off-by: Michael S. Tsirkin
>>> Signed-off-by: Pan Nengyuan
>>
>>
>> So let's just name the new one virtio_del_queue then,
>> and drop the old one.
>
> I tried but it seems like too much work.
Yes, some of them do not maintain the vq pointer, so can we just rename
the virtio_delete_queue to avoid confusion?
I have sent a new version before your reply, can you check whether it's
appropriate or not?
>
>>
>>> ---
>>> Changes v2 to v1:
>>> - add a new function virtio_delete_queue to cleanup vq through a vq pointer
>>> ---
>>> hw/virtio/virtio.c | 16 +++-
>>> include/hw/virtio/virtio.h | 2 ++
>>> 2 files changed, 13 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>>> index 04716b5..6de3cfd 100644
>>> --- a/hw/virtio/virtio.c
>>> +++ b/hw/virtio/virtio.c
>>> @@ -2330,17 +2330,23 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int
>>> queue_size,
>>> return &vdev->vq[i];
>>> }
>>>
>>> +void virtio_delete_queue(VirtQueue *vq)
>>> +{
>>> +vq->vring.num = 0;
>>> +vq->vring.num_default = 0;
>>> +vq->handle_output = NULL;
>>> +vq->handle_aio_output = NULL;
>>> +g_free(vq->used_elems);
>>> +vq->used_elems = NULL;
>>> +}
>>> +
>>> void virtio_del_queue(VirtIODevice *vdev, int n)
>>> {
>>> if (n < 0 || n >= VIRTIO_QUEUE_MAX) {
>>> abort();
>>> }
>>>
>>> -vdev->vq[n].vring.num = 0;
>>> -vdev->vq[n].vring.num_default = 0;
>>> -vdev->vq[n].handle_output = NULL;
>>> -vdev->vq[n].handle_aio_output = NULL;
>>> -g_free(vdev->vq[n].used_elems);
>>> +virtio_delete_queue(&vdev->vq[n]);
>>> }
>>>
>>> static void virtio_set_isr(VirtIODevice *vdev, int value)
>>> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
>>> index c32a815..e18756d 100644
>>> --- a/include/hw/virtio/virtio.h
>>> +++ b/include/hw/virtio/virtio.h
>>> @@ -183,6 +183,8 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int
>>> queue_size,
>>>
>>> void virtio_del_queue(VirtIODevice *vdev, int n);
>>>
>>> +void virtio_delete_queue(VirtQueue *vq);
>>> +
>>> void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
>>> unsigned int len);
>>> void virtqueue_flush(VirtQueue *vq, unsigned int count);
>>> --
>>> 2.7.2.windows.1
>>>
>
>
> .
>
Re: [PATCH v2 4/4] python/qemu: accel: Add tcg_available() method
On Fri, Dec 06, 2019 at 04:34:33PM -0500, Wainer dos Santos Moschetta wrote: > This adds a method to check if the tcg accelerator is enabled > in the QEMU binary. > > Signed-off-by: Wainer dos Santos Moschetta > Reviewed-by: Alex Bennée > Reviewed-by: Philippe Mathieu-Daudé > --- > python/qemu/accel.py | 8 > 1 file changed, 8 insertions(+) > > diff --git a/python/qemu/accel.py b/python/qemu/accel.py > index 9fecffb44b..f4ff31825d 100644 > --- a/python/qemu/accel.py > +++ b/python/qemu/accel.py > @@ -67,3 +67,11 @@ def kvm_available(target_arch=None, qemu_bin=None): > if qemu_bin and "kvm" not in list_accel(qemu_bin): > return False > return True > + > +def tcg_available(qemu_bin): > +""" > +Check if TCG is available. > + > +@param qemu_bin (str): path to the QEMU binary > +""" > +return 'tcg' in list_accel(qemu_bin) > -- > 2.21.0 > Reviewed-by: Cleber Rosa Tested-by: Cleber Rosa signature.asc Description: PGP signature
Re: [PATCH v2 3/4] python/qemu: accel: Strengthen kvm_available() checks
On Fri, Dec 06, 2019 at 04:34:32PM -0500, Wainer dos Santos Moschetta wrote:
> Currently kvm_available() checks for the presence of kvm module
> and, if target and host arches don't mismatch. This patch adds
> an 3rd checking: if QEMU binary was compiled with kvm
> support.
>
> Signed-off-by: Wainer dos Santos Moschetta
> Reviewed-by: Alex Bennée
> Reviewed-by: Philippe Mathieu-Daudé
> ---
> python/qemu/accel.py | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/python/qemu/accel.py b/python/qemu/accel.py
> index 746b7e68f5..9fecffb44b 100644
> --- a/python/qemu/accel.py
> +++ b/python/qemu/accel.py
> @@ -46,9 +46,24 @@ def list_accel(qemu_bin):
> # Skip the first line which is the header.
> return [l.strip() for l in lines[1:] if l]
>
> -def kvm_available(target_arch=None):
> -host_arch = os.uname()[4]
> -if target_arch and target_arch != host_arch:
> -if target_arch != ADDITIONAL_ARCHES.get(host_arch):
> -return False
> -return os.access("/dev/kvm", os.R_OK | os.W_OK)
> +def kvm_available(target_arch=None, qemu_bin=None):
> +"""
> +Check if KVM is available using the following heuristic:
> + - Kernel module is present in the host;
> + - Target and host arches don't mismatch;
> + - KVM is enabled in the QEMU binary.
> +
> +@param target_arch (str): target architecture
> +@param qemu_bin (str): path to the QEMU binary
> +@return True if kvm is available, otherwise False.
> +"""
> +if not os.access("/dev/kvm", os.R_OK | os.W_OK):
> +return False
> +if target_arch:
> +host_arch = os.uname()[4]
> +if target_arch != host_arch:
> +if target_arch != ADDITIONAL_ARCHES.get(host_arch):
> +return False
> +if qemu_bin and "kvm" not in list_accel(qemu_bin):
> +return False
> +return True
> --
> 2.21.0
>
Reviewed-by: Cleber Rosa
Tested-by: Cleber Rosa
signature.asc
Description: PGP signature
[PATCH 2/2] hw/arm: ast2600: Wire up the eMMC controller
Initialise another SDHCI model instance for the AST2600's eMMC
controller and use the SDHCI's num_slots value introduced previously to
determine whether we should create an SD card instance for the new slot.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed.c | 13 +
hw/arm/aspeed_ast2600.c | 21 +
include/hw/arm/aspeed_soc.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 862549b1f3a9..0e08d62e9ff3 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -272,6 +272,19 @@ static void aspeed_board_init(MachineState *machine,
object_property_set_bool(OBJECT(card), true, "realized", &error_fatal);
}
+if (bmc->soc.emmc.num_slots) {
+SDHCIState *emmc = &bmc->soc.emmc.slots[0];
+DriveInfo *dinfo = drive_get_next(IF_SD);
+BlockBackend *blk;
+DeviceState *card;
+
+blk = dinfo ? blk_by_legacy_dinfo(dinfo) : NULL;
+card = qdev_create(qdev_get_child_bus(DEVICE(emmc), "sd-bus"),
+ TYPE_SD_CARD);
+qdev_prop_set_drive(card, "drive", blk, &error_fatal);
+object_property_set_bool(OBJECT(card), true, "realized", &error_fatal);
+}
+
arm_load_kernel(ARM_CPU(first_cpu), machine, &aspeed_board_binfo);
}
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 931ee5aae183..723c8196c8a5 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -46,6 +46,7 @@ static const hwaddr aspeed_soc_ast2600_memmap[] = {
[ASPEED_ADC] = 0x1E6E9000,
[ASPEED_VIDEO] = 0x1E70,
[ASPEED_SDHCI] = 0x1E74,
+[ASPEED_EMMC] = 0x1E75,
[ASPEED_GPIO] = 0x1E78,
[ASPEED_GPIO_1_8V] = 0x1E780800,
[ASPEED_RTC] = 0x1E781000,
@@ -64,6 +65,7 @@ static const hwaddr aspeed_soc_ast2600_memmap[] = {
#define ASPEED_SOC_AST2600_MAX_IRQ 128
+/* Shared Peripheral Interrupt values below are offset by -32 from datasheet */
static const int aspeed_soc_ast2600_irqmap[] = {
[ASPEED_UART1] = 47,
[ASPEED_UART2] = 48,
@@ -77,6 +79,7 @@ static const int aspeed_soc_ast2600_irqmap[] = {
[ASPEED_ADC] = 78,
[ASPEED_XDMA] = 6,
[ASPEED_SDHCI] = 43,
+[ASPEED_EMMC] = 15,
[ASPEED_GPIO] = 40,
[ASPEED_GPIO_1_8V] = 11,
[ASPEED_RTC] = 13,
@@ -215,6 +218,14 @@ static void aspeed_soc_ast2600_init(Object *obj)
sysbus_init_child_obj(obj, "sdhci[*]", OBJECT(&s->sdhci.slots[i]),
sizeof(s->sdhci.slots[i]), TYPE_SYSBUS_SDHCI);
}
+
+sysbus_init_child_obj(obj, "emmc", OBJECT(&s->emmc), sizeof(s->emmc),
+ TYPE_ASPEED_SDHCI);
+
+object_property_set_int(OBJECT(&s->emmc), 1, "num-slots", &error_abort);
+
+sysbus_init_child_obj(obj, "emmc[*]", OBJECT(&s->emmc.slots[0]),
+sizeof(s->emmc.slots[0]), TYPE_SYSBUS_SDHCI);
}
/*
@@ -487,6 +498,16 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev,
Error **errp)
sc->memmap[ASPEED_SDHCI]);
sysbus_connect_irq(SYS_BUS_DEVICE(&s->sdhci), 0,
aspeed_soc_get_irq(s, ASPEED_SDHCI));
+
+/* eMMC */
+object_property_set_bool(OBJECT(&s->emmc), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->emmc), 0, sc->memmap[ASPEED_EMMC]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->emmc), 0,
+ aspeed_soc_get_irq(s, ASPEED_EMMC));
}
static void aspeed_soc_ast2600_class_init(ObjectClass *oc, void *data)
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index 495c08be1b84..911443f4c071 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -56,6 +56,7 @@ typedef struct AspeedSoCState {
AspeedGPIOState gpio;
AspeedGPIOState gpio_1_8v;
AspeedSDHCIState sdhci;
+AspeedSDHCIState emmc;
} AspeedSoCState;
#define TYPE_ASPEED_SOC "aspeed-soc"
@@ -125,6 +126,7 @@ enum {
ASPEED_MII4,
ASPEED_SDRAM,
ASPEED_XDMA,
+ASPEED_EMMC,
};
#endif /* ASPEED_SOC_H */
--
git-series 0.9.1
Re: [PATCH v2 2/4] python/qemu: accel: Add list_accel() method
On Fri, Dec 06, 2019 at 04:34:31PM -0500, Wainer dos Santos Moschetta wrote:
> Since commit cbe6d6365a48 the command `qemu -accel help` returns
> the list of accelerators enabled in the QEMU binary. This adds
> the list_accel() method which return that same list.
>
> Signed-off-by: Wainer dos Santos Moschetta
> Reviewed-by: Alex Bennée
> Reviewed-by: Philippe Mathieu-Daudé
> ---
> python/qemu/accel.py | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/python/qemu/accel.py b/python/qemu/accel.py
> index cbeac10dd1..746b7e68f5 100644
> --- a/python/qemu/accel.py
> +++ b/python/qemu/accel.py
> @@ -14,7 +14,11 @@ accelerators.
> # the COPYING file in the top-level directory.
> #
>
> +import logging
> import os
> +import subprocess
> +
> +LOG = logging.getLogger(__name__)
>
> # Mapping host architecture to any additional architectures it can
> # support which often includes its 32 bit cousin.
> @@ -23,6 +27,25 @@ ADDITIONAL_ARCHES = {
> "aarch64" : "armhf"
> }
>
> +def list_accel(qemu_bin):
> +"""
> +List accelerators enabled in the QEMU binary.
> +
> +@param qemu_bin (str): path to the QEMU binary.
> +@raise Exception: if failed to run `qemu -accel help`
> +@return a list of accelerator names.
> +"""
> +if not qemu_bin:
> +return []
> +try:
> +out = subprocess.check_output("%s -accel help" % qemu_bin,
> shell=True)
There's no need to use a shell here. This could become:
out = subprocess.check_output([qemu_bin, '-accel' 'help'])
> +except:
> +LOG.debug("Failed to get the list of accelerators in %s" % qemu_bin)
> +raise
> +lines = out.decode().splitlines()
And maybe discard the first line earlier with:
lines = out.decode().splitlines()[1:]
Also, you could avoid the manual decode() with the `universal_newlines`
option to subprocess.check_output(), ie:
accels = subprocess.check_output([qemu-bin, '-accel', 'help'],
universal_newlines=True).splitlines()[1:]
> +# Skip the first line which is the header.
> +return [l.strip() for l in lines[1:] if l]
> +
I think that the `if l` check can actually hide undesirable behavior
(bugs) in the `qemu -accel ?` output. I don't remember seeing
`-$(option) ?` returning empty strings but doesn't mean it couldn't
and shouldn't).
I do remember `-machine ?` returning random non-printable characters
that turned out to be a bug, though.
> def kvm_available(target_arch=None):
> host_arch = os.uname()[4]
> if target_arch and target_arch != host_arch:
> --
> 2.21.0
>
- Cleber.
signature.asc
Description: PGP signature
[PATCH 1/2] hw/sd: Configure number of slots exposed by the ASPEED SDHCI model
The AST2600 includes a second cut-down version of the SD/MMC controller
found in the AST2500, named the eMMC controller. It's cut down in the
sense that it only supports one slot rather than two, but it brings the
total number of slots supported by the AST2600 to three.
The existing code assumed that the SD controller always provided two
slots. Rework the SDHCI object to expose the number of slots as a
property to be set by the SoC configuration.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed.c | 2 +-
hw/arm/aspeed_ast2600.c | 2 ++
hw/arm/aspeed_soc.c | 3 +++
hw/sd/aspeed_sdhci.c | 11 +--
include/hw/sd/aspeed_sdhci.h | 1 +
5 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 028191ff36fc..862549b1f3a9 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -259,7 +259,7 @@ static void aspeed_board_init(MachineState *machine,
cfg->i2c_init(bmc);
}
-for (i = 0; i < ARRAY_SIZE(bmc->soc.sdhci.slots); i++) {
+for (i = 0; i < bmc->soc.sdhci.num_slots; i++) {
SDHCIState *sdhci = &bmc->soc.sdhci.slots[i];
DriveInfo *dinfo = drive_get_next(IF_SD);
BlockBackend *blk;
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 931887ac681f..931ee5aae183 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -208,6 +208,8 @@ static void aspeed_soc_ast2600_init(Object *obj)
sysbus_init_child_obj(obj, "sdc", OBJECT(&s->sdhci), sizeof(s->sdhci),
TYPE_ASPEED_SDHCI);
+object_property_set_int(OBJECT(&s->sdhci), 2, "num-slots", &error_abort);
+
/* Init sd card slot class here so that they're under the correct parent */
for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
sysbus_init_child_obj(obj, "sdhci[*]", OBJECT(&s->sdhci.slots[i]),
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index f4fe243458fd..3498f55603f2 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -215,6 +215,9 @@ static void aspeed_soc_init(Object *obj)
sysbus_init_child_obj(obj, "sdc", OBJECT(&s->sdhci), sizeof(s->sdhci),
TYPE_ASPEED_SDHCI);
+object_property_set_int(OBJECT(&s->sdhci), ASPEED_SDHCI_NUM_SLOTS,
+"num-slots", &error_abort);
+
/* Init sd card slot class here so that they're under the correct parent */
for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
sysbus_init_child_obj(obj, "sdhci[*]", OBJECT(&s->sdhci.slots[i]),
diff --git a/hw/sd/aspeed_sdhci.c b/hw/sd/aspeed_sdhci.c
index cff3eb7dd21e..939d1510dedb 100644
--- a/hw/sd/aspeed_sdhci.c
+++ b/hw/sd/aspeed_sdhci.c
@@ -13,6 +13,7 @@
#include "qapi/error.h"
#include "hw/irq.h"
#include "migration/vmstate.h"
+#include "hw/qdev-properties.h"
#define ASPEED_SDHCI_INFO0x00
#define ASPEED_SDHCI_INFO_RESET 0x0003
@@ -120,14 +121,14 @@ static void aspeed_sdhci_realize(DeviceState *dev, Error
**errp)
/* Create input irqs for the slots */
qdev_init_gpio_in_named_with_opaque(DEVICE(sbd), aspeed_sdhci_set_irq,
-sdhci, NULL, ASPEED_SDHCI_NUM_SLOTS);
+sdhci, NULL, sdhci->num_slots);
sysbus_init_irq(sbd, &sdhci->irq);
memory_region_init_io(&sdhci->iomem, OBJECT(sdhci), &aspeed_sdhci_ops,
sdhci, TYPE_ASPEED_SDHCI, 0x1000);
sysbus_init_mmio(sbd, &sdhci->iomem);
-for (int i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
+for (int i = 0; i < sdhci->num_slots; ++i) {
Object *sdhci_slot = OBJECT(&sdhci->slots[i]);
SysBusDevice *sbd_slot = SYS_BUS_DEVICE(&sdhci->slots[i]);
@@ -174,6 +175,11 @@ static const VMStateDescription vmstate_aspeed_sdhci = {
},
};
+static Property aspeed_sdhci_properties[] = {
+DEFINE_PROP_UINT8("num-slots", AspeedSDHCIState, num_slots, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
static void aspeed_sdhci_class_init(ObjectClass *classp, void *data)
{
DeviceClass *dc = DEVICE_CLASS(classp);
@@ -181,6 +187,7 @@ static void aspeed_sdhci_class_init(ObjectClass *classp,
void *data)
dc->realize = aspeed_sdhci_realize;
dc->reset = aspeed_sdhci_reset;
dc->vmsd = &vmstate_aspeed_sdhci;
+dc->props = aspeed_sdhci_properties;
}
static TypeInfo aspeed_sdhci_info = {
diff --git a/include/hw/sd/aspeed_sdhci.h b/include/hw/sd/aspeed_sdhci.h
index dfdab4379021..dffbb46946b9 100644
--- a/include/hw/sd/aspeed_sdhci.h
+++ b/include/hw/sd/aspeed_sdhci.h
@@ -24,6 +24,7 @@ typedef struct AspeedSDHCIState {
SysBusDevice parent;
SDHCIState slots[ASPEED_SDHCI_NUM_SLOTS];
+uint8_t num_slots;
MemoryRegion iomem;
qemu_irq irq;
--
git-series 0.9.1
[PATCH 0/2] hw/arm: ast2600: Wire up eMMC controller
Hello, The AST2600 has an additional SDHCI intended for use as an eMMC boot source. These two patches rework the existing ASPEED SDHCI model to accommodate the single-slot nature of the eMMC controller and wire it into the AST2600 SoC. Please review! Andrew Andrew Jeffery (2): hw/sd: Configure number of slots exposed by the ASPEED SDHCI model hw/arm: ast2600: Wire up the eMMC controller hw/arm/aspeed.c | 15 ++- hw/arm/aspeed_ast2600.c | 23 +++ hw/arm/aspeed_soc.c | 3 +++ hw/sd/aspeed_sdhci.c | 11 +-- include/hw/arm/aspeed_soc.h | 2 ++ include/hw/sd/aspeed_sdhci.h | 1 + 6 files changed, 52 insertions(+), 3 deletions(-) base-commit: 6a4ef4e5d1084ce41fafa7d470a644b0fd3d9317 -- git-series 0.9.1
Re: [PATCH v2 1/4] python/qemu: Move kvm_available() to its own module
On Fri, Dec 06, 2019 at 04:34:30PM -0500, Wainer dos Santos Moschetta wrote:
> This creates the 'accel' Python module to be the home for
> utilities that deal with accelerators. Also moved kvm_available()
> from __init__.py to this new module.
>
> Signed-off-by: Wainer dos Santos Moschetta
> Reviewed-by: Alex Bennée
> Reviewed-by: Philippe Mathieu-Daudé
> ---
> python/qemu/__init__.py | 20 +---
> python/qemu/accel.py| 31 +++
> tests/vm/basevm.py | 2 +-
> 3 files changed, 33 insertions(+), 20 deletions(-)
> create mode 100644 python/qemu/accel.py
>
> diff --git a/python/qemu/__init__.py b/python/qemu/__init__.py
> index 6c919a3d56..eff17a306e 100644
> --- a/python/qemu/__init__.py
> +++ b/python/qemu/__init__.py
> @@ -12,24 +12,6 @@
> # Based on qmp.py.
> #
>
> -import logging
> -import os
> -
> from . import qmp
> from . import machine
These lines don't achieve anything besides forcing an earlier
evaluation of those modules, which AFAICT is totally unnecessary.
If there was code in QEMU such as:
import qemu
def foo():
...
raise qemu.qmp.QMPError
Then there would be a reason for such imports. I couldn't find
any though. Anyway, I now this is not from your patch but...
> -
> -LOG = logging.getLogger(__name__)
> -
> -# Mapping host architecture to any additional architectures it can
> -# support which often includes its 32 bit cousin.
> -ADDITIONAL_ARCHES = {
> -"x86_64" : "i386",
> -"aarch64" : "armhf"
> -}
> -
> -def kvm_available(target_arch=None):
> -host_arch = os.uname()[4]
> -if target_arch and target_arch != host_arch:
> -if target_arch != ADDITIONAL_ARCHES.get(host_arch):
> -return False
> -return os.access("/dev/kvm", os.R_OK | os.W_OK)
> +from . import accel
... according to that reasoning, this should be ommited. IMO we could
use another patch in this series removing those imports.
> diff --git a/python/qemu/accel.py b/python/qemu/accel.py
> new file mode 100644
> index 00..cbeac10dd1
> --- /dev/null
> +++ b/python/qemu/accel.py
> @@ -0,0 +1,31 @@
> +"""
> +QEMU accel module:
> +
> +This module provides utilities for discover and check the availability of
> +accelerators.
> +"""
> +# Copyright (C) 2015-2016 Red Hat Inc.
> +# Copyright (C) 2012 IBM Corp.
> +#
> +# Authors:
> +# Fam Zheng
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2. See
> +# the COPYING file in the top-level directory.
> +#
> +
> +import os
> +
> +# Mapping host architecture to any additional architectures it can
> +# support which often includes its 32 bit cousin.
> +ADDITIONAL_ARCHES = {
> +"x86_64" : "i386",
> +"aarch64" : "armhf"
> +}
> +
> +def kvm_available(target_arch=None):
> +host_arch = os.uname()[4]
> +if target_arch and target_arch != host_arch:
> +if target_arch != ADDITIONAL_ARCHES.get(host_arch):
> +return False
> +return os.access("/dev/kvm", os.R_OK | os.W_OK)
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> index 91a9226026..3e2b69c96c 100755
> --- a/tests/vm/basevm.py
> +++ b/tests/vm/basevm.py
> @@ -21,7 +21,7 @@ import logging
> import time
> import datetime
> sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..',
> 'python'))
> -from qemu import kvm_available
> +from qemu.accel import kvm_available
> from qemu.machine import QEMUMachine
> import subprocess
> import hashlib
> --
> 2.21.0
>
Other than that, this LGTM.
- Cleber.
signature.asc
Description: PGP signature
Re: [PATCH V3 0/4] Introduce Advanced Watch Dog module
On 12/9/2019 5:08 PM, Paolo Bonzini wrote:
On 08/12/19 18:52, Zhang, Chen wrote:
Hi All~
No news for a long time.
Please give me more comments about this series.
Sorry, people were probably busy with the QEMU release candidates.
Even before looking at the code, the series is completely missing
documentation on how to use it and on the chardev protocol. The
documentation should go in docs/ and should be written as restructuredText.
The qemu-options.hx patches also lack documentation about the properties
accepted by the new object.
OK, I will add documentation in docs/ and qemu-options.hx in next version.
For the chardev protocol part, current implementation just use plaintext
that make AWD easy to connect with other user defined node, I am not
very familiar with this part, do you have any suggestions here? maybe
use some general protocol is better? or Jason have any suggestions?
In particular:
-chardev socket,id=h1,host=3.3.3.3,port=9009,server,nowait
-chardev socket,id=heartbeat0,host=3.3.3.3,port=4445
-object iothread,id=iothread2
-object
advanced-watchdog,id=heart1,server=on,awd_node=h1,notification_node=heartbeat0,opt_script=colo_opt_script_path,iothread=iothread1,pulse_interval=1000,timeout=5000
What are the two sockets for, and what should be in colo_opt_script_path?
Anything user want to send when timeout, for example:
If timeout is detected, AWD send quit command to Qemu.
colo_opt_script_path=/tmp/qemu-qmp-quit.script
qemu-qmp-quit.script:
{ "execute": "quit" }
Thanks
Zhang Chen
In secondary node:
-monitor tcp::4445,server,nowait
-chardev socket,id=h1,host=3.3.3.3,port=9009,reconnect=1
-chardev socket,id=heart1,host=3.3.3.8,port=4445
-object iothread,id=iothread1
-object
advanced-watchdog,id=heart1,server=off,awd_node=h1,notification_node=heart1,opt_script=colo_secondary_opt_script,iothread=iothread1,timeout=1
Same here.
Paolo
Re: [RFC PATCH 1/9] vfio/pci: introduce mediate ops to intercept vfio-pci ops
On Sun, 8 Dec 2019 22:42:25 -0500
Yan Zhao wrote:
> On Sat, Dec 07, 2019 at 05:22:26AM +0800, Alex Williamson wrote:
> > On Fri, 6 Dec 2019 02:56:55 -0500
> > Yan Zhao wrote:
> >
> > > On Fri, Dec 06, 2019 at 07:55:19AM +0800, Alex Williamson wrote:
> > > > On Wed, 4 Dec 2019 22:25:36 -0500
> > > > Yan Zhao wrote:
> > > >
> > > > > when vfio-pci is bound to a physical device, almost all the hardware
> > > > > resources are passthroughed.
> > > > > Sometimes, vendor driver of this physcial device may want to mediate
> > > > > some
> > > > > hardware resource access for a short period of time, e.g. dirty page
> > > > > tracking during live migration.
> > > > >
> > > > > Here we introduce mediate ops in vfio-pci for this purpose.
> > > > >
> > > > > Vendor driver can register a mediate ops to vfio-pci.
> > > > > But rather than directly bind to the passthroughed device, the
> > > > > vendor driver is now either a module that does not bind to any device
> > > > > or
> > > > > a module binds to other device.
> > > > > E.g. when passing through a VF device that is bound to vfio-pci
> > > > > modules,
> > > > > PF driver that binds to PF device can register to vfio-pci to mediate
> > > > > VF's regions, hence supporting VF live migration.
> > > > >
> > > > > The sequence goes like this:
> > > > > 1. Vendor driver register its vfio_pci_mediate_ops to vfio-pci driver
> > > > >
> > > > > 2. vfio-pci maintains a list of those registered vfio_pci_mediate_ops
> > > > >
> > > > > 3. Whenever vfio-pci opens a device, it searches the list and call
> > > > > vfio_pci_mediate_ops->open() to check whether a vendor driver supports
> > > > > mediating this device.
> > > > > Upon a success return value of from vfio_pci_mediate_ops->open(),
> > > > > vfio-pci will stop list searching and store a mediate handle to
> > > > > represent this open into vendor driver.
> > > > > (so if multiple vendor drivers support mediating a device through
> > > > > vfio_pci_mediate_ops, only one will win, depending on their
> > > > > registering
> > > > > sequence)
> > > > >
> > > > > 4. Whenever a VFIO_DEVICE_GET_REGION_INFO ioctl is received in
> > > > > vfio-pci
> > > > > ops, it will chain into vfio_pci_mediate_ops->get_region_info(), so
> > > > > that
> > > > > vendor driver is able to override a region's default flags and caps,
> > > > > e.g. adding a sparse mmap cap to passthrough only sub-regions of a
> > > > > whole
> > > > > region.
> > > > >
> > > > > 5. vfio_pci_rw()/vfio_pci_mmap() first calls into
> > > > > vfio_pci_mediate_ops->rw()/vfio_pci_mediate_ops->mmaps().
> > > > > if pt=true is rteturned, vfio_pci_rw()/vfio_pci_mmap() will further
> > > > > passthrough this read/write/mmap to physical device, otherwise it just
> > > > > returns without touch physical device.
> > > > >
> > > > > 6. When vfio-pci closes a device, vfio_pci_release() chains into
> > > > > vfio_pci_mediate_ops->release() to close the reference in vendor
> > > > > driver.
> > > > >
> > > > > 7. Vendor driver unregister its vfio_pci_mediate_ops when driver exits
> > > > >
> > > > > Cc: Kevin Tian
> > > > >
> > > > > Signed-off-by: Yan Zhao
> > > > > ---
> > > > > drivers/vfio/pci/vfio_pci.c | 146
> > > > >
> > > > > drivers/vfio/pci/vfio_pci_private.h | 2 +
> > > > > include/linux/vfio.h| 16 +++
> > > > > 3 files changed, 164 insertions(+)
> > > > >
> > > > > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > > > > index 02206162eaa9..55080ff29495 100644
> > > > > --- a/drivers/vfio/pci/vfio_pci.c
> > > > > +++ b/drivers/vfio/pci/vfio_pci.c
> > > > > @@ -54,6 +54,14 @@ module_param(disable_idle_d3, bool, S_IRUGO |
> > > > > S_IWUSR);
> > > > > MODULE_PARM_DESC(disable_idle_d3,
> > > > >"Disable using the PCI D3 low power state for idle,
> > > > > unused devices");
> > > > >
> > > > > +static LIST_HEAD(mediate_ops_list);
> > > > > +static DEFINE_MUTEX(mediate_ops_list_lock);
> > > > > +struct vfio_pci_mediate_ops_list_entry {
> > > > > + struct vfio_pci_mediate_ops *ops;
> > > > > + int refcnt;
> > > > > + struct list_headnext;
> > > > > +};
> > > > > +
> > > > > static inline bool vfio_vga_disabled(void)
> > > > > {
> > > > > #ifdef CONFIG_VFIO_PCI_VGA
> > > > > @@ -472,6 +480,10 @@ static void vfio_pci_release(void *device_data)
> > > > > if (!(--vdev->refcnt)) {
> > > > > vfio_spapr_pci_eeh_release(vdev->pdev);
> > > > > vfio_pci_disable(vdev);
> > > > > + if (vdev->mediate_ops && vdev->mediate_ops->release) {
> > > > > +
> > > > > vdev->mediate_ops->release(vdev->mediate_handle);
> > > > > + vdev->mediate_ops = NULL;
> > > > > + }
> > > > > }
> > > > >
> > > > > mutex_unlock(&vdev->reflck->lock);
> > > > > @@ -483,6 +495,7 @@ static int vfio_pci_op
Re: [PATCH v1 00/36] Add RISC-V Hypervisor Extension v0.5
On Mon, Dec 9, 2019 at 2:55 PM Aleksandar Markovic wrote: > > > > On Monday, December 9, 2019, Alistair Francis > wrote: >> >> This patch series adds the RISC-V Hypervisor extension v0.5. This is the >> latest draft spec of the Hypervisor extension. >> > > Hi, Alistair, > > I have a question for you: > > Let's say this series is accepted. And let's say, next year, the draft spec > of RISC-V Hypervisor extension v0.6 is released, and you or somebody else > comes up with series on QEMU support for it, and that series is accepted too. > What would happen afterwards: > > A. Both support for v0.5 and v0.6 would continue to coexist perpetually > > B. Support for v0.5 would be deprecated according to QEMU deprecation rules, > and in two cycle would disappear > > C. Support for v0.5 would abruptly stop existing My current plan is to upgrade the implementation to the next version and drop v0.5 when a new spec release. happens. The justification for this is that the Hypervisor is a draft extension, disabled by default and marked as experimental. Therefore I think it's ok to just support the latest version of the spec. Alistair > > D. Something else > > ? > > Thanks, > Aleksandar > > >> >> The Hypervisor extension is disabled by default, so this series should >> result in no changes to anyone using QEMU unless they enable the >> extension. The extention can be enabled with the -cpu property (see >> below). >> >> Testing of this implementation has been done by using the baremetal >> Xvisor Hypervisor. We are able to run two Linux guests (that's all I >> have tried) as guests in 64-bit. In 32-bit so far I can only run >> baremetal guests, but I think this is a baremetal boot loader issue and >> not an issue in QEMU. >> >> The RISC-V KVM implementation was also written using these patches. The >> KVM implementation is currently under review. >> >> At the moment this spec is in a draft state and is subject to change. As >> QEMU is extreamly useful in early bring up I think it makes sense for >> QEMU to support non-frozen extensions. >> >> Thanks to Anup for doing the initial port of Xvisor. The port is avaliable >> here: >> https://github.com/avpatel/xvisor-next and will run on QEMU. >> >> Also thanks to Atish for implementing the SBI call support in Xvisor and >> for lots of help debugging. >> >> To run this yourself: >> 1. Apply this patch series to QEMU. The latest branch can be found here: >> >> https://github.com/alistair23/qemu/tree/mainline/alistair/riscv-hyp-ext-v0.5.next >> 2. Get the version of OpenSBI that supports the H extension. This can >> be found here: >> https://github.com/avpatel/opensbi/tree/riscv_hyp_ext_0_5_v1 >> 3. Build the next release of Xvisor. It is available here: >> https://github.com/avpatel/xvisor-next >> 4. Make sure you build the Xvisor tests, see here for details: >> >> https://github.com/avpatel/xvisor-next/tree/master/tests/riscv/virt64/linux >> 5. Run QEMU: >> ./riscv64-softmmu/qemu-system-riscv64 -nographic \ >>-machine virt -cpu rv64,x-h=true \ >>-serial mon:stdio -serial null -m 4G \ >>-device loader,file=vmm.bin,addr=0x8020 \ >>-kernel fw_jump.elf \ >>-initrd vmm-disk-linux.img \ >>-append "vmm.console=uart@1000 vmm.bootcmd=\"vfs mount initrd >> /;vfs run /boot.xscript;vfs cat /system/banner.txt\"" >> >>Once you get to the prompt you can start the geust by running: >> guest kick guest0 >>You can then bind to the serial port using: >> vserial bind guest0/uart0 >>Then you can start Linux using: >> autoexec >> >> This was all tested with the mainline 5.2/5.3 kernels. >> >> There is very early work on a Xen port as well which is avaliable here: >> https://github.com/alistair23/xen/tree/alistair/riscv-port >> >> ToDo/Issues >> - Get 32-bit fully working >> >> >> >> Alistair Francis (36): >> target/riscv: Convert MIP CSR to target_ulong >> target/riscv: Don't set write permissions on dirty PTEs >> target/riscv: Add the Hypervisor extension >> target/riscv: Add the Hypervisor CSRs to CPUState >> target/riscv: Add support for the new execption numbers >> target/riscv: Rename the H irqs to VS irqs >> target/riscv: Add the virtulisation mode >> target/riscv: Add the force HS exception mode >> target/riscv: Fix CSR perm checking for HS mode >> target/riscv: Print priv and virt in disas log >> target/riscv: Dump Hypervisor registers if enabled >> target/riscv: Add Hypervisor CSR access functions >> target/riscv: Add Hypervisor virtual CSRs accesses >> target/riscv: Add Hypervisor virtual CSRs accesses >> target/riscv: Convert mstatus to pointers >> target/riscv: Add virtual register swapping function >> target/riscv: Set VS bits in mideleg for Hyp extension >> target/riscv: Extend the MIE CSR to support virtulisation >> target/riscv: Extend the SIP CSR to support virtulisation >> target/riscv: Add support for virtual
Re: [PATCH v2 2/2] s390x/cpumodel: Introduce dynamic feature groups
On Thu, Dec 05, 2019 at 03:48:47PM +0100, David Hildenbrand wrote:
> On 05.12.19 15:35, Eduardo Habkost wrote:
> > On Mon, Dec 02, 2019 at 10:15:12AM +0100, David Hildenbrand wrote:
> >>
> Say the user has the option to select a model (zEC12, z13, z14), upper
> layers always want to have a model that includes all backported security
> features. While the host model can do that, CPU definitions can't. You
> can't change default models within a QEMU release, or for older releases
> (e.g., a z13).
>
> >>>
> >>> This is a good description of the main use case we're worried
> >>> about in x86 too, and the main reason we have added versioned CPU
> >>> models.
> >>>
> >>> I remember I was planning to use `query-cpu-model-expansion` for
> >>> "please give me the best configuration for this specific CPU
> >>> model" (which would be very similar to the approach used in this
> >>> series). Now, I need to refresh my memory and try to remember
> >>> why I concluded this approach wouldn't work for x86.
> >>
> >> I would be interested in that - I don't really think exposing CPU
> >> versions to the user is necessary here.
> >>
> >> E.g., you can maintain the versions internally and enable the stored
> >> features of the fitting one with "recommended-features=on...".
> >
> > I was re-reading some code and threads, and now I remember: the
> > main obstacle for using query-cpu-model-expansion for CPU model
> > version resolution in x86 is the fact that the x86 CPU models
> > aren't static yet. (type=full expansion isn't useful for CPU the
> > use case above; type=static expansion requires static CPU models
> > to be useful)
>
>
> I think, you could if you would expand "best X" to something like
>
> -cpu X,all-features=off,featX=on,featY=on ...
>
> The "all-features" part would need a better name as discussed. Such a
> model would always have a defined feature set (all listed features) ==
> static. The list could get a little longer, which is why s390x has these
> static "base" features. But that's not a road blocker.
>
> >
> > I was planning to make x86 CPU models static, then I noticed we
> > do have lots of feature flags that depend on the current
> > accelerator (set by kvm_default_props) or current machine (set
> > by compat_props). This breaks the rules for static CPU models.
>
> The static models we have (e.g., z13-base) contain a minimum set of
> features we expect to be around in every environment (but doesn't have
> to). It's just a way to make the featX=on,featY=on ... list shorter.
>
> X would be expanded to e.g.,
>
> -cpu X-base,featX=on,featY=on ...
>
> But nothing speaks against having
>
> -cpu X-base,featX=off,featY=on ...
>
> A very simplistic base model would be a model without any features.
> (like -cpu X,all-features=off), but then it would be set in stone.
x86 has only one static CPU model, called "base", just to make
type=static expansion work. Having multiple "-base" CPU
models would help make the extra feature list shorter, yes.
But we would still need to decide how to handle the
accel-specific code in x86_cpu_load_model(), including:
* kvm_default_props/tcg_default_props;
* x2apic special case for !kvm_irqchip_in_kernel();
* host vendor ID special case for KVM.
If we include that in static expansion, it would be a large
number of user-visible side effects for something that was
supposed to just add/remove a tiny set of CPU features to an
existing configuration. If we don't, we are breaking the rules
of static expansion (aren't we?).
We can still try to address this and make
"query-cpu-model-expansion type=static ...,recommended-features=on"
work on x86, and see it is usable by libvirt in x86. I'm just
worried that the interface may become complex, easy to get wrong,
and hard to validate until full libvirt support is implemented.
query-cpu-model-expansion is very extensible and flexible, but
hard to explain and reason about.
>
> >
> > We can still try to provide useful static CPU models in x86 in
> > the future (I want to). But I don't want to make this an
> > obstacle for providing a CPU model update mechanism that works
> > for x86 (which is more urgent).
> >
> >>
> >>>
> >>>
> >
> > Maybe its just the interface or the name. But I find this very
> > non-intuitive
>
> I'm open for suggestions.
>
> >
> > e.g. you wrote
> >
> > Get the maximum possible feature set (e.g., including deprecated
> > features) for a CPU definition in the configuration ("everything
> > that
> > could be enabled"):
> > -cpu z14,all-features=off,available-features=on
> >
> > Get all valid features for a CPU definition:
> > -cpu z14,all-features=on
> >
> > What is the point of this? It is either the same as the one before, or
> > it wont
> > be able to start.
>
> valid != available, all != available. Yes, the model won't run unless
>
Re: [PATCH] hw/core: Fix data type in do_nmi()
On 12/9/19 9:55 PM, Greg Kurz wrote:
On Mon, 9 Dec 2019 20:12:09 +1100
Gavin Shan wrote:
On 12/9/19 7:36 PM, Greg Kurz wrote:
On Sun, 8 Dec 2019 00:14:00 +1100
Gavin Shan wrote:
On 12/7/19 3:50 AM, Greg Kurz wrote:
On Fri, 6 Dec 2019 17:36:42 +1100
Gavin Shan wrote:
object_dynamic_cast() should return machine (or GPIO) state instad of NMI
state in do_nmi(). So it's wrong to convert it to NMI state unconditionally.
object_dynamic_cast() returns either its first argument if it can be cast
to the given typename or NULL. Since the x86, ccw and spapr machines and
the PowerMac GPIO implement the NMI interface, nothing is wrong here.
The do_nmi() function is called for all objects in the QOM tree and simply
filters out the ones that don't implement the NMI interface.
I do agree that this isn't super obvious though. It would be clearer to
do the filtering in the foreach() function. Something like:
https://patchwork.ozlabs.org/patch/1182232/
Greg, Thanks for the review and comments. I think we're talking about
different issues. I do agree it's worthy to simplify the code with the
object_child_foreach_type(), but later.
When we have below parameters to qemu, object_dynamic_cast(o, TYPE_NMI)
returns object of "pc-q35-4.2-machine", which is passed to the subquent
NMIClass::nmi_monitor_handler(). However, the function expects a NMIState
from its prototype as below. This patch changes the prototype to fill the
gap.
void (*nmi_monitor_handler)(NMIState *n, int cpu_index, Error **errp);
Hmm... the "pc-q35-4.2-machine" type inherits from the TYPE_PC_MACHINE,
which in turns inherits from TYPE_X86_MACHINE, which implements the
TYPE_NMI interface. It thus seems okay to pass this object to x86_nmi().
What are you trying to fix here ?
There is no valid instance associated with interface class. For this specific
case, there is no NMIState instance. I don't understand how we can pass a
valid NMIState to the function.
Ah I get it. Please read the include/qom/object.h to understand what QOM
interfaces are about. Especially this paragraph:
* # Interfaces #
*
* Interfaces allow a limited form of multiple inheritance. Instances are
* similar to normal types except for the fact that are only defined by
* their classes and never carry any state. You can dynamically cast an object
* to one of its #Interface types and vice versa.
Thanks, Greg. The statements here clarify the forced conversion (casting) is
allowed, even I don't think it's safe to do so.
Furthermore, below code returns "pc-q35-4.2-machine"
object instead of NMIState. It's not safe to do the forced conversion here.
/* It returns "pc-q35-4.2-machine" instance */
NMIState *n = (NMIState *) object_dynamic_cast(o, TYPE_NMI);
:
nc->nmi_monitor_handler(n, ns->cpu_index, &ns->err);
As explained in my previous mail, this _forced conversion_ is the current
way to implement object_child_foreach_type(). It is ugly and confusing for
newcomers but it is safe since the pointer is either TYPE_NMI or NULL, in
which case the handler isn't called.
Yes, as above statements said.
If "struct NMIState" is declared and the data struct is written in the function.
We will run into data corruption if I'm correct.
The 'struct NMIState' isn't defined on purpose, but I agree this isn't
documented
anywhere except in this changelog:
commit 00ed3da9b5c2e66e796a172df3e19545462b9c90
Author: David Gibson
Date: Tue Sep 24 16:00:33 2019 +1000
xics: Minor fixes for XICSFabric interface
Interface instances should never be directly dereferenced. So, the common
practice is to make them incomplete types to make sure no-one does that.
XICSFrabric, however, had a dummy type which is less safe.
We were also using OBJECT_CHECK() where we should have been using
INTERFACE_CHECK().
Signed-off-by: David Gibson
Reviewed-by: Greg Kurz
Reviewed-by: Cédric Le Goater
Maybe the NMIState naming was a poor choice since there's no associated
state with QOM interfaces. But we do want to keep a typedef though: it
is more precise and hence safer to pass an NMIState * than an Object *.>
It's arguable to be correct enough. The NMIClass and the associated callback
(nmi_monitor_handler()) are attached to the parent class, which is
"pc-q35-4.2-machine"
in our example. The interface is strongly associated with the parent class. From
this perspective, it also makes sense to pass the parent object.
However, we didn't run into any issue so far. Maybe the code can be revisited
when it needs to be improved later, or never :)
I'm pasting the message I had. Hope this helps for understanding the issue:
--- a/hw/core/nmi.c
+++ b/hw/core/nmi.c
@@ -42,6 +42,10 @@ static int do_nmi(Object *o, void *opaque)
if (n) {
NMIClass *nc = NMI_GET_CLASS(n);
+ fprintf(stdout, "%s: o=%s, n=%s\n",
+__func__, object_get_typename(OBJECT(o)),
+
Re: [PATCH v2 00/18] Complete the implementation of -accel
Patchew URL:
https://patchew.org/QEMU/1575903705-12925-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v2 00/18] Complete the implementation of -accel
Type: series
Message-id: 1575903705-12925-1-git-send-email-pbonz...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Switched to a new branch 'test'
fabb8b3 kvm: convert "-machine kernel_irqchip" to an accelerator property
6a1dbee kvm: introduce kvm_kernel_irqchip_* functions
800c958 kvm: convert "-machine kvm_shadow_mem" to an accelerator property
d72d3ea xen: convert "-machine igd-passthru" to an accelerator property
24067b2 tcg: add "-accel tcg, tb-size" and deprecate "-tb-size"
8b42a7e tcg: convert "-accel threads" to a QOM property
3ebd51d accel: pass object to accel_init_machine
4351594 qom: add object_new_with_class
314fb80 qom: introduce object_register_sugar_prop
0995654 vl: warn for unavailable accelerators, clarify messages
5c7b904 vl: configure accelerators from -accel options
6a4da93 vl: introduce object_parse_property_opt
a4b9880 accel: compile accel/accel.c just once
62cdc79 vl: merge -accel processing into configure_accelerators
6246357 vl: extract accelerator option processing to a separate function
63877b9 tcg: move qemu_tcg_configure to accel/tcg/tcg-all.c
1bd01e6 vl: move icount configuration earlier
86d414d memory: do not look at current_machine->accel
=== OUTPUT BEGIN ===
1/18 Checking commit 86d414d86513 (memory: do not look at
current_machine->accel)
2/18 Checking commit 1bd01e62ccaf (vl: move icount configuration earlier)
3/18 Checking commit 63877b94ad15 (tcg: move qemu_tcg_configure to
accel/tcg/tcg-all.c)
4/18 Checking commit 62463579c28f (vl: extract accelerator option processing to
a separate function)
5/18 Checking commit 62cdc7986f89 (vl: merge -accel processing into
configure_accelerators)
6/18 Checking commit a4b98800e6a2 (accel: compile accel/accel.c just once)
7/18 Checking commit 6a4da93b15b0 (vl: introduce object_parse_property_opt)
8/18 Checking commit 5c7b904bf344 (vl: configure accelerators from -accel
options)
WARNING: line over 80 characters
#206: FILE: vl.c:2909:
+error_report("The -accel and \"-machine accel=\" options are
incompatible");
WARNING: line over 80 characters
#214: FILE: vl.c:2915:
+ do_configure_accelerator, &init_failed,
&error_fatal)) {
total: 0 errors, 2 warnings, 196 lines checked
Patch 8/18 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/18 Checking commit 099565450487 (vl: warn for unavailable accelerators,
clarify messages)
10/18 Checking commit 314fb80d9a2c (qom: introduce object_register_sugar_prop)
WARNING: line over 80 characters
#24: FILE: include/qom/object.h:682:
+void object_register_sugar_prop(const char *driver, const char *prop, const
char *value);
WARNING: line over 80 characters
#48: FILE: qom/object.c:428:
+void object_register_sugar_prop(const char *driver, const char *prop, const
char *value)
total: 0 errors, 2 warnings, 61 lines checked
Patch 10/18 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
11/18 Checking commit 4351594192c0 (qom: add object_new_with_class)
WARNING: line over 80 characters
#142: FILE: vl.c:3992:
+current_machine =
MACHINE(object_new_with_class(OBJECT_CLASS(machine_class)));
total: 0 errors, 1 warnings, 96 lines checked
Patch 11/18 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
12/18 Checking commit 3ebd51dc3893 (accel: pass object to accel_init_machine)
13/18 Checking commit 8b42a7e25f3f (tcg: convert "-accel threads" to a QOM
property)
14/18 Checking commit 24067b2d77d6 (tcg: add "-accel tcg, tb-size" and
deprecate "-tb-size")
ERROR: line over 90 characters
#189: FILE: vl.c:3750:
+warn_report("The -tb-size option is deprecated, use -accel
tcg,tb-size instead");
WARNING: line over 80 characters
#190: FILE: vl.c:3751:
+object_register_sugar_prop(ACCEL_CLASS_NAME("tcg"), "tb-size",
optarg);
total: 1 errors, 1 warnings, 148 lines checked
Patch 14/18 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
15/18 Checking commit d72d3ea5e7e4 (xen: convert "-machine igd-passthru" to an
accelerator property)
16/18 Checking commit 800c95819ba7 (kvm: convert "-machine kvm_shadow_mem" to
an accelerator property)
WARNING: line over 80 characters
#228: FILE: target/i386/kvm.c:
Re: [PATCH v1 00/36] Add RISC-V Hypervisor Extension v0.5
On Monday, December 9, 2019, Alistair Francis wrote: > This patch series adds the RISC-V Hypervisor extension v0.5. This is the > latest draft spec of the Hypervisor extension. > > Hi, Alistair, I have a question for you: Let's say this series is accepted. And let's say, next year, the draft spec of RISC-V Hypervisor extension v0.6 is released, and you or somebody else comes up with series on QEMU support for it, and that series is accepted too. What would happen afterwards: A. Both support for v0.5 and v0.6 would continue to coexist perpetually B. Support for v0.5 would be deprecated according to QEMU deprecation rules, and in two cycle would disappear C. Support for v0.5 would abruptly stop existing D. Something else ? Thanks, Aleksandar > The Hypervisor extension is disabled by default, so this series should > result in no changes to anyone using QEMU unless they enable the > extension. The extention can be enabled with the -cpu property (see > below). > > Testing of this implementation has been done by using the baremetal > Xvisor Hypervisor. We are able to run two Linux guests (that's all I > have tried) as guests in 64-bit. In 32-bit so far I can only run > baremetal guests, but I think this is a baremetal boot loader issue and > not an issue in QEMU. > > The RISC-V KVM implementation was also written using these patches. The > KVM implementation is currently under review. > > At the moment this spec is in a draft state and is subject to change. As > QEMU is extreamly useful in early bring up I think it makes sense for > QEMU to support non-frozen extensions. > > Thanks to Anup for doing the initial port of Xvisor. The port is avaliable > here: > https://github.com/avpatel/xvisor-next and will run on QEMU. > > Also thanks to Atish for implementing the SBI call support in Xvisor and > for lots of help debugging. > > To run this yourself: > 1. Apply this patch series to QEMU. The latest branch can be found here: > https://github.com/alistair23/qemu/tree/mainline/alistair/ > riscv-hyp-ext-v0.5.next > 2. Get the version of OpenSBI that supports the H extension. This can > be found here: > https://github.com/avpatel/opensbi/tree/riscv_hyp_ext_0_5_v1 > 3. Build the next release of Xvisor. It is available here: > https://github.com/avpatel/xvisor-next > 4. Make sure you build the Xvisor tests, see here for details: > https://github.com/avpatel/xvisor-next/tree/master/tests/ > riscv/virt64/linux > 5. Run QEMU: > ./riscv64-softmmu/qemu-system-riscv64 -nographic \ >-machine virt -cpu rv64,x-h=true \ >-serial mon:stdio -serial null -m 4G \ >-device loader,file=vmm.bin,addr=0x8020 \ >-kernel fw_jump.elf \ >-initrd vmm-disk-linux.img \ >-append "vmm.console=uart@1000 vmm.bootcmd=\"vfs mount initrd > /;vfs run /boot.xscript;vfs cat /system/banner.txt\"" > >Once you get to the prompt you can start the geust by running: > guest kick guest0 >You can then bind to the serial port using: > vserial bind guest0/uart0 >Then you can start Linux using: > autoexec > > This was all tested with the mainline 5.2/5.3 kernels. > > There is very early work on a Xen port as well which is avaliable here: > https://github.com/alistair23/xen/tree/alistair/riscv-port > > ToDo/Issues > - Get 32-bit fully working > > > > Alistair Francis (36): > target/riscv: Convert MIP CSR to target_ulong > target/riscv: Don't set write permissions on dirty PTEs > target/riscv: Add the Hypervisor extension > target/riscv: Add the Hypervisor CSRs to CPUState > target/riscv: Add support for the new execption numbers > target/riscv: Rename the H irqs to VS irqs > target/riscv: Add the virtulisation mode > target/riscv: Add the force HS exception mode > target/riscv: Fix CSR perm checking for HS mode > target/riscv: Print priv and virt in disas log > target/riscv: Dump Hypervisor registers if enabled > target/riscv: Add Hypervisor CSR access functions > target/riscv: Add Hypervisor virtual CSRs accesses > target/riscv: Add Hypervisor virtual CSRs accesses > target/riscv: Convert mstatus to pointers > target/riscv: Add virtual register swapping function > target/riscv: Set VS bits in mideleg for Hyp extension > target/riscv: Extend the MIE CSR to support virtulisation > target/riscv: Extend the SIP CSR to support virtulisation > target/riscv: Add support for virtual interrupt setting > target/ricsv: Flush the TLB on virtulisation mode changes > target/riscv: Generate illegal instruction on WFI when V=1 > target/riscv: Add hypvervisor trap support > target/riscv: Add Hypervisor trap return support > target/riscv: Add hfence instructions > target/riscv: Remove the hret instruction > target/riscv: Disable guest FP support based on virtual status > target/riscv: Mark both sstatus and vsstatus as dirty > target/riscv: Respect MPRV and SPRV for floating point ops > target
Re: [PATCH v2 00/18] Complete the implementation of -accel
Patchew URL: https://patchew.org/QEMU/1575903705-12925-1-git-send-email-pbonz...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === CC migration/fd.o CC migration/exec.o /tmp/qemu-test/src/hw/xen/xen-common.c: In function 'xen_get_igd_gfx_passthru': /tmp/qemu-test/src/hw/xen/xen-common.c:129:12: error: 'has_igd_gfx_passthru' undeclared (first use in this function) return has_igd_gfx_passthru; ^ /tmp/qemu-test/src/hw/xen/xen-common.c:129:12: note: each undeclared identifier is reported only once for each function it appears in /tmp/qemu-test/src/hw/xen/xen-common.c: In function 'xen_set_igd_gfx_passthru': /tmp/qemu-test/src/hw/xen/xen-common.c:134:5: error: 'has_igd_gfx_passthru' undeclared (first use in this function) has_igd_gfx_passthru = value; ^ /tmp/qemu-test/src/hw/xen/xen-common.c: In function 'xen_accel_class_init': /tmp/qemu-test/src/hw/xen/xen-common.c:193:10: error: 'error_abort' undeclared (first use in this function) &error_abort); ^ make: *** [hw/xen/xen-common.o] Error 1 make: *** Waiting for unfinished jobs Traceback (most recent call last): File "./tests/docker/docker.py", line 662, in --- raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=4ff14485a3e34faa8e0fe7af9be44271', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-vvzmvig_/src/docker-src.2019-12-09-17.39.39.16043:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2. filter=--filter=label=com.qemu.instance.uuid=4ff14485a3e34faa8e0fe7af9be44271 make[1]: *** [docker-run] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-vvzmvig_/src' make: *** [docker-run-test-quick@centos7] Error 2 real2m51.895s user0m7.919s The full log is available at http://patchew.org/logs/1575903705-12925-1-git-send-email-pbonz...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH v2 1/2] usb-host: remove 'remote wakeup' flag from configuration descriptor
On Tue, Dec 03, 2019 at 09:07:15PM +0200, Yuri Benditovich wrote:
> If the redirected device has this capability, Windows guest may
> place the device into D2 and expect it to wake when the device
> becomes active, but this will never happen. For example, when
> internal Bluetooth adapter is redirected, keyboards and mice
> connected to it do not work. Current commit removes this
> capability (starting from machine 4.2)
> Set 'usb-host.suppress-remote-wake' property to 'off' to keep
> 'remote wake' as is or to 'on' to remove 'remote wake' on
> 4.1 or earlier.
>
> Signed-off-by: Yuri Benditovich
> ---
> hw/core/machine.c| 1 +
> hw/usb/host-libusb.c | 20
> hw/usb/trace-events | 1 +
> 3 files changed, 22 insertions(+)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 1689ad3bf8..8c0eaad091 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -29,6 +29,7 @@
>
> GlobalProperty hw_compat_4_1[] = {
> { "virtio-pci", "x-pcie-flr-init", "off" },
> +{ "usb-host", "suppress-remote-wake", "off" },
> };
> const size_t hw_compat_4_1_len = G_N_ELEMENTS(hw_compat_4_1);
In case this doesn't get merged in QEMU 4.2.0, the patch needs to
be updated to change hw_compat_4_2 instead (after applying the
5.0 machine type patch[1]).
[1] https://patchew.org/QEMU/20191112104811.30323-1-coh...@redhat.com/
--
Eduardo
Re: [PATCH 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine
On Friday, December 6, 2019, Peter Maydell wrote: > On Tue, 3 Dec 2019 at 19:32, Niek Linnenbank > wrote: > > Indeed that sounds like an interesting combination. Are there plans to > build a multi-arch/single-binary QEMU? > > This is in the category of "it would be nice in theory to > support multi-arch guest machines, and we've made some > small steps in that direction and/or tried to keep the > door open for it when designing things, but it would > still be a huge amount of work to actually implement, > so don't hold your breath for it or make anything else > depend on having it happen first"... > > Peter, This is one of the longest definitions of a category (in fact, most likely, the longest) that I have heard in my life. ;)) Aleksandar > thanks > -- PMM > >
Re: [bugfix ping2] Re: [PATCH v2 0/2] fix qcow2_can_store_new_dirty_bitmap
On 12/9/19 11:58 AM, Max Reitz wrote: On 09.12.19 17:30, Max Reitz wrote: On 02.12.19 15:09, Vladimir Sementsov-Ogievskiy wrote: Hi again! Still forgotten bug-fix :( Is it too late for 4.2? Sorry. :-/ Yes, I think I just forgot it. I don’t think it’s too important for 4.2, so, well, it isn’t too bad, but... Sorry. I can't imagine better test, and it tests exactly what written in https://bugzilla.redhat.com/show_bug.cgi?id=1712636 (Hmm, actually, I doubt that it is real use-case, more probably it's a bug in management layer) So, take this with test or without test, to 4.2 or 5.0. I was thinking of seeing whether I could write a quicker test, but of course we should take the patch either way. OK, I give up. It’s very much possible to create an image with 65535 bitmaps very quickly (like, under a second) outside of qemu, but just opening it takes 2:30 min (because of the quadratic complexity of checking whether a bitmap of the same name already exists). Can we fix that to use a hash table for amortized O(1) lookup rather than the current O(n) lookup? But such a fix is 5.0 material. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [PATCH for 4.2-rc5 1/1] block/qcow2-bitmap: fix crash bug in qcow2_co_remove_persistent_dirty_bitmap
On 12/9/19 11:03 AM, John Snow wrote: Did you mean to mark this as [PULL] ? Probably - that's the curse of hand-editing a mail sent in-reply-to the cover letter after the fact, instead of sending a v2 of the overall pull request. At any rate, the correct commit made it in (f56281abd9). On 12/9/19 11:16 AM, Eric Blake wrote: From: Vladimir Sementsov-Ogievskiy Here is double bug: -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [PATCH 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine
Hi Philippe, On Tue, Dec 3, 2019 at 9:47 AM Philippe Mathieu-Daudé wrote: > On 12/2/19 10:09 PM, Niek Linnenbank wrote: > > Dear QEMU developers, > > > > Hereby I would like to contribute the following set of patches to QEMU > > which add support for the Allwinner H3 System on Chip and the > > Orange Pi PC machine. The following features and devices are supported: > > > > * SMP (Quad Core Cortex A7) > > * Generic Interrupt Controller configuration > > * SRAM mappings > > * Timer device (re-used from Allwinner A10) > > * UART > > * SD/MMC storage controller > > * EMAC ethernet connectivity > > * USB 2.0 interfaces > > * Clock Control Unit > > * System Control module > > * Security Identifier device > > Awesome! > > > Functionality related to graphical output such as HDMI, GPU, > > Display Engine and audio are not included. Recently released > > mainline Linux kernels (4.19 up to latest master) and mainline U-Boot > > are known to work. The SD/MMC code is tested using bonnie++ and > > various tools such as fsck, dd and fdisk. The EMAC is verified with > iperf3 > > using -netdev socket. > > > > To build a Linux mainline kernel that can be booted by the Orange Pi PC > > machine, simply configure the kernel using the sunxi_defconfig > configuration: > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make mrproper > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make sunxi_defconfig > > > > To be able to use USB storage, you need to manually enable the > corresponding > > configuration item. Start the kconfig configuration tool: > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make menuconfig > > > > Navigate to the following item, enable it and save your configuration: > > Device Drivers > USB support > USB Mass Storage support > > > > Build the Linux kernel with: > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j5 > > > > To boot the newly build linux kernel in QEMU with the Orange Pi PC > machine, use: > > $ qemu-system-arm -M orangepi -m 512 -nic user -nographic \ > > -kernel /path/to/linux/arch/arm/boot/zImage \ > > -append 'console=ttyS0,115200' \ > > -dtb /path/to/linux/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dtb > > > > Note that this kernel does not have a root filesystem. You may provide it > > with an official Orange Pi PC image [1] either as an SD card or as > > USB mass storage. To boot using the Orange Pi PC Debian image on SD card, > > simply add the -sd argument and provide the proper root= kernel > parameter: > > $ qemu-system-arm -M orangepi -m 512 -nic user -nographic \ > > -kernel /path/to/linux/arch/arm/boot/zImage \ > > -append 'console=ttyS0,115200 root=/dev/mmcblk0p2' \ > > -dtb /path/to/linux/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dtb \ > > -sd OrangePi_pc_debian_stretch_server_linux5.3.5_v1.0.img > > > > Alternatively, you can also choose to build and boot a recent buildroot > [2] > > using the orangepi_pc_defconfig or Armbian image [3] for Orange Pi PC. > > Richard, trying the Armbian image from > https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/ I get: > > $ arm-softmmu/qemu-system-arm -M orangepi -m 512 -nic user \ >-append 'console=ttyS0,115200' \ >-kernel boot/vmlinuz-4.20.7-sunxi \ >-dtb usr/lib/linux-image-dev-sunxi/sun8i-h3-orangepi-pc.dtb \ >-serial stdio -d unimp > Uncompressing Linux... done, booting the kernel. > rtc: unimplemented device write (size 4, value 0x16aa0001, offset 0x0) > rtc: unimplemented device read (size 4, offset 0x0) > rtc: unimplemented device read (size 4, offset 0x0) > rtc: unimplemented device read (size 4, offset 0x8) > qemu-system-arm: target/arm/helper.c:11359: cpu_get_tb_cpu_state: > Assertion `flags == rebuild_hflags_internal(env)' failed. > Aborted (core dumped) > I'm trying to reproduce the error you reported here with my patch set on latest master, but so far without any result. The host OS I'm using is Ubuntu 18.04.3 LTS on x86_64. I ran several times using the same 4.20.7-sunxi kernel and same command line. Some questions that might help: 1) Are there any specific steps you did in order to produce this error? 2) Could this be a known / existing issue? 3) How many times did you see this error? 4) Are you also using Ubuntu 18.04.3 LTS on x86_64, or a different host OS? Regards, Niek > > (gdb) bt > #0 0x7f6c1fa2ce35 in raise () at /lib64/libc.so.6 > #1 0x7f6c1fa17895 in abort () at /lib64/libc.so.6 > #2 0x7f6c1fa17769 in _nl_load_domain.cold () at /lib64/libc.so.6 > #3 0x7f6c1fa25566 in annobin_assert.c_end () at /lib64/libc.so.6 > #4 0x5590657e2685 in cpu_get_tb_cpu_state (env=0x5590686899b0, > pc=0x7f6c07ffa718, cs_base=0x7f6c07ffa714, pflags=0x7f6c07ffa71c) at > target/arm/helper.c:11359 > #5 0x55906569f962 in tb_lookup__cpu_state (cpu=0x5590686808b0, > pc=0x7f6c07ffa718, cs_base=0x7f6c07ffa714, flags=0x7f6c07ffa71c, > cf_mask=524288) at include/exec/tb-lookup.h:28 > #6 0x5590656a084c in tb_find (cpu=0x
Re: [PATCH v2] Adding support for MAC filtering in the FEC IP implementation.
On 07/12/2019 21:56, bilalwasim...@gmail.com wrote:
> From: Bilal Wasim
>
> This addition ensures that the IP does NOT boot up in
> promiscuous mode by default, and so the software only receives the desired
> packets(Unicast, Broadcast, Unicast / Multicast hashed) by default. The
> software running on-top of QEMU can also modify these settings and disable
> reception of broadcast frames or make the IP receive all packets (PROM mode).
> This patch greatly reduces the number of packets received by the software
> running on-top of the QEMU model. Tested with the armv7-a SABRE_LITE machine.
> Testing included running a custom OS with IPv4 / IPv6 support. Hashing and
> filtering of packets is tested to work well. Skeleton taken from the
> CADENCE_GEM IP and hash generation algorithm from the Linux Kernel.
>
> Signed-off-by: Bilal Wasim
> ---
> hw/net/imx_fec.c | 117 ++-
> include/hw/net/imx_fec.h | 12
> 2 files changed, 128 insertions(+), 1 deletion(-)
>
> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> index bd99236864..cc1572b5fe 100644
> --- a/hw/net/imx_fec.c
> +++ b/hw/net/imx_fec.c
> @@ -419,6 +419,87 @@ static void imx_enet_write_bd(IMXENETBufDesc *bd,
> dma_addr_t addr)
> dma_memory_write(&address_space_memory, addr, bd, sizeof(*bd));
> }
>
> +/*
> + * Calculate a FEC MAC Address hash index
> + */
> +static unsigned calc_mac_hash(const uint8_t *mac, uint8_t mac_length)
> +{
> +uint32_t crc = -1;
> +int i;
> +
> +while (mac_length--) {
> +crc ^= *mac++;
> +for (i = 0; i < 8; i++) {
> +crc = (crc >> 1) ^ ((crc & 1) ? CRCPOLY_LE : 0);
> +}
> +}
Can you not use the existing net_crc32_le() function here?
> +/*
> + * only upper 6 bits (FEC_HASH_BITS) are used
> + * which point to specific bit in the hash registers
> + */
> +return (crc >> (32 - FEC_HASH_BITS)) & 0x3f;
> +}
> +
> +/*
> + * fec_mac_address_filter:
> + * Accept or reject this destination address?
> + */
> +static int fec_mac_address_filter(IMXFECState *s, const uint8_t *packet)
> +{
> +const uint8_t broadcast_addr[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
> +uint32_t addr1, addr2;
> +uint8_t hash;
> +
> +/* Promiscuous mode? */
> +if (s->regs[ENET_RCR] & ENET_RCR_PROM) {
> +/* Accept all packets in promiscuous mode (even if bc_rej is set). */
> +return FEC_RX_PROMISCUOUS_ACCEPT;
> +}
> +
> +/* Broadcast packet? */
> +if (!memcmp(packet, broadcast_addr, 6)) {
> +/* Reject broadcast packets? */
> +if (s->regs[ENET_RCR] & ENET_RCR_BC_REJ) {
> +return FEC_RX_REJECT;
> +}
> +/* Accept packets from broadcast address. */
> +return FEC_RX_BROADCAST_ACCEPT;
> +}
> +
> +/* Accept packets -w- hash match? */
> +hash = calc_mac_hash(packet, 6);
> +
> +/* Accept packets -w- multicast hash match? */
> +if ((packet[0] & 0x01) == 0x01) {
> +/* Computed hash matches GAUR / GALR register ? */
> +if (((hash < 32) && (s->regs[ENET_GALR] & (1 << hash)))
> +|| ((hash > 31) && (s->regs[ENET_GAUR] & (1 << (hash -
> 32) {
> +/* Accept multicast hash enabled address. */
> +return FEC_RX_MULTICAST_HASH_ACCEPT;
> +}
> +} else {
> +/* Computed hash matches IAUR / IALR register ? */
> +if (((hash < 32) && (s->regs[ENET_IALR] & (1 << hash)))
> +|| ((hash > 31) && (s->regs[ENET_IAUR] & (1 << (hash -
> 32) {
> +/* Accept multicast hash enabled address. */
> +return FEC_RX_UNICAST_HASH_ACCEPT;
> +}
> +}
> +
> +/* Match Unicast address. */
> +addr1 = g_htonl(s->regs[ENET_PALR]);
> +addr2 = g_htonl(s->regs[ENET_PAUR]);
> +if (!(memcmp(packet, (uint8_t *) &addr1, 4) ||
> + memcmp(packet + 4, (uint8_t *) &addr2, 2))) {
> +/* Accept packet because it matches my unicast address. */
> +return FEC_RX_UNICAST_ACCEPT;
> +}
> +
> +/* Return -1 because we do NOT support MAC address filtering.. */
> +return FEC_RX_REJECT;
> +}
> +
> static void imx_eth_update(IMXFECState *s)
> {
> /*
> @@ -984,7 +1065,7 @@ static void imx_eth_write(void *opaque, hwaddr offset,
> uint64_t value,
> case ENET_IALR:
> case ENET_GAUR:
> case ENET_GALR:
> -/* TODO: implement MAC hash filtering. */
> +s->regs[index] |= value;
> break;
> case ENET_TFWR:
> if (s->is_fec) {
> @@ -1066,8 +1147,15 @@ static ssize_t imx_fec_receive(NetClientState *nc,
> const uint8_t *buf,
> uint32_t buf_addr;
> uint8_t *crc_ptr;
> unsigned int buf_len;
> +int maf;
> size_t size = len;
>
> +/* Is this destination MAC address "for us" ? */
> +maf = fec_mac_address_filter(s, buf);
> +if (maf == FEC_RX_REJECT) {
> +return FEC_RX_REJECT;
> +}
> +
> FEC_PRINTF("len %
Re: [RFC PATCH 4/9] vfio-pci: register default dynamic-trap-bar-info region
On Mon, 9 Dec 2019 01:22:12 -0500 Yan Zhao wrote: > On Fri, Dec 06, 2019 at 11:20:38PM +0800, Alex Williamson wrote: > > On Fri, 6 Dec 2019 01:04:07 -0500 > > Yan Zhao wrote: > > > > > On Fri, Dec 06, 2019 at 07:55:30AM +0800, Alex Williamson wrote: > > > > On Wed, 4 Dec 2019 22:26:50 -0500 > > > > Yan Zhao wrote: > > > > > > > > > Dynamic trap bar info region is a channel for QEMU and vendor driver > > > > > to > > > > > communicate dynamic trap info. It is of type > > > > > VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and subtype > > > > > VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO. > > > > > > > > > > This region has two fields: dt_fd and trap. > > > > > When QEMU detects a device regions of this type, it will create an > > > > > eventfd and write its eventfd id to dt_fd field. > > > > > When vendor drivre signals this eventfd, QEMU reads trap field of this > > > > > info region. > > > > > - If trap is true, QEMU would search the device's PCI BAR > > > > > regions and disable all the sparse mmaped subregions (if the sparse > > > > > mmaped subregion is disablable). > > > > > - If trap is false, QEMU would re-enable those subregions. > > > > > > > > > > A typical usage is > > > > > 1. vendor driver first cuts its bar 0 into several sections, all in a > > > > > sparse mmap array. So initally, all its bar 0 are passthroughed. > > > > > 2. vendor driver specifys part of bar 0 sections to be disablable. > > > > > 3. on migration starts, vendor driver signals dt_fd and set trap to > > > > > true > > > > > to notify QEMU disabling the bar 0 sections of disablable flags on. > > > > > 4. QEMU disables those bar 0 section and hence let vendor driver be > > > > > able > > > > > to trap access of bar 0 registers and make dirty page tracking > > > > > possible. > > > > > 5. on migration failure, vendor driver signals dt_fd to QEMU again. > > > > > QEMU reads trap field of this info region which is false and QEMU > > > > > re-passthrough the whole bar 0 region. > > > > > > > > > > Vendor driver specifies whether it supports dynamic-trap-bar-info > > > > > region > > > > > through cap VFIO_PCI_DEVICE_CAP_DYNAMIC_TRAP_BAR in > > > > > vfio_pci_mediate_ops->open(). > > > > > > > > > > If vfio-pci detects this cap, it will create a default > > > > > dynamic_trap_bar_info region on behalf of vendor driver with region > > > > > len=0 > > > > > and region->ops=null. > > > > > Vvendor driver should override this region's len, flags, rw, mmap in > > > > > its > > > > > vfio_pci_mediate_ops. > > > > > > > > TBH, I don't like this interface at all. Userspace doesn't pass data > > > > to the kernel via INFO ioctls. We have a SET_IRQS ioctl for > > > > configuring user signaling with eventfds. I think we only need to > > > > define an IRQ type that tells the user to re-evaluate the sparse mmap > > > > information for a region. The user would enumerate the device IRQs via > > > > GET_IRQ_INFO, find one of this type where the IRQ info would also > > > > indicate which region(s) should be re-evaluated on signaling. The user > > > > would enable that signaling via SET_IRQS and simply re-evaluate the > > > ok. I'll try to switch to this way. Thanks for this suggestion. > > > > > > > sparse mmap capability for the associated regions when signaled. > > > > > > Do you like the "disablable" flag of sparse mmap ? > > > I think it's a lightweight way for user to switch mmap state of a whole > > > region, > > > otherwise going through a complete flow of GET_REGION_INFO and re-setup > > > region might be too heavy. > > > > No, I don't like the disable-able flag. At what frequency do we expect > > regions to change? It seems like we'd only change when switching into > > and out of the _SAVING state, which is rare. It seems easy for > > userspace, at least QEMU, to drop the entire mmap configuration and > ok. I'll try this way. > > > re-read it. Another concern here is how do we synchronize the event? > > Are we assuming that this event would occur when a user switch to > > _SAVING mode on the device? That operation is synchronous, the device > > must be in saving mode after the write to device state completes, but > > it seems like this might be trying to add an asynchronous dependency. > > Will the write to device_state only complete once the user handles the > > eventfd? How would the kernel know when the mmap re-evaluation is > > complete. It seems like there are gaps here that the vendor driver > > could miss traps required for migration because the user hasn't > > completed the mmap transition yet. Thanks, > > > > Alex > > yes, this asynchronous event notification will cause vendor driver miss > traps. But it's supposed to be of very short period time. That's also a > reason for us to wish the re-evaluation to be lightweight. E.g. if it's > able to be finished before the first iterate, it's still safe. Making the re-evaluation lightweight cannot solve the race, it only masks it.
[PATCH] virtio: don't enable notifications during polling
Virtqueue notifications are not necessary during polling, so we disable
them. This allows the guest driver to avoid MMIO vmexits.
Unfortunately the virtio-blk and virtio-scsi handler functions re-enable
notifications, defeating this optimization.
Fix virtio-blk and virtio-scsi emulation so they leave notifications
disabled. The key thing to remember for correctness is that polling
always checks one last time after ending its loop, therefore it's safe
to lose the race when re-enabling notifications at the end of polling.
There is a measurable performance improvement of 5-10% with the null-co
block driver. Real-life storage configurations will see a smaller
improvement because the MMIO vmexit overhead contributes less to
latency.
Signed-off-by: Stefan Hajnoczi
---
hw/block/virtio-blk.c | 9 +++--
hw/scsi/virtio-scsi.c | 9 +++--
hw/virtio/virtio.c | 12 ++--
include/hw/virtio/virtio.h | 1 +
4 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 4c357d2928..c4e55fb3de 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -764,13 +764,16 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
{
VirtIOBlockReq *req;
MultiReqBuffer mrb = {};
+bool suppress_notifications = virtio_queue_get_notification(vq);
bool progress = false;
aio_context_acquire(blk_get_aio_context(s->blk));
blk_io_plug(s->blk);
do {
-virtio_queue_set_notification(vq, 0);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 0);
+}
while ((req = virtio_blk_get_request(s, vq))) {
progress = true;
@@ -781,7 +784,9 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
}
}
-virtio_queue_set_notification(vq, 1);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 1);
+}
} while (!virtio_queue_empty(vq));
if (mrb.num_reqs) {
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index e8b2b64d09..f080545f48 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -597,12 +597,15 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue
*vq)
{
VirtIOSCSIReq *req, *next;
int ret = 0;
+bool suppress_notifications = virtio_queue_get_notification(vq);
bool progress = false;
QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs);
do {
-virtio_queue_set_notification(vq, 0);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 0);
+}
while ((req = virtio_scsi_pop_req(s, vq))) {
progress = true;
@@ -622,7 +625,9 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq)
}
}
-virtio_queue_set_notification(vq, 1);
+if (suppress_notifications) {
+virtio_queue_set_notification(vq, 1);
+}
} while (ret != -EINVAL && !virtio_queue_empty(vq));
QTAILQ_FOREACH_SAFE(req, &reqs, next, next) {
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 762df12f4c..78e5852296 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -431,6 +431,11 @@ static void virtio_queue_packed_set_notification(VirtQueue
*vq, int enable)
}
}
+bool virtio_queue_get_notification(VirtQueue *vq)
+{
+return vq->notification;
+}
+
void virtio_queue_set_notification(VirtQueue *vq, int enable)
{
vq->notification = enable;
@@ -3382,17 +3387,12 @@ static bool virtio_queue_host_notifier_aio_poll(void
*opaque)
{
EventNotifier *n = opaque;
VirtQueue *vq = container_of(n, VirtQueue, host_notifier);
-bool progress;
if (!vq->vring.desc || virtio_queue_empty(vq)) {
return false;
}
-progress = virtio_queue_notify_aio_vq(vq);
-
-/* In case the handler function re-enabled notifications */
-virtio_queue_set_notification(vq, 0);
-return progress;
+return virtio_queue_notify_aio_vq(vq);
}
static void virtio_queue_host_notifier_aio_poll_end(EventNotifier *n)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 3448d67d2a..8ee93873a4 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -224,6 +224,7 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int
version_id);
void virtio_notify_config(VirtIODevice *vdev);
+bool virtio_queue_get_notification(VirtQueue *vq);
void virtio_queue_set_notification(VirtQueue *vq, int enable);
int virtio_queue_ready(VirtQueue *vq);
--
2.23.0
[ANNOUNCE] SeaBIOS 1.13.0
The 1.13.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Support for reading logical CHS drive information from QEMU * Workaround added for misbehaving optionroms that grab "int19" * The TPM 2 "PCR bank" option can now be set from the TPM menu * SeaVGABIOS support for QEMU "atiext" display * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download = git shortlog -n rel-1.12.0..rel-1.13.0 = Gerd Hoffmann (25): vga: move modelist from bochsvga.c to new svgamodes.c vga: make memcpy_high() public vga: add atiext driver vga: add ati bios tables vbe: add edid support. ati: add edid support. bochsvga: add edid support. bochsdisplay: add edid support. bochsdisplay: parse resolution from edid. add get_keystroke_full() helper bootmenu: add support for more than 9 entries optionrom: disallow int19 redirect for pnp roms. ati-vga: make less verbose ati-vga: fix ati_read() ati-vga: make i2c register and bits configurable ati-vga: try vga ddc first ati-vga: add rage128 edid support bochsdisplay: add copyright and license to bochsdisplay.c ramfb: add copyright and license to ramfb.c cp437: add license to cp437.c ahci: zero-initialize port struct Revert "geometry: Apply LCHS values for boot devices" Revert "config: Add toggle for bootdevice information" Revert "geometry: Add boot_lchs_find_*() utility functions" Revert "geometry: Read LCHS from fw_cfg" Kevin O'Connor (11): output: Avoid thunking to 16bit mode in printf() if no vgabios docs: Update mailing list archive links docs: Fix cut-and-paste error in Mailinglist.md archive link usb-ehci: Clear pipe token on pipe reallocate pciinit: Use %pP shorthand for printing device ids in intel_igd_setup() virtio-pci: Use %pP format in dprintf() calls Makefile: Build with -Wno-address-of-packed-member svgamodes: Add copyright notice to vgasrc/svgamodes.c docs: Add developer-certificate-of-origin docs: Note release date for v1.12.1 docs: Note v1.13.0 release Sam Eiderman (10): smbios: Add missing zero byte to Type 0 geometry: Read LCHS from fw_cfg boot: Reorder functions in boot.c geometry: Add boot_lchs_find_*() utility functions config: Add toggle for bootdevice information geometry: Apply LCHS values for boot devices geometry: Read LCHS from fw_cfg boot: Build ata and scsi paths in function geometry: Add boot_lchs_find_*() utility functions geometry: Apply LCHS values for boot devices Stefan Berger (4): tcgbios: Use table to convert hash to buffer size tcgbios: Implement TPM 2.0 menu item to activate and deactivate PCR banks tpm: Require a response to have minimum size of a valid response header tcgbios: Check for enough bytes returned from TPM2_GetCapability Uwe Kleine-König (3): cbvga: reuse svga modes definitions from svgamodes.c Add additional resolutions for 16:9 displays: 1600x900 and 2560x1440 Remove dos line endings introduced in the last two commits David Woodhouse (2): csm: Sanitise alignment constraint in Legacy16GetTableAddress csm: Fix boot priority translation Denis Plotnikov (1): virtio: extend virtio queue size to 256 Joseph Pacheco-Corwin (1): bootsplash: Added support for 16/24/32bpp in one function Liran Alon (1): pvscsi: ring_desc do not have to be page aligned Stefano Garzarella (1): qemu: avoid debug prints if debugcon is not enabled Stephen Douthit (1): tpm: Check for TPM related ACPI tables before attempting hw probe
Re: [for-5.0 PATCH] ppc: Make PPCVirtualHypervisor an incomplete type
On Mon, 9 Dec 2019 16:42:39 +
Peter Maydell wrote:
> On Mon, 9 Dec 2019 at 16:28, Greg Kurz wrote:
> >
> > On Mon, 9 Dec 2019 15:02:38 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> > > On 12/9/19 2:28 PM, Greg Kurz wrote:
> > > > PPCVirtualHypervisor is an interface instance. It should never be
> > > > dereferenced. Drop the dummy type definition for extra safety, which
> > > > is the common practice with QOM interfaces.
> > >
> > > This "common practice" is also referenced in commit 00ed3da9b5:
> > >
> > > xics: Minor fixes for XICSFabric interface
> > >
> > > Interface instances should never be directly dereferenced. So, the
> > > common
> > > practice is to make them incomplete types to make sure no-one does
> > > that.
> > > XICSFrabric, however, had a dummy type which is less safe.
> > >
> > > We were also using OBJECT_CHECK() where we should have been using
> > > INTERFACE_CHECK().
> > >
> > > This indeed follow the changes from commit aa1b35b975d8:
> > >
> > > qom: make interface types abstract
> > >
> > > Interfaces don't have instance, let's make the interface type really
> > > abstract to avoid confusion.
> > >
> > > Now I can't find guidelines for this. If you don't know about it and use
> > > 'git-grep', it is very confusing to see we use structures we never define.
> > >
> >
> > I agree that this deliberate usage of incomplete types isn't common.
> >
> > > Can we document this use please?
> > >
> >
> > Probably we could amend the related section in the object.h header file.
> > Something like:
> >
> > --- a/include/qom/object.h
> > +++ b/include/qom/object.h
> > @@ -200,8 +200,11 @@ typedef struct InterfaceInfo InterfaceInfo;
> > *
> > * Interfaces allow a limited form of multiple inheritance. Instances are
> > * similar to normal types except for the fact that are only defined by
> > - * their classes and never carry any state. You can dynamically cast an
> > object
> > - * to one of its #Interface types and vice versa.
> > + * their classes and never carry any state. As a consequence, a pointer to
> > + * an interface instance should always be of incomplete type in order to be
> > + * sure it cannot be dereferenced.
>
> It might be helpful to add here the concrete details of how to do that,
> so people don't have to look up what an incomplete type is:
>
> "That is, you should define the 'typedef struct SomethingIf SomethingIf'
> so that you can pass around 'SomethingIf *si' arguments, but not define
> a 'struct SomethingIf { ... }'. The only things you can validly do with
> a 'SomethingIf *' are to pass it as an argument to a method on its
> corresponding
> SomethingIfClass, or to dynamically cast the interface pointer to a pointer
> to the concrete object which is implementing the interface."
>
> ?
>
> > + * You can dynamically cast an object to one of its #Interface types and
> > vice
> > + * versa.
>
> ...though that last part is then kind of awkwardly similar to this sentence.
> There's probably better wording possible than what I suggest above.
>
What about ?
* Interfaces allow a limited form of multiple inheritance. Instances are
* similar to normal types except for the fact that are only defined by
- * their classes and never carry any state. You can dynamically cast an object
- * to one of its #Interface types and vice versa.
+ * their classes and never carry any state. As a consequence, a pointer to
+ * an interface instance should always be of incomplete type in order to be
+ * sure it cannot be dereferenced. That is, you should define the
+ * 'typedef struct SomethingIf SomethingIf' so that you can pass around
+ * 'SomethingIf *si' arguments, but not define a 'struct SomethingIf { ... }'.
+ * The only things you can validly do with a 'SomethingIf *' are to pass it as
+ * an argument to a method on its corresponding SomethingIfClass, or to
+ * dynamically cast it to an object that implements the interface.
> thanks
> -- PMM
Re: [for-5.0 PATCH v2 0/3] cpu: Clarify overloading of reset QOM methods
On Mon, 9 Dec 2019 19:21:43 +0100 Cornelia Huck wrote: > On Mon, 09 Dec 2019 18:55:12 +0100 > Greg Kurz wrote: > > > Each cpu subclass overloads the reset method of its parent class with > > its own. But since it needs to call the parent method as well, it keeps > > a parent_reset pointer to do so. This causes the same not very explicit > > boiler plate to be duplicated all around the place: > > > > pcc->parent_reset = cc->reset; > > cc->reset = ppc_cpu_reset; > > > > A similar concern was addressed some time back by Philippe Mathieu-Daudé > > in qdev, with the addition of device_class_set_parent_reset() and friends: > > > > https://git.qemu.org/?p=qemu.git;a=commit;h=46795cf2e2f6 > > https://git.qemu.org/?p=qemu.git;a=commit;h=bf853881690d > > > > Follow the same approach with cpus. > > > > Changes in v2: > > - added Reviewed-by and Acked-by tags > > - rebased on top of https://github.com/cohuck/qemu.git s390-next > > SHA1 dd6252f035a2 > > My apologies for the churn. I'll try to flush my queue ASAP after 5.0 > development opens. > No problems. It is perfectly fine to queue patches during freeze :) > > > > -- > > Greg > > > > --- > > > > Greg Kurz (3): > > cpu: Introduce CPUReset callback typedef > > cpu: Introduce cpu_class_set_parent_reset() > > cpu: Use cpu_class_set_parent_reset() > > > > > > hw/core/cpu.c |8 > > include/hw/core/cpu.h |8 +++- > > target/alpha/cpu-qom.h |2 +- > > target/arm/cpu-qom.h|2 +- > > target/arm/cpu.c|3 +-- > > target/cris/cpu-qom.h |2 +- > > target/cris/cpu.c |3 +-- > > target/hppa/cpu-qom.h |2 +- > > target/i386/cpu-qom.h |2 +- > > target/i386/cpu.c |3 +-- > > target/lm32/cpu-qom.h |2 +- > > target/lm32/cpu.c |3 +-- > > target/m68k/cpu-qom.h |2 +- > > target/m68k/cpu.c |3 +-- > > target/microblaze/cpu-qom.h |2 +- > > target/microblaze/cpu.c |3 +-- > > target/mips/cpu-qom.h |2 +- > > target/mips/cpu.c |3 +-- > > target/moxie/cpu.c |3 +-- > > target/moxie/cpu.h |2 +- > > target/nios2/cpu.c |3 +-- > > target/nios2/cpu.h |2 +- > > target/openrisc/cpu.c |3 +-- > > target/openrisc/cpu.h |2 +- > > target/ppc/cpu-qom.h|2 +- > > target/ppc/translate_init.inc.c |3 +-- > > target/riscv/cpu.c |3 +-- > > target/riscv/cpu.h |2 +- > > target/s390x/cpu-qom.h |2 +- > > target/s390x/cpu.c |3 +-- > > target/sh4/cpu-qom.h|2 +- > > target/sh4/cpu.c|3 +-- > > target/sparc/cpu-qom.h |2 +- > > target/sparc/cpu.c |3 +-- > > target/tilegx/cpu.c |3 +-- > > target/tilegx/cpu.h |2 +- > > target/tricore/cpu-qom.h|2 +- > > target/tricore/cpu.c|3 +-- > > target/xtensa/cpu-qom.h |2 +- > > target/xtensa/cpu.c |3 +-- > > 40 files changed, 53 insertions(+), 57 deletions(-) > > >
Re: [PATCH 2/2] Add -mem-shared option
+Markus On Tue, Dec 03, 2019 at 03:43:03PM +0100, Igor Mammedov wrote: > On Tue, 3 Dec 2019 09:56:15 +0100 > Thomas Huth wrote: > > > On 02/12/2019 22.00, Eduardo Habkost wrote: > > > On Mon, Dec 02, 2019 at 08:39:48AM +0100, Igor Mammedov wrote: > > >> On Fri, 29 Nov 2019 18:46:12 +0100 > > >> Paolo Bonzini wrote: > > >> > > >>> On 29/11/19 13:16, Igor Mammedov wrote: > > As for "-m", I'd make it just an alias that translates > > -m/mem-path/mem-prealloc > > >>> > > >>> I think we should just deprecate -mem-path/-mem-prealloc in 5.0. CCing > > >>> Thomas as mister deprecation. :) > > >> > > >> I'll add that to my series > > > > > > Considering that the plan is to eventually reimplement those > > > options as syntactic sugar for memory backend options (hopefully > > > in less than 2 QEMU releases), what's the point of deprecating > > > them? > > > > Well, it depends on the "classification" [1] of the parameter... > > > > Let's ask: What's the main purpose of the option? > > > > Is it easier to use than the "full" option, and thus likely to be used > > by a lot of people who run QEMU directly from the CLI? In that case it > > should stay as "convenience option" and not be deprecated. > > > > Or is the option merely there to give the upper layers like libvirt or > > some few users and their scripts some more grace period to adapt their > > code, but we all agree that the options are rather ugly and should > > finally go away? Then it's rather a "legacy option" and the deprecation > > process is the right way to go. Our QEMU interface is still way > > overcrowded, we should try to keep it as clean as possible. > > After switching to memdev for main RAM, users could use relatively > short global options > -global memory-backend.prealloc|share=on > and > -global memory-backend-file.mem-path=X|prealloc|share=on > > instead of us adding and maintaining slightly shorter > -mem-shared/-mem-path/-mem-prealloc Global properties are a convenient way to expose knobs through the command line with little effort, but we have no documentation on which QOM properties are really supposed to be touched by users using -global. Unless we fix the lack of documentation, I'd prefer to have syntactic sugar translated to -global instead of recommending direct usage of -global. -- Eduardo
Re: [PATCH for-5.0 v2 9/9] acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command
On 12/09/19 14:09, Igor Mammedov wrote:
> Firmware can enumerate present at boot APs by broadcasting wakeup IPI,
> so that woken up secondary CPUs could register them-selves.
> However in CPU hotplug case, it would need to know architecture
> specific CPU IDs for possible and hotplugged CPUs so it could
> prepare environment for and wake hotplugged AP.
>
> Reuse and extend existing CPU hotplug interface to return architecture
> specific ID for currently selected CPU in 2 registers:
> - lower 32 bits in ACPI_CPU_CMD_DATA_OFFSET_RW
> - upper 32 bits in ACPI_CPU_CMD_DATA2_OFFSET_R
>
> On x86, firmware will use CPHP_GET_CPU_ID_CMD for fetching the APIC ID
> when handling hotplug SMI.
>
> Later, CPHP_GET_CPU_ID_CMD will be used on ARM to retrieve MPIDR,
> which serves the similar to APIC ID purpose.
>
> Signed-off-by: Igor Mammedov
> ---
> v1:
> - s/ACPI_CPU_CMD_DATA2_OFFSET_RW/ACPI_CPU_CMD_DATA2_OFFSET_R/.
> v2:
> - ACPI_CPU_CMD_DATA2_OFFSET_R moved into separate patch
>that adds 'Command data 2' field separately
> - ammend commit message
> ---
> docs/specs/acpi_cpu_hotplug.txt | 3 +++
> hw/acpi/cpu.c | 7 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/docs/specs/acpi_cpu_hotplug.txt b/docs/specs/acpi_cpu_hotplug.txt
> index cb99cf3..a8ce5e7 100644
> --- a/docs/specs/acpi_cpu_hotplug.txt
> +++ b/docs/specs/acpi_cpu_hotplug.txt
> @@ -47,6 +47,7 @@ read access:
> [0x0-0x3] Command data 2: (DWORD access)
>if value last stored in 'Command field':
> 0: reads as 0x0
> +3: upper 32 bits of architecture specific CPU ID value
> other values: reserved
> [0x4] CPU device status fields: (1 byte access)
> bits:
> @@ -61,6 +62,8 @@ read access:
> [0x8] Command data: (DWORD access)
>contains 0 unless value last stored in 'Command field' is one of:
>0: contains 'CPU selector' value of a CPU with pending event[s]
> + 3: lower 32 bits of architecture specific CPU ID value
> + (in x86 case: APIC ID)
>
> write access:
> offset:
> diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
> index d475c06..e2c957c 100644
> --- a/hw/acpi/cpu.c
> +++ b/hw/acpi/cpu.c
> @@ -18,6 +18,7 @@ enum {
> CPHP_GET_NEXT_CPU_WITH_EVENT_CMD = 0,
> CPHP_OST_EVENT_CMD = 1,
> CPHP_OST_STATUS_CMD = 2,
> +CPHP_GET_CPU_ID_CMD = 3,
> CPHP_CMD_MAX
> };
>
> @@ -75,6 +76,9 @@ static uint64_t cpu_hotplug_rd(void *opaque, hwaddr addr,
> unsigned size)
> case CPHP_GET_NEXT_CPU_WITH_EVENT_CMD:
> val = cpu_st->selector;
> break;
> +case CPHP_GET_CPU_ID_CMD:
> + val = cdev->arch_id & 0x;
> + break;
> default:
> break;
> }
> @@ -85,6 +89,9 @@ static uint64_t cpu_hotplug_rd(void *opaque, hwaddr addr,
> unsigned size)
> case CPHP_GET_NEXT_CPU_WITH_EVENT_CMD:
> val = 0;
> break;
> +case CPHP_GET_CPU_ID_CMD:
> + val = cdev->arch_id >> 32;
> + break;
> default:
> break;
> }
>
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
Re: [PATCH for-5.0 v2 8/9] acpi: cpuhp: spec: add typical usecases
On 12/09/19 14:09, Igor Mammedov wrote: > Document work-flows for > * enabling/detecting modern CPU hotplug interface > * finding a CPU with pending 'insert/remove' event > * enumerating present and possible CPUs > > Signed-off-by: Igor Mammedov > --- > v2: > - fix indent of "other values" that's just above >being added "Typical usecases:" section > - unindent "Typical usecases" to put it into right scope >(Laszlo) > - squash in ammended (using CPHP_GET_NEXT_CPU_WITH_EVENT_CMD) >"acpi: cpuhp: spec: document procedure for enabling modern CPU hotplug" >(Laszlo) > --- > docs/specs/acpi_cpu_hotplug.txt | 51 > ++--- > 1 file changed, 48 insertions(+), 3 deletions(-) > > diff --git a/docs/specs/acpi_cpu_hotplug.txt b/docs/specs/acpi_cpu_hotplug.txt > index 9879f9e..cb99cf3 100644 > --- a/docs/specs/acpi_cpu_hotplug.txt > +++ b/docs/specs/acpi_cpu_hotplug.txt > @@ -15,14 +15,14 @@ CPU present bitmap for: >PIIX-PM (IO port 0xaf00-0xaf1f, 1-byte access) >One bit per CPU. Bit position reflects corresponding CPU APIC ID. > Read-only. >The first DWORD in bitmap is used in write mode to switch from legacy > - to new CPU hotplug interface, write 0 into it to do switch. > + to modern CPU hotplug interface, write 0 into it to do switch. > --- > QEMU sets corresponding CPU bit on hot-add event and issues SCI > with GPE.2 event set. CPU present map is read by ACPI BIOS GPE.2 handler > to notify OS about CPU hot-add events. CPU hot-remove isn't supported. > > = > -ACPI CPU hotplug interface registers: > +Modern ACPI CPU hotplug interface registers: > - (1) If you need to post a v3 for other reasons, please consider adjusting the "===" and "---" lines that surround the new heading. Otherwise, don't bother. > Register block base address: > ICH9-LPC IO port 0x0cd8 > @@ -67,6 +67,7 @@ write access: > [0x0-0x3] CPU selector: (DWORD access) >selects active CPU device. All following accesses to other >registers will read/store data from/to selected CPU. > + Valid values: [0 .. max_cpus) > [0x4] CPU device control fields: (1 byte access) > bits: > 0: reserved, OSPM must clear it before writing to register. > @@ -98,4 +99,48 @@ write access: >2: stores value into OST status register, triggers > ACPI_DEVICE_OST QMP event from QEMU to external applications > with current values of OST event and status registers. > -other values: reserved > + other values: reserved > + > +Typical usecases: > +- (x86) Detecting and enabling modern CPU hotplug interface. > + QEMU starts with legacy CPU hotplug interface enabled. Detecting and > + switching to modern interface is based on the 2 legacy CPU hotplug > features: > +1. Writes into CPU bitmap are ignored. > +2. CPU bitmap always has bit#0 set, corresponding to boot CPU. > + > + Use following steps to detect and enable modern CPU hotplug interface: > +1. Store 0x0 to the 'CPU selector' register, > + attempting to switch to modern mode > +2. Store 0x0 to the 'CPU selector' register, > + to ensure valid selector value > +3. Store 0x0 to the 'Command field' register, > +4. Read the 'Command data 2' register. > + If read value is 0x0, the modern interface is enabled. > + Otherwise legacy or no CPU hotplug interface available > + > +- Get a cpu with pending event > + 1. Store 0x0 to the 'CPU selector' register. > + 2. Store 0x0 to the 'Command field' register. > + 3. Read the 'CPU device status fields' register. > + 4. If both bit#1 and bit#2 are clear in the value read, there is no CPU > + with a pending event and selected CPU remains unchanged. > + 5. Otherwise, read the 'Command data' register. The value read is the > + selector of the CPU with the pending event (which is already > + selected). > + > +- Enumerate CPUs present/non present CPUs > + 01. Set the present CPU count to 0. > + 02. Set the iterator to 0. > + 03. Store 0x0 to the 'CPU selector' register, to ensure that it's in > + a valid state and that access to other registers won't be ignored. > + 04. Store 0x0 to the 'Command field' register to make 'Command data' > + register return 'CPU selector' value of selected CPU > + 05. Read the 'CPU device status fields' register. > + 06. If bit#0 is set, increment the present CPU count. > + 07. Increment the iterator. > + 08. Store the iterator to the 'CPU selector' register. > + 09. Read the 'Command data' register. > + 10. If the value read is not zero, goto 05. > + 11. Otherwise
Re: [PATCH for-5.0 v2 7/9] acpi: cpuhp: introduce 'Command data 2' field
On 12/09/19 14:09, Igor Mammedov wrote:
> No functional change in practice, patch only aims to properly
> document (in spec and code) intended usage of the reserved space.
>
> The new field is to be used for 2 purposes:
> - detection of modern CPU hotplug interface using
> CPHP_GET_NEXT_CPU_WITH_EVENT_CMD command.
> procedure will be described in follow up patch:
> "acpi: cpuhp: spec: add typical usecases"
> - for returning upper 32 bits of architecture specific CPU ID,
> for new CPHP_GET_CPU_ID_CMD command added by follow up patch:
> "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command"
>
> Change is backward compatible with 4.2 and older machines, as field was
> unconditionally reserved and always returned 0x0 if modern CPU hotplug
> interface was enabled.
>
> Signed-off-by: Igor Mammedov
> ---
> docs/specs/acpi_cpu_hotplug.txt | 5 -
> hw/acpi/cpu.c | 11 +++
> hw/acpi/trace-events| 1 +
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/docs/specs/acpi_cpu_hotplug.txt b/docs/specs/acpi_cpu_hotplug.txt
> index 8fb9ad2..9879f9e 100644
> --- a/docs/specs/acpi_cpu_hotplug.txt
> +++ b/docs/specs/acpi_cpu_hotplug.txt
> @@ -44,7 +44,10 @@ keeps the current value.
>
> read access:
> offset:
> -[0x0-0x3] reserved
> +[0x0-0x3] Command data 2: (DWORD access)
> + if value last stored in 'Command field':
> +0: reads as 0x0
> +other values: reserved
> [0x4] CPU device status fields: (1 byte access)
> bits:
> 0: Device is enabled and may be used by guest
> diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
> index 87f30a3..d475c06 100644
> --- a/hw/acpi/cpu.c
> +++ b/hw/acpi/cpu.c
> @@ -12,6 +12,7 @@
> #define ACPI_CPU_FLAGS_OFFSET_RW 4
> #define ACPI_CPU_CMD_OFFSET_WR 5
> #define ACPI_CPU_CMD_DATA_OFFSET_RW 8
> +#define ACPI_CPU_CMD_DATA2_OFFSET_R 0
>
> enum {
> CPHP_GET_NEXT_CPU_WITH_EVENT_CMD = 0,
> @@ -79,6 +80,16 @@ static uint64_t cpu_hotplug_rd(void *opaque, hwaddr addr,
> unsigned size)
> }
> trace_cpuhp_acpi_read_cmd_data(cpu_st->selector, val);
> break;
> +case ACPI_CPU_CMD_DATA2_OFFSET_R:
> +switch (cpu_st->command) {
> +case CPHP_GET_NEXT_CPU_WITH_EVENT_CMD:
> + val = 0;
> + break;
> +default:
> + break;
> +}
> +trace_cpuhp_acpi_read_cmd_data2(cpu_st->selector, val);
> +break;
> default:
> break;
> }
> diff --git a/hw/acpi/trace-events b/hw/acpi/trace-events
> index 96b8273..afbc77d 100644
> --- a/hw/acpi/trace-events
> +++ b/hw/acpi/trace-events
> @@ -23,6 +23,7 @@ cpuhp_acpi_read_flags(uint32_t idx, uint8_t flags)
> "idx[0x%"PRIx32"] flags: 0x%"
> cpuhp_acpi_write_idx(uint32_t idx) "set active cpu idx: 0x%"PRIx32
> cpuhp_acpi_write_cmd(uint32_t idx, uint8_t cmd) "idx[0x%"PRIx32"] cmd:
> 0x%"PRIx8
> cpuhp_acpi_read_cmd_data(uint32_t idx, uint32_t data) "idx[0x%"PRIx32"]
> data: 0x%"PRIx32
> +cpuhp_acpi_read_cmd_data2(uint32_t idx, uint32_t data) "idx[0x%"PRIx32"]
> data: 0x%"PRIx32
> cpuhp_acpi_cpu_has_events(uint32_t idx, bool ins, bool rm) "idx[0x%"PRIx32"]
> inserting: %d, removing: %d"
> cpuhp_acpi_clear_inserting_evt(uint32_t idx) "idx[0x%"PRIx32"]"
> cpuhp_acpi_clear_remove_evt(uint32_t idx) "idx[0x%"PRIx32"]"
>
Neat. :)
Reviewed-by: Laszlo Ersek
Re: [PATCH for-5.0 v3 3/9] tests: q35: MCH: add default SMBASE SMRAM lock test
On 12/09/19 14:46, Igor Mammedov wrote:
> test lockable SMRAM at default SMBASE feature, introduced by
> patch "q35: implement 128K SMRAM at default SMBASE address"
>
> Signed-off-by: Igor Mammedov
> ---
> v3:
> - a bunch of spelling fixes
>(Christophe de Dinechin )
Since I've run git-range-diff for this series anyway, I guess I can help
other reviewers with the changes (relative to the previous, fully
separate posting):
> 2: f1a896f4dbc6 ! 3: 092ec4a30289 tests: q35: MCH: add default SMBASE
> SMRAM lock test
> @@ -6,7 +6,7 @@
> patch "q35: implement 128K SMRAM at default SMBASE address"
>
> Signed-off-by: Igor Mammedov
> -Message-Id: <1575479147-6641-3-git-send-email-imamm...@redhat.com>
> +Message-Id: <1575899217-333105-1-git-send-email-imamm...@redhat.com>
>
> diff --git a/tests/q35-test.c b/tests/q35-test.c
> --- a/tests/q35-test.c
> @@ -40,7 +40,7 @@
> +qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
> +
> -+/* check that writinng junk to 0x9c before before negotiating is
> ignorred */
> ++/* check that writing junk to 0x9c before before negotiating is
> ignored */
> +for (i = 0; i < 0xff; i++) {
> +qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) ==
> 0);
> @@ -60,7 +60,7 @@
> +qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) ==
> 0x02);
> +
> -+/* RAM access should go inot black hole */
> ++/* RAM access should go into black hole */
> +qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, 0xff);
> +}
> @@ -98,7 +98,7 @@
> +pcidev = qpci_device_find(pcibus, 0);
> +g_assert(pcidev != NULL);
> +
> -+/* check that RAM accessible */
> ++/* check that RAM is accessible */
> +qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
> +
Thanks,
Laszlo
On 12/09/19 14:46, Igor Mammedov wrote:
> ---
> tests/q35-test.c | 105
> +++
> 1 file changed, 105 insertions(+)
>
> diff --git a/tests/q35-test.c b/tests/q35-test.c
> index a68183d..c922d81 100644
> --- a/tests/q35-test.c
> +++ b/tests/q35-test.c
> @@ -186,6 +186,109 @@ static void test_tseg_size(const void *data)
> qtest_quit(qts);
> }
>
> +#define SMBASE 0x3
> +#define SMRAM_TEST_PATTERN 0x32
> +#define SMRAM_TEST_RESET_PATTERN 0x23
> +
> +static void test_smram_smbase_lock(void)
> +{
> +QPCIBus *pcibus;
> +QPCIDevice *pcidev;
> +QDict *response;
> +QTestState *qts;
> +int i;
> +
> +qts = qtest_init("-M q35");
> +
> +pcibus = qpci_new_pc(qts, NULL);
> +g_assert(pcibus != NULL);
> +
> +pcidev = qpci_device_find(pcibus, 0);
> +g_assert(pcidev != NULL);
> +
> +/* check that SMRAM is not enabled by default */
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0);
> +qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
> +
> +/* check that writing junk to 0x9c before before negotiating is ignored
> */
> +for (i = 0; i < 0xff; i++) {
> +qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0);
> +}
> +
> +/* enable SMRAM at SMBASE */
> +qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, 0xff);
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0x01);
> +/* lock SMRAM at SMBASE */
> +qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, 0x02);
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0x02);
> +
> +/* check that SMRAM at SMBASE is locked and can't be unlocked */
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, 0xff);
> +for (i = 0; i <= 0xff; i++) {
> +/* make sure register is immutable */
> +qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
> +g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) ==
> 0x02);
> +
> +/* RAM access should go into black hole */
> +qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, 0xff);
> +}
> +
> +/* reset */
> +response = qtest_qmp(qts, "{'execute': 'system_reset', 'arguments': {}
> }");
> +g_assert(response);
> +g_assert(!qdict_haskey(response, "error"));
> +qobject_unref(response);
> +
> +/* check RAM at SMBASE is available after reset */
> +g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
> +
Re: [PATCH for-5.0 v2 2/9] q35: implement 128K SMRAM at default SMBASE address
On 12/09/19 14:08, Igor Mammedov wrote:
> It's not what real HW does, implementing which would be overkill [**]
> and would require complex cross stack changes (QEMU+firmware) to make
> it work.
> So considering that SMRAM is owned by MCH, for simplicity (ab)use
> reserved Q35 register, which allows QEMU and firmware easily init
> and make RAM at SMBASE available only from SMM context.
>
> Patch uses commit (2f295167e0 q35/mch: implement extended TSEG sizes)
> for inspiration and uses reserved register in config space at 0x9c
> offset [*] to extend q35 pci-host with ability to use 128K at
> 0x3 as SMRAM and hide it (like TSEG) from non-SMM context.
>
> Usage:
> 1: write 0xff in the register
> 2: if the feature is supported, follow up read from the register
> should return 0x01. At this point RAM at 0x3 is still
> available for SMI handler configuration from non-SMM context
> 3: writing 0x02 in the register, locks SMBASE area, making its contents
> available only from SMM context. In non-SMM context, reads return
> 0xff and writes are ignored. Further writes into the register are
> ignored until the system reset.
>
> *) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html
> **) https://www.mail-archive.com/qemu-devel@nongnu.org/msg646965.html
>
> Signed-off-by: Igor Mammedov
> ---
> V2:
> - add a note in commit message/coed that used approach is QEMU hack
> to make impl. simple instead of going after VT-d approach
> which real HW does.
> (Paolo Bonzini )
> - rebase on top of (hw: add compat machines for 5.0), and move
> compat property smbase-smram to pc_compat_4_2[]
> ("Laszlo Ersek" )
> ---
> include/hw/pci-host/q35.h | 10 ++
> hw/i386/pc.c | 4 ++-
> hw/pci-host/q35.c | 84
> +++
> 3 files changed, 90 insertions(+), 8 deletions(-)
Interdiff per git-range-diff, with the last version applied on
1bdc319ab5d2 ("Update version for v4.2.0-rc4 release", 2019-12-03; aka
"v4.2.0-rc4"), and the present version applied on 9b4efa2ede5d ("Merge
remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-12-09' into
staging", 2019-12-09):
> 1: 5aafb1228e86 ! 2: effa5c4ca588 q35: implement 128K SMRAM at default
> SMBASE address
> @@ -2,8 +2,15 @@
>
> q35: implement 128K SMRAM at default SMBASE address
>
> -Use commit (2f295167e0 q35/mch: implement extended TSEG sizes) for
> -inspiration and (ab)use reserved register in config space at 0x9c
> +It's not what real HW does, implementing which would be overkill [**]
> +and would require complex cross stack changes (QEMU+firmware) to make
> +it work.
> +So considering that SMRAM is owned by MCH, for simplicity (ab)use
> +reserved Q35 register, which allows QEMU and firmware easily init
> +and make RAM at SMBASE available only from SMM context.
> +
> +Patch uses commit (2f295167e0 q35/mch: implement extended TSEG sizes)
> +for inspiration and uses reserved register in config space at 0x9c
> offset [*] to extend q35 pci-host with ability to use 128K at
> 0x3 as SMRAM and hide it (like TSEG) from non-SMM context.
>
> @@ -18,9 +25,10 @@
> ignored until the system reset.
>
> *) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html
> +**) https://www.mail-archive.com/qemu-devel@nongnu.org/msg646965.html
>
> Signed-off-by: Igor Mammedov
> -Message-Id: <1575479147-6641-2-git-send-email-imamm...@redhat.com>
> +Message-Id: <1575896942-331151-3-git-send-email-imamm...@redhat.com>
>
> diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
> --- a/include/hw/pci-host/q35.h
> @@ -64,13 +72,13 @@
>
> struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>
> --GlobalProperty pc_compat_4_1[] = {};
> -+GlobalProperty pc_compat_4_1[] = {
> +-GlobalProperty pc_compat_4_2[] = {};
> ++GlobalProperty pc_compat_4_2[] = {
> +{ "mch", "smbase-smram", "off" },
> +};
> - const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);
> + const size_t pc_compat_4_2_len = G_N_ELEMENTS(pc_compat_4_2);
>
> - GlobalProperty pc_compat_4_0[] = {};
> + GlobalProperty pc_compat_4_1[] = {};
>
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> --- a/hw/pci-host/q35.c
> @@ -192,6 +200,10 @@
> memory_region_add_subregion(&mch->smram, mch->below_4g_mem_size,
> &mch->tseg_window);
> +
> ++/*
> ++ * This is not what hardware does, so it's QEMU specific hack.
> ++ * See commit message for details.
> ++ */
> +memory_region_init_io(&mch->smbase_blackhole, OBJECT(mch),
> &blackhole_ops,
> + NULL, "smbase-blackhole",
> + MCH_HOST_BRIDGE_S
Re: [PATCH v38 16/22] target/avr: Add section about AVR into QEMU documentation
On Sunday, December 8, 2019, Michael Rolnik wrote:
> Signed-off-by: Michael Rolnik
> ---
> qemu-doc.texi | 10 ++
> 1 file changed, 10 insertions(+)
>
>
Very good!!
You can add these nice 5-6 examples that you mentioned in yor cover letter.
Just a heads up, if we change mcu/device model during further review, this
doc section will have to be changed too, of course.
Yours,
Aleksandar
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 3ddf5c0a68..cea1008800 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -1757,6 +1757,7 @@ differences are mentioned in the following sections.
> * Microblaze System emulator::
> * SH4 System emulator::
> * Xtensa System emulator::
> +* AVR System emulator::
> @end menu
>
> @node PowerPC System emulator
> @@ -2532,6 +2533,15 @@ so should only be used with trusted guest OS.
>
> @c man end
>
> +@node AVR System emulator
> +@section AVR System emulator
> +@cindex system emulation (AVR)
> +
> +Use the executable @file{qemu-system-avr} to emulates a AVR 8 bit based
> machine having one for the following cores: avr1, avr2, avr25, avr3, avr31,
> avr35, avr4, avr5, avr51, avr6, avrtiny, xmega2, xmega3, xmega4, xmega5,
> xmega6 and xmega7.
> +
> +As for now it does not support any real MCUs. However, it does support a
> "sample" board for educational and testing purposes. This "sample" board
> hosts USART & 16 bit timer devices.
> +
> +
> @node QEMU User space emulator
> @chapter QEMU User space emulator
>
> --
> 2.17.2 (Apple Git-113)
>
>
Re: [PATCH v38 03/22] target/avr: Add instruction decoding
On Monday, December 9, 2019, Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote: > > > On Sunday, December 8, 2019, Michael Rolnik wrote: > >> This includes: >> - encoding of all 16 bit instructions >> - encoding of all 32 bit instructions >> >> Signed-off-by: Michael Rolnik >> Tested-by: Philippe Mathieu-Daudé >> --- >> target/avr/insn.decode | 194 + >> 1 file changed, 194 insertions(+) >> create mode 100644 target/avr/insn.decode >> >> > Hi, Michael, > > Could you please reorder decoding definitions in this file following this > pattern: > > # > # Arithmetic Instructions > # > > < their decoding definitions in the order they appear in the ISA doc > > > # > target/avr: Add instruction translation - Branch Instructions > # > copu-paste error. I meant: # Branch Instructions > # > If you refactor the file this way, it will be much easier to inspect the code, and also to add changes in case of future versions of AVR ISA - the file would look much tidier. Take care, Aleksandar > < their decoding definitions in the order they appear in the ISA doc > > > # > # Data Transfer Instructions > # > > < their decoding definitions in the order they appear in the ISA doc > > > # > # Bit and Bit-test Instructions > # > > < their decoding definitions in the order they appear in the ISA doc > > > # > # MCU Control Instructions > # > > < their decoding definitions in the order they appear in the ISA doc > > > > > Thanks in advance! > > Aleksandar > > > > > > >> diff --git a/target/avr/insn.decode b/target/avr/insn.decode >> new file mode 100644 >> index 00..2eb6de692a >> --- /dev/null >> +++ b/target/avr/insn.decode >> @@ -0,0 +1,194 @@ >> +# >> +# AVR instruction decode definitions. >> +# >> +# Copyright (c) 2019 Michael Rolnik >> +# >> +# This library is free software; you can redistribute it and/or >> +# modify it under the terms of the GNU Lesser General Public >> +# License as published by the Free Software Foundation; either >> +# version 2.1 of the License, or (at your option) any later version. >> +# >> +# This library is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> +# Lesser General Public License for more details. >> +# >> +# You should have received a copy of the GNU Lesser General Public >> +# License along with this library; if not, see < >> http://www.gnu.org/licenses/>. >> +# >> + >> +# >> +# regs_16_31_by_one = [16 .. 31] >> +# regs_16_23_by_one = [16 .. 23] >> +# regs_24_30_by_two = [24, 26, 28, 30] >> +# regs_00_30_by_two = [0, 2, 4, 6, 8, .. 30] >> + >> +%rd 4:5 >> +%rr 9:1 0:4 >> + >> +&rd_rr rd rr >> +&rd_imm rd imm >> + >> +@op_rd_rr .. . . &rd_rr rd=%rd rr=%rr >> +ADD 11 . . @op_rd_rr >> +ADC 0001 11 . . @op_rd_rr >> +AND 0010 00 . . @op_rd_rr >> +CP 0001 01 . . @op_rd_rr >> +CPC 01 . . @op_rd_rr >> +CPSE0001 00 . . @op_rd_rr >> +EOR 0010 01 . . @op_rd_rr >> +MOV 0010 11 . . @op_rd_rr >> +MUL 1001 11 . . @op_rd_rr >> +OR 0010 10 . . @op_rd_rr >> +SBC 10 . . @op_rd_rr >> +SUB 0001 10 . . @op_rd_rr >> + >> + >> +%rd_c 4:2 !function=to_regs_24_30_by_ >> two >> +%imm6 6:2 0:4 >> + >> +@op_rd_imm6 .. .. &rd_imm rd=%rd_c >> imm=%imm6 >> +ADIW1001 0110 .. .. @op_rd_imm6 >> +SBIW1001 0111 .. .. @op_rd_imm6 >> + >> + >> +%rd_a 4:4 !function=to_regs_16_31_by_ >> one >> +%rr_a 0:4 !function=to_regs_16_31_by_ >> one >> +%rd_d 4:4 !function=to_regs_00_30_by_ >> two >> +%rr_d 0:4 !function=to_regs_00_30_by_ >> two >> +%imm8 8:4 0:4 >> + >> +@op_rd_imm8 &rd_imm rd=%rd_a >> imm=%imm8 >> +ANDI0111 @op_rd_imm8 >> +CPI 0011 @op_rd_imm8 >> +LDI 1110 @op_rd_imm8 >> +ORI 0110 @op_rd_imm8 >> +SBCI0100 @op_rd_imm8 >> +SUBI0101 @op_rd_imm8 >> + >> + >> +@op_rd ... rd:5 >> +ASR 1001 010 . 0101 @op_rd >> +COM 1001 010 . @op_rd >> +DEC 1001 010 . 1010 @op_rd >> +ELPM2 1001 000 . 0
Re: [PATCH v38 03/22] target/avr: Add instruction decoding
On Sunday, December 8, 2019, Michael Rolnik wrote: > This includes: > - encoding of all 16 bit instructions > - encoding of all 32 bit instructions > > Signed-off-by: Michael Rolnik > Tested-by: Philippe Mathieu-Daudé > --- > target/avr/insn.decode | 194 + > 1 file changed, 194 insertions(+) > create mode 100644 target/avr/insn.decode > > Hi, Michael, Could you please reorder decoding definitions in this file following this pattern: # # Arithmetic Instructions # < their decoding definitions in the order they appear in the ISA doc > # target/avr: Add instruction translation - Branch Instructions # < their decoding definitions in the order they appear in the ISA doc > # # Data Transfer Instructions # < their decoding definitions in the order they appear in the ISA doc > # # Bit and Bit-test Instructions # < their decoding definitions in the order they appear in the ISA doc > # # MCU Control Instructions # < their decoding definitions in the order they appear in the ISA doc > Thanks in advance! Aleksandar > diff --git a/target/avr/insn.decode b/target/avr/insn.decode > new file mode 100644 > index 00..2eb6de692a > --- /dev/null > +++ b/target/avr/insn.decode > @@ -0,0 +1,194 @@ > +# > +# AVR instruction decode definitions. > +# > +# Copyright (c) 2019 Michael Rolnik > +# > +# This library is free software; you can redistribute it and/or > +# modify it under the terms of the GNU Lesser General Public > +# License as published by the Free Software Foundation; either > +# version 2.1 of the License, or (at your option) any later version. > +# > +# This library is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +# Lesser General Public License for more details. > +# > +# You should have received a copy of the GNU Lesser General Public > +# License along with this library; if not, see < > http://www.gnu.org/licenses/>. > +# > + > +# > +# regs_16_31_by_one = [16 .. 31] > +# regs_16_23_by_one = [16 .. 23] > +# regs_24_30_by_two = [24, 26, 28, 30] > +# regs_00_30_by_two = [0, 2, 4, 6, 8, .. 30] > + > +%rd 4:5 > +%rr 9:1 0:4 > + > +&rd_rr rd rr > +&rd_imm rd imm > + > +@op_rd_rr .. . . &rd_rr rd=%rd rr=%rr > +ADD 11 . . @op_rd_rr > +ADC 0001 11 . . @op_rd_rr > +AND 0010 00 . . @op_rd_rr > +CP 0001 01 . . @op_rd_rr > +CPC 01 . . @op_rd_rr > +CPSE0001 00 . . @op_rd_rr > +EOR 0010 01 . . @op_rd_rr > +MOV 0010 11 . . @op_rd_rr > +MUL 1001 11 . . @op_rd_rr > +OR 0010 10 . . @op_rd_rr > +SBC 10 . . @op_rd_rr > +SUB 0001 10 . . @op_rd_rr > + > + > +%rd_c 4:2 !function=to_regs_24_30_by_two > +%imm6 6:2 0:4 > + > +@op_rd_imm6 .. .. &rd_imm rd=%rd_c imm=%imm6 > +ADIW1001 0110 .. .. @op_rd_imm6 > +SBIW1001 0111 .. .. @op_rd_imm6 > + > + > +%rd_a 4:4 !function=to_regs_16_31_by_one > +%rr_a 0:4 !function=to_regs_16_31_by_one > +%rd_d 4:4 !function=to_regs_00_30_by_two > +%rr_d 0:4 !function=to_regs_00_30_by_two > +%imm8 8:4 0:4 > + > +@op_rd_imm8 &rd_imm rd=%rd_a imm=%imm8 > +ANDI0111 @op_rd_imm8 > +CPI 0011 @op_rd_imm8 > +LDI 1110 @op_rd_imm8 > +ORI 0110 @op_rd_imm8 > +SBCI0100 @op_rd_imm8 > +SUBI0101 @op_rd_imm8 > + > + > +@op_rd ... rd:5 > +ASR 1001 010 . 0101 @op_rd > +COM 1001 010 . @op_rd > +DEC 1001 010 . 1010 @op_rd > +ELPM2 1001 000 . 0110 @op_rd > +ELPMX 1001 000 . 0111 @op_rd > +INC 1001 010 . 0011 @op_rd > +LDX11001 000 . 1100 @op_rd > +LDX21001 000 . 1101 @op_rd > +LDX31001 000 . 1110 @op_rd > +LDY21001 000 . 1001 @op_rd > +LDY31001 000 . 1010 @op_rd > +LDZ21001 000 . 0001 @op_rd > +LDZ31001 000 . 0010 @op_rd > +LPM21001 000 . 0100
Re: [PATCH] target/arm: ensure we use current exception state after SCR update
Patchew URL: https://patchew.org/QEMU/20191209143723.6368-1-alex.ben...@linaro.org/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-h1p3v7cj/src/docker-src.2019-12-09-14.28.28.18212] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-h1p3v7cj/src' make: *** [docker-run-test-quick@centos7] Error 2 real0m3.985s user0m2.582s The full log is available at http://patchew.org/logs/20191209143723.6368-1-alex.ben...@linaro.org/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH] virtio-fs: fix MSI-X nvectors calculation
Patchew URL: https://patchew.org/QEMU/20191209110759.35227-1-stefa...@redhat.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #! /bin/bash export ARCH=x86_64 make docker-image-fedora V=1 NETWORK=1 time make docker-test-mingw@fedora J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-qf8_kdog/src/docker-src.2019-12-09-14.22.17.17018] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-qf8_kdog/src' make: *** [docker-run-test-mingw@fedora] Error 2 real4m26.482s user0m2.275s The full log is available at http://patchew.org/logs/20191209110759.35227-1-stefa...@redhat.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH] virtio-fs: fix MSI-X nvectors calculation
Patchew URL: https://patchew.org/QEMU/20191209110759.35227-1-stefa...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-x3rpl899/src/docker-src.2019-12-09-14.16.12.15965] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-x3rpl899/src' make: *** [docker-run-test-quick@centos7] Error 2 real5m24.090s user0m2.544s The full log is available at http://patchew.org/logs/20191209110759.35227-1-stefa...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH] target/arm: Display helpful message when hflags mismatch
Patchew URL: https://patchew.org/QEMU/20191209134552.27733-1-phi...@redhat.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #! /bin/bash export ARCH=x86_64 make docker-image-fedora V=1 NETWORK=1 time make docker-test-mingw@fedora J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-_5dpbvna/src/docker-src.2019-12-09-14.05.27.14518] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-_5dpbvna/src' make: *** [docker-run-test-mingw@fedora] Error 2 real5m12.306s user0m2.438s The full log is available at http://patchew.org/logs/20191209134552.27733-1-phi...@redhat.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH] target/arm: Display helpful message when hflags mismatch
Patchew URL: https://patchew.org/QEMU/20191209134552.27733-1-phi...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-8vki3gda/src/docker-src.2019-12-09-14.00.09.13536] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-8vki3gda/src' make: *** [docker-run-test-quick@centos7] Error 2 real4m52.604s user0m2.594s The full log is available at http://patchew.org/logs/20191209134552.27733-1-phi...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH-for-5.0 v3 0/6] hw/pci-host: Add Kconfig selector for IGD PCIe pass-through
Patchew URL: https://patchew.org/QEMU/20191209095002.32194-1-phi...@redhat.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #! /bin/bash export ARCH=x86_64 make docker-image-fedora V=1 NETWORK=1 time make docker-test-mingw@fedora J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-w4w8li1u/src/docker-src.2019-12-09-13.44.32.11934] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-w4w8li1u/src' make: *** [docker-run-test-mingw@fedora] Error 2 real5m17.813s user0m2.470s The full log is available at http://patchew.org/logs/20191209095002.32194-1-phi...@redhat.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH v38 11/22] target/avr: Add instruction disassembly function
Hi Aleksandar.
1. all instructions are 16 bit long except CALL & JMP they are 32 bit long
2. next_word_used is set to true by next_word when called by append_16 when
CALL & JMP are parsed
Regards,
Michael Rolnik
On Mon, Dec 9, 2019 at 8:10 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Sunday, December 8, 2019, Michael Rolnik wrote:
>
>> Provide function disassembles executed instruction when `-d in_asm` is
>> provided
>>
>> Example:
>> `./avr-softmmu/qemu-system-avr -bios
>> free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf -d in_asm` will produce
>> something like the following
>>
>> ```
>> ...
>> IN:
>> 0x014a: CALL 0x3808
>>
>> IN: main
>> 0x3808: CALL 0x4b4
>>
>> IN: vParTestInitialise
>> 0x04b4: LDI r24, 255
>> 0x04b6: STS r24, 0
>> 0x04b8: MULS r16, r20
>> 0x04ba: OUT $1, r24
>> 0x04bc: LDS r24, 0
>> 0x04be: MULS r16, r20
>> 0x04c0: OUT $2, r24
>> 0x04c2: RET
>> ...
>> ```
>>
>> Signed-off-by: Michael Rolnik
>> Suggested-by: Richard Henderson
>> Suggested-by: Philippe Mathieu-Daudé
>> Suggested-by: Aleksandar Markovic
>> Reviewed-by: Philippe Mathieu-Daudé
>> Tested-by: Philippe Mathieu-Daudé
>> ---
>> target/avr/cpu.h | 1 +
>> target/avr/cpu.c | 2 +-
>> target/avr/disas.c | 226 +
>> target/avr/translate.c | 11 ++
>> 4 files changed, 239 insertions(+), 1 deletion(-)
>> create mode 100644 target/avr/disas.c
>>
>> diff --git a/target/avr/cpu.h b/target/avr/cpu.h
>> index c217eefeb4..a8a3e7ade6 100644
>> --- a/target/avr/cpu.h
>> +++ b/target/avr/cpu.h
>> @@ -178,6 +178,7 @@ bool avr_cpu_exec_interrupt(CPUState *cpu, int
>> int_req);
>> hwaddr avr_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
>> int avr_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
>> int avr_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
>> +int avr_print_insn(bfd_vma addr, disassemble_info *info);
>>
>> static inline int avr_feature(CPUAVRState *env, int feature)
>> {
>> diff --git a/target/avr/cpu.c b/target/avr/cpu.c
>> index c5cafcae3c..be4b921e4d 100644
>> --- a/target/avr/cpu.c
>> +++ b/target/avr/cpu.c
>> @@ -83,7 +83,7 @@ static void avr_cpu_reset(CPUState *cs)
>> static void avr_cpu_disas_set_info(CPUState *cpu, disassemble_info *info)
>> {
>> info->mach = bfd_arch_avr;
>> -info->print_insn = NULL;
>> +info->print_insn = avr_print_insn;
>> }
>>
>> static void avr_cpu_realizefn(DeviceState *dev, Error **errp)
>> diff --git a/target/avr/disas.c b/target/avr/disas.c
>> new file mode 100644
>> index 00..22863d2eb1
>> --- /dev/null
>> +++ b/target/avr/disas.c
>> @@ -0,0 +1,226 @@
>> +/*
>> + * AVR disassembler
>> + *
>> + * Copyright (c) 2019 Richard Henderson
>> + * Copyright (c) 2019 Michael Rolnik
>> + *
>> + * This program is free software: you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation, either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see
Re: [PATCH v38 18/22] target/avr: Add machine none test
On Monday, December 9, 2019, Michael Rolnik wrote:
> :)
>
> no idea. all other machines / CPUs have it, so I added as well
>
>>
>>
lol
> On Mon, Dec 9, 2019 at 8:13 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Sunday, December 8, 2019, Michael Rolnik wrote:
>>
>>> Signed-off-by: Michael Rolnik
>>> Tested-by: Philippe Mathieu-Daudé
>>> Reviewed-by: Aleksandar Markovic
>>> ---
>>> tests/machine-none-test.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>>
>> You need to add a commit message explaining how adding a test is achieved
>> with this single line.
>>
>>
>>
>>> diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
>>> index 5953d31755..3e5c74e73e 100644
>>> --- a/tests/machine-none-test.c
>>> +++ b/tests/machine-none-test.c
>>> @@ -27,6 +27,7 @@ static struct arch2cpu cpus_map[] = {
>>> /* tested targets list */
>>> { "arm", "cortex-a15" },
>>> { "aarch64", "cortex-a57" },
>>> +{ "avr", "avr6-avr-cpu" },
>>> { "x86_64", "qemu64,apic-id=0" },
>>> { "i386", "qemu32,apic-id=0" },
>>> { "alpha", "ev67" },
>>> --
>>> 2.17.2 (Apple Git-113)
>>>
>>>
>
> --
> Best Regards,
> Michael Rolnik
>
Re: [libvirt] [PATCH v2 0/4] Remove deprecated pc-0.x machine types and related hacks
Patchew URL: https://patchew.org/QEMU/20191209125248.5849-1-th...@redhat.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #! /bin/bash export ARCH=x86_64 make docker-image-fedora V=1 NETWORK=1 time make docker-test-mingw@fedora J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-9lcnuxat/src/docker-src.2019-12-09-13.19.18.7229] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-9lcnuxat/src' make: *** [docker-run-test-mingw@fedora] Error 2 real4m35.183s user0m2.657s The full log is available at http://patchew.org/logs/20191209125248.5849-1-th...@redhat.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH-for-5.0 v3 0/6] hw/pci-host: Add Kconfig selector for IGD PCIe pass-through
Patchew URL: https://patchew.org/QEMU/20191209095002.32194-1-phi...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-2t3gdqmo/src/docker-src.2019-12-09-13.30.01.10260] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-2t3gdqmo/src' make: *** [docker-run-test-quick@centos7] Error 2 real9m11.026s user0m2.757s The full log is available at http://patchew.org/logs/20191209095002.32194-1-phi...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [libvirt] [PATCH v2 0/4] Remove deprecated pc-0.x machine types and related hacks
Patchew URL: https://patchew.org/QEMU/20191209125248.5849-1-th...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' Cloning into 'dtc'... remote: Counting objects: 5280, done. error: RPC failed; result=18, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header Clone of 'https://git.qemu.org/git/dtc.git' into submodule path 'dtc' failed failed to update submodule dtc Submodule 'dtc' (https://git.qemu.org/git/dtc.git) unregistered for path 'dtc' make[1]: *** [/var/tmp/patchew-tester-tmp-x_fnqco1/src/docker-src.2019-12-09-13.13.54.13964] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-x_fnqco1/src' make: *** [docker-run-test-quick@centos7] Error 2 real4m48.507s user0m2.457s The full log is available at http://patchew.org/logs/20191209125248.5849-1-th...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH v38 15/22] target/avr: Add example board configuration
I will check again.
On Mon, Dec 9, 2019 at 8:30 PM Michael Rolnik wrote:
> Yes, I did compile other platforms.
>
> On Mon, Dec 9, 2019 at 8:24 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Sunday, December 8, 2019, Michael Rolnik wrote:
>>
>>> A simple board setup that configures an AVR CPU to run a given firmware
>>> image.
>>> This is all that's useful to implement without peripheral emulation as
>>> AVR CPUs include a lot of on-board peripherals.
>>>
>>> NOTE: this is not a real board
>>> NOTE: it's used for CPU testing
>>>
>>> Signed-off-by: Michael Rolnik
>>> Reviewed-by: Aleksandar Markovic
>>> Nacked-by: Philippe Mathieu-Daudé
>>> ---
>>> include/elf.h| 2 +
>>> include/hw/elf_ops.h | 6 +-
>>> include/hw/loader.h | 3 +-
>>> hw/avr/sample.c | 293 +++
>>> hw/core/loader.c | 13 +-
>>> hw/Kconfig | 1 +
>>> hw/avr/Kconfig | 6 +
>>> hw/avr/Makefile.objs | 1 +
>>> 8 files changed, 317 insertions(+), 8 deletions(-)
>>> create mode 100644 hw/avr/sample.c
>>> create mode 100644 hw/avr/Kconfig
>>> create mode 100644 hw/avr/Makefile.objs
>>>
>>> diff --git a/include/elf.h b/include/elf.h
>>> index 3501e0c8d0..53cdfa23b7 100644
>>> --- a/include/elf.h
>>> +++ b/include/elf.h
>>> @@ -202,6 +202,8 @@ typedef struct mips_elf_abiflags_v0 {
>>> #define EM_MOXIE 223 /* Moxie processor family */
>>> #define EM_MOXIE_OLD 0xFEED
>>>
>>> +#define EM_AVR 83 /* AVR 8-bit microcontroller */
>>> +
>>> /* This is the info that is needed to parse the dynamic section of the
>>> file */
>>> #define DT_NULL0
>>> #define DT_NEEDED 1
>>> diff --git a/include/hw/elf_ops.h b/include/hw/elf_ops.h
>>> index e07d276df7..9f28c16490 100644
>>> --- a/include/hw/elf_ops.h
>>> +++ b/include/hw/elf_ops.h
>>> @@ -316,7 +316,8 @@ static int glue(load_elf, SZ)(const char *name, int
>>> fd,
>>>void *translate_opaque,
>>>int must_swab, uint64_t *pentry,
>>>uint64_t *lowaddr, uint64_t *highaddr,
>>> - int elf_machine, int clear_lsb, int
>>> data_swab,
>>> + int elf_machine, uint32_t *pflags,
>>> + int clear_lsb, int data_swab,
>>>AddressSpace *as, bool load_rom,
>>>symbol_fn_t sym_cb)
>>
>>
>>>
>> New parameter uint32_t *pflags should go before int elf_machine, so that
>> input and output parameters are grouped together. The mane should be more
>> precise, like pe_flags.
>>
>> But, it looks to me that you are breaking all other platforms with this
>> change. Did you try full qemu build after your series is applied?
>>
>>
>>>
>>
>> {
>>> @@ -594,6 +595,9 @@ static int glue(load_elf, SZ)(const char *name, int
>>> fd,
>>> }
>>> }
>>>
>>> +if (pflags) {
>>> +*pflags = (uint32_t)(elf_sword)ehdr.e_flags;
>>> +}
>>> if (lowaddr)
>>> *lowaddr = (uint64_t)(elf_sword)low;
>>> if (highaddr)
>>> diff --git a/include/hw/loader.h b/include/hw/loader.h
>>> index 48a96cd559..3dbdd1868d 100644
>>> --- a/include/hw/loader.h
>>> +++ b/include/hw/loader.h
>>> @@ -132,7 +132,8 @@ int load_elf_ram_sym(const char *filename,
>>> uint64_t (*translate_fn)(void *, uint64_t),
>>> void *translate_opaque, uint64_t *pentry,
>>> uint64_t *lowaddr, uint64_t *highaddr, int
>>> big_endian,
>>> - int elf_machine, int clear_lsb, int data_swab,
>>> + int elf_machine, uint32_t *pflags,
>>> + int clear_lsb, int data_swab,
>>> AddressSpace *as, bool load_rom, symbol_fn_t
>>> sym_cb);
>>>
>>> /** load_elf_ram:
>>> diff --git a/hw/avr/sample.c b/hw/avr/sample.c
>>> new file mode 100644
>>> index 00..6574733b57
>>> --- /dev/null
>>> +++ b/hw/avr/sample.c
>>> @@ -0,0 +1,293 @@
>>> +/*
>>> + * QEMU AVR CPU
>>> + *
>>> + * Copyright (c) 2019 Michael Rolnik
>>> + *
>>> + * This library is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * This library is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with this library; if not, see
>>> + *
>>> + */
>>> +
>>> +/*
>>> + * NOTE:
>>> + * This is not a
Re: [PATCH v38 17/22] target/avr: Register AVR support with the rest of QEMU
I prefer to remove it, as nobody uses it. what do you think? the full list
is in target/avr/cpu.h file
On Mon, Dec 9, 2019 at 8:16 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Sunday, December 8, 2019, Michael Rolnik wrote:
>
>> Add AVR related definitions into QEMU
>>
>> Signed-off-by: Michael Rolnik
>> Tested-by: Philippe Mathieu-Daudé
>> Reviewed-by: Aleksandar Markovic
>> ---
>> qapi/machine.json | 3 ++-
>> include/disas/dis-asm.h| 6 ++
>> include/sysemu/arch_init.h | 1 +
>> arch_init.c| 2 ++
>> 4 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/qapi/machine.json b/qapi/machine.json
>> index ca26779f1a..8c6df54921 100644
>> --- a/qapi/machine.json
>> +++ b/qapi/machine.json
>> @@ -21,11 +21,12 @@
>> #is true even for "qemu-system-x86_64".
>> #
>> # ppcemb: dropped in 3.1
>> +# avr: since 5.0
>> #
>> # Since: 3.0
>> ##
>> { 'enum' : 'SysEmuTarget',
>> - 'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
>> + 'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386',
>> 'lm32',
>
> 'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
>> 'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
>> 'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
>> diff --git a/include/disas/dis-asm.h b/include/disas/dis-asm.h
>> index e9c7dd8eb4..8bedce17ac 100644
>> --- a/include/disas/dis-asm.h
>> +++ b/include/disas/dis-asm.h
>> @@ -211,6 +211,12 @@ enum bfd_architecture
>> #define bfd_mach_m32r 0 /* backwards compatibility */
>>bfd_arch_mn10200,/* Matsushita MN10200 */
>>bfd_arch_mn10300,/* Matsushita MN10300 */
>> + bfd_arch_avr, /* Atmel AVR microcontrollers. */
>> +#define bfd_mach_avr1 1
>> +#define bfd_mach_avr2 2
>> +#define bfd_mach_avr3 3
>> +#define bfd_mach_avr4 4
>> +#define bfd_mach_avr5 5
>
>
> Incomplete list. I already explained why in reply to v37.
>
>
>
>>bfd_arch_cris, /* Axis CRIS */
>> #define bfd_mach_cris_v0_v10 255
>> #define bfd_mach_cris_v32 32
>> diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
>> index 62c6fe4cf1..893df26ce2 100644
>> --- a/include/sysemu/arch_init.h
>> +++ b/include/sysemu/arch_init.h
>> @@ -24,6 +24,7 @@ enum {
>> QEMU_ARCH_NIOS2 = (1 << 17),
>> QEMU_ARCH_HPPA = (1 << 18),
>> QEMU_ARCH_RISCV = (1 << 19),
>> +QEMU_ARCH_AVR = (1 << 20),
>> };
>>
>> extern const uint32_t arch_type;
>> diff --git a/arch_init.c b/arch_init.c
>> index 705d0b94ad..6a741165b2 100644
>> --- a/arch_init.c
>> +++ b/arch_init.c
>> @@ -89,6 +89,8 @@ int graphic_depth = 32;
>> #define QEMU_ARCH QEMU_ARCH_UNICORE32
>> #elif defined(TARGET_XTENSA)
>> #define QEMU_ARCH QEMU_ARCH_XTENSA
>> +#elif defined(TARGET_AVR)
>> +#define QEMU_ARCH QEMU_ARCH_AVR
>> #endif
>>
>> const uint32_t arch_type = QEMU_ARCH;
>> --
>> 2.17.2 (Apple Git-113)
>>
>>
--
Best Regards,
Michael Rolnik
Re: [PATCH v38 15/22] target/avr: Add example board configuration
On Sunday, December 8, 2019, Michael Rolnik wrote:
> A simple board setup that configures an AVR CPU to run a given firmware
> image.
> This is all that's useful to implement without peripheral emulation as AVR
> CPUs include a lot of on-board peripherals.
>
> NOTE: this is not a real board
> NOTE: it's used for CPU testing
>
> Signed-off-by: Michael Rolnik
> Reviewed-by: Aleksandar Markovic
> Nacked-by: Philippe Mathieu-Daudé
> ---
> include/elf.h| 2 +
> include/hw/elf_ops.h | 6 +-
> include/hw/loader.h | 3 +-
> hw/avr/sample.c | 293 +++
> hw/core/loader.c | 13 +-
> hw/Kconfig | 1 +
> hw/avr/Kconfig | 6 +
> hw/avr/Makefile.objs | 1 +
> 8 files changed, 317 insertions(+), 8 deletions(-)
> create mode 100644 hw/avr/sample.c
> create mode 100644 hw/avr/Kconfig
> create mode 100644 hw/avr/Makefile.objs
>
> diff --git a/include/elf.h b/include/elf.h
> index 3501e0c8d0..53cdfa23b7 100644
> --- a/include/elf.h
> +++ b/include/elf.h
> @@ -202,6 +202,8 @@ typedef struct mips_elf_abiflags_v0 {
> #define EM_MOXIE 223 /* Moxie processor family */
> #define EM_MOXIE_OLD 0xFEED
>
> +#define EM_AVR 83 /* AVR 8-bit microcontroller */
> +
> /* This is the info that is needed to parse the dynamic section of the
> file */
> #define DT_NULL0
> #define DT_NEEDED 1
> diff --git a/include/hw/elf_ops.h b/include/hw/elf_ops.h
> index e07d276df7..9f28c16490 100644
> --- a/include/hw/elf_ops.h
> +++ b/include/hw/elf_ops.h
> @@ -316,7 +316,8 @@ static int glue(load_elf, SZ)(const char *name, int fd,
>void *translate_opaque,
>int must_swab, uint64_t *pentry,
>uint64_t *lowaddr, uint64_t *highaddr,
> - int elf_machine, int clear_lsb, int
> data_swab,
> + int elf_machine, uint32_t *pflags,
> + int clear_lsb, int data_swab,
>AddressSpace *as, bool load_rom,
>symbol_fn_t sym_cb)
>
New parameter uint32_t *pflags should go before int elf_machine, so that
input and output parameters are grouped together. The mane should be more
precise, like pe_flags.
But, it looks to me that you are breaking all other platforms with this
change. Did you try full qemu build after your series is applied?
>
{
> @@ -594,6 +595,9 @@ static int glue(load_elf, SZ)(const char *name, int fd,
> }
> }
>
> +if (pflags) {
> +*pflags = (uint32_t)(elf_sword)ehdr.e_flags;
> +}
> if (lowaddr)
> *lowaddr = (uint64_t)(elf_sword)low;
> if (highaddr)
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 48a96cd559..3dbdd1868d 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -132,7 +132,8 @@ int load_elf_ram_sym(const char *filename,
> uint64_t (*translate_fn)(void *, uint64_t),
> void *translate_opaque, uint64_t *pentry,
> uint64_t *lowaddr, uint64_t *highaddr, int
> big_endian,
> - int elf_machine, int clear_lsb, int data_swab,
> + int elf_machine, uint32_t *pflags,
> + int clear_lsb, int data_swab,
> AddressSpace *as, bool load_rom, symbol_fn_t sym_cb);
>
> /** load_elf_ram:
> diff --git a/hw/avr/sample.c b/hw/avr/sample.c
> new file mode 100644
> index 00..6574733b57
> --- /dev/null
> +++ b/hw/avr/sample.c
> @@ -0,0 +1,293 @@
> +/*
> + * QEMU AVR CPU
> + *
> + * Copyright (c) 2019 Michael Rolnik
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see
> + *
> + */
> +
> +/*
> + * NOTE:
> + * This is not a real AVR board, this is an example!
> + * The CPU is an approximation of an ATmega2560, but is missing
> various
> + * built-in peripherals.
> + *
> + * This example board loads provided binary file into flash memory
> and
> + * executes it from 0x address in the code memory space.
> + *
> + * Currently used for AVR CPU validation
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qemu-common.h"
> +#include "cpu.
[PATCH v1 33/36] target/riscv: Set htval and mtval2 on execptions
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 43c6629014..aa033b8590 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -841,6 +841,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)
target_ulong cause = cs->exception_index & RISCV_EXCP_INT_MASK;
target_ulong deleg = async ? env->mideleg : env->medeleg;
target_ulong tval = 0;
+target_ulong htval = 0;
+target_ulong mtval2 = 0;
if (!async) {
/* set tval to badaddr for traps with address information */
@@ -900,6 +902,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)
env->hstatus = set_field(env->hstatus, HSTATUS_SPV,
riscv_cpu_virt_enabled(env));
+htval = env->guest_phys_fault_addr;
+
riscv_cpu_set_virt_enabled(env, 0);
riscv_cpu_set_force_hs_excep(env, 0);
} else {
@@ -910,6 +914,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)
get_field(*env->mstatus,
SSTATUS_SPP));
env->hstatus = set_field(env->hstatus, HSTATUS_SPV,
riscv_cpu_virt_enabled(env));
+
+htval = env->guest_phys_fault_addr;
}
}
@@ -922,6 +928,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
env->scause = cause | ((target_ulong)async << (TARGET_LONG_BITS - 1));
env->sepc = env->pc;
env->sbadaddr = tval;
+env->htval = htval;
env->pc = (env->stvec >> 2 << 2) +
((async && (env->stvec & 3) == 1) ? cause * 4 : 0);
riscv_cpu_set_mode(env, PRV_S);
@@ -936,6 +943,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)
*env->mstatus = set_field(*env->mstatus, MSTATUS_MTL,
riscv_cpu_force_hs_excep_enabled(env));
+mtval2 = env->guest_phys_fault_addr;
+
/* Trapping to M mode, virt is disabled */
riscv_cpu_set_virt_enabled(env, 0);
}
@@ -949,6 +958,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
env->mcause = cause | ~(((target_ulong)-1) >> async);
env->mepc = env->pc;
env->mbadaddr = tval;
+env->mtval2 = mtval2;
env->pc = (env->mtvec >> 2 << 2) +
((async && (env->mtvec & 3) == 1) ? cause * 4 : 0);
riscv_cpu_set_mode(env, PRV_M);
--
2.24.0
Re: [PATCH v3] qga: fence guest-set-time if hwclock not available
On Fri, 06 Dec 2019 08:17:27 +0100
Markus Armbruster wrote:
> Cornelia Huck writes:
>
> > On Thu, 5 Dec 2019 14:05:19 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> Hi Cornelia,
> >>
> >> On 12/5/19 12:53 PM, Cornelia Huck wrote:
> >> > The Posix implementation of guest-set-time invokes hwclock to
> >> > set/retrieve the time to/from the hardware clock. If hwclock
> >> > is not available, the user is currently informed that "hwclock
> >> > failed to set hardware clock to system time", which is quite
> >> > misleading. This may happen e.g. on s390x, which has a different
> >> > timekeeping concept anyway.
> >> >
> >> > Let's check for the availability of the hwclock command and
> >> > return QERR_UNSUPPORTED for guest-set-time if it is not available.
> >> >
> >> > Reviewed-by: Laszlo Ersek
> >> > Reviewed-by: Daniel P. Berrangé
> >> > Reviewed-by: Michael Roth
> >> > Signed-off-by: Cornelia Huck
> >> > ---
> >> >
> >> > v2->v3:
> >> >- added 'static' keyword to hwclock_path
> >> >
> >> > Not sure what tree this is going through; if there's no better place,
> >> > I can also take this through the s390 tree.
> >>
> >> s390 or trivial trees seems appropriate.
> >>
> >> >
> >> > ---
> >> > qga/commands-posix.c | 13 -
> >> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> >> > index 1c1a165daed8..0be301a4ea77 100644
> >> > --- a/qga/commands-posix.c
> >> > +++ b/qga/commands-posix.c
> >> > @@ -156,6 +156,17 @@ void qmp_guest_set_time(bool has_time, int64_t
> >> > time_ns, Error **errp)
> >> > pid_t pid;
> >> > Error *local_err = NULL;
> >> > struct timeval tv;
> >> > +static const char hwclock_path[] = "/sbin/hwclock";
> >> > +static int hwclock_available = -1;
> >> > +
> >> > +if (hwclock_available < 0) {
> >> > +hwclock_available = (access(hwclock_path, X_OK) == 0);
> >> > +}
> >> > +
> >> > +if (!hwclock_available) {
> >> > +error_setg(errp, QERR_UNSUPPORTED);
> >>
> >> In include/qapi/qmp/qerror.h we have:
> >>
> >> /*
> >> * These macros will go away, please don't use in new code, and do not
> >> * add new ones!
> >> */
> >
> > Sigh, it is really hard to keep track here :( I just copied from other
> > callers in this file...
>
> I'm not faulting you for that.
>
> I think this new use is acceptable. For details, see my other reply in
> this thread.
Ok, thanks for your explanation there.
I guess I'll queue this on s390-next... Philippe, any objections to
adding your R-b to the unmodified patch?
Re: [for-5.0 PATCH v2 0/3] cpu: Clarify overloading of reset QOM methods
On Mon, 09 Dec 2019 18:55:12 +0100 Greg Kurz wrote: > Each cpu subclass overloads the reset method of its parent class with > its own. But since it needs to call the parent method as well, it keeps > a parent_reset pointer to do so. This causes the same not very explicit > boiler plate to be duplicated all around the place: > > pcc->parent_reset = cc->reset; > cc->reset = ppc_cpu_reset; > > A similar concern was addressed some time back by Philippe Mathieu-Daudé > in qdev, with the addition of device_class_set_parent_reset() and friends: > > https://git.qemu.org/?p=qemu.git;a=commit;h=46795cf2e2f6 > https://git.qemu.org/?p=qemu.git;a=commit;h=bf853881690d > > Follow the same approach with cpus. > > Changes in v2: > - added Reviewed-by and Acked-by tags > - rebased on top of https://github.com/cohuck/qemu.git s390-next > SHA1 dd6252f035a2 My apologies for the churn. I'll try to flush my queue ASAP after 5.0 development opens. > > -- > Greg > > --- > > Greg Kurz (3): > cpu: Introduce CPUReset callback typedef > cpu: Introduce cpu_class_set_parent_reset() > cpu: Use cpu_class_set_parent_reset() > > > hw/core/cpu.c |8 > include/hw/core/cpu.h |8 +++- > target/alpha/cpu-qom.h |2 +- > target/arm/cpu-qom.h|2 +- > target/arm/cpu.c|3 +-- > target/cris/cpu-qom.h |2 +- > target/cris/cpu.c |3 +-- > target/hppa/cpu-qom.h |2 +- > target/i386/cpu-qom.h |2 +- > target/i386/cpu.c |3 +-- > target/lm32/cpu-qom.h |2 +- > target/lm32/cpu.c |3 +-- > target/m68k/cpu-qom.h |2 +- > target/m68k/cpu.c |3 +-- > target/microblaze/cpu-qom.h |2 +- > target/microblaze/cpu.c |3 +-- > target/mips/cpu-qom.h |2 +- > target/mips/cpu.c |3 +-- > target/moxie/cpu.c |3 +-- > target/moxie/cpu.h |2 +- > target/nios2/cpu.c |3 +-- > target/nios2/cpu.h |2 +- > target/openrisc/cpu.c |3 +-- > target/openrisc/cpu.h |2 +- > target/ppc/cpu-qom.h|2 +- > target/ppc/translate_init.inc.c |3 +-- > target/riscv/cpu.c |3 +-- > target/riscv/cpu.h |2 +- > target/s390x/cpu-qom.h |2 +- > target/s390x/cpu.c |3 +-- > target/sh4/cpu-qom.h|2 +- > target/sh4/cpu.c|3 +-- > target/sparc/cpu-qom.h |2 +- > target/sparc/cpu.c |3 +-- > target/tilegx/cpu.c |3 +-- > target/tilegx/cpu.h |2 +- > target/tricore/cpu-qom.h|2 +- > target/tricore/cpu.c|3 +-- > target/xtensa/cpu-qom.h |2 +- > target/xtensa/cpu.c |3 +-- > 40 files changed, 53 insertions(+), 57 deletions(-) >
[PATCH v1 32/36] target/riscv: Raise the new execptions when 2nd stage translation fails
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 8667e5ffce..43c6629014 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -589,16 +589,28 @@ static void raise_mmu_exception(CPURISCVState *env,
target_ulong address,
}
switch (access_type) {
case MMU_INST_FETCH:
-cs->exception_index = page_fault_exceptions ?
-RISCV_EXCP_INST_PAGE_FAULT : RISCV_EXCP_INST_ACCESS_FAULT;
+if (riscv_cpu_virt_enabled(env) && !first_stage) {
+cs->exception_index = RISCV_EXCP_INST_GUEST_PAGE_FAULT;
+} else {
+cs->exception_index = page_fault_exceptions ?
+RISCV_EXCP_INST_PAGE_FAULT : RISCV_EXCP_INST_ACCESS_FAULT;
+}
break;
case MMU_DATA_LOAD:
-cs->exception_index = page_fault_exceptions ?
-RISCV_EXCP_LOAD_PAGE_FAULT : RISCV_EXCP_LOAD_ACCESS_FAULT;
+if (riscv_cpu_virt_enabled(env) && !first_stage) {
+cs->exception_index = RISCV_EXCP_LOAD_GUEST_ACCESS_FAULT;
+} else {
+cs->exception_index = page_fault_exceptions ?
+RISCV_EXCP_LOAD_PAGE_FAULT : RISCV_EXCP_LOAD_ACCESS_FAULT;
+}
break;
case MMU_DATA_STORE:
-cs->exception_index = page_fault_exceptions ?
-RISCV_EXCP_STORE_PAGE_FAULT : RISCV_EXCP_STORE_AMO_ACCESS_FAULT;
+if (riscv_cpu_virt_enabled(env) && !first_stage) {
+cs->exception_index = RISCV_EXCP_STORE_GUEST_AMO_ACCESS_FAULT;
+} else {
+cs->exception_index = page_fault_exceptions ?
+RISCV_EXCP_STORE_PAGE_FAULT :
RISCV_EXCP_STORE_AMO_ACCESS_FAULT;
+}
break;
default:
g_assert_not_reached();
--
2.24.0
[PATCH v1 36/36] target/riscv: Allow enabling the Hypervisor extension
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
target/riscv/cpu.c | 5 +
target/riscv/cpu.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index ac8f53a49d..f087bc2c8b 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -453,6 +453,9 @@ static void riscv_cpu_realize(DeviceState *dev, Error
**errp)
if (cpu->cfg.ext_u) {
target_misa |= RVU;
}
+if (cpu->cfg.ext_h) {
+target_misa |= RVH;
+}
set_misa(env, RVXLEN | target_misa);
}
@@ -498,6 +501,8 @@ static Property riscv_cpu_properties[] = {
DEFINE_PROP_BOOL("c", RISCVCPU, cfg.ext_c, true),
DEFINE_PROP_BOOL("s", RISCVCPU, cfg.ext_s, true),
DEFINE_PROP_BOOL("u", RISCVCPU, cfg.ext_u, true),
+/* This is experimental so mark with 'x-' */
+DEFINE_PROP_BOOL("x-h", RISCVCPU, cfg.ext_h, false),
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),
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 84a07971dc..53bc6af5f7 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -261,6 +261,7 @@ typedef struct RISCVCPU {
bool ext_c;
bool ext_s;
bool ext_u;
+bool ext_h;
bool ext_counters;
bool ext_ifencei;
bool ext_icsr;
--
2.24.0
Re: [PATCH v38 15/22] target/avr: Add example board configuration
Yes, I did compile other platforms.
On Mon, Dec 9, 2019 at 8:24 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Sunday, December 8, 2019, Michael Rolnik wrote:
>
>> A simple board setup that configures an AVR CPU to run a given firmware
>> image.
>> This is all that's useful to implement without peripheral emulation as
>> AVR CPUs include a lot of on-board peripherals.
>>
>> NOTE: this is not a real board
>> NOTE: it's used for CPU testing
>>
>> Signed-off-by: Michael Rolnik
>> Reviewed-by: Aleksandar Markovic
>> Nacked-by: Philippe Mathieu-Daudé
>> ---
>> include/elf.h| 2 +
>> include/hw/elf_ops.h | 6 +-
>> include/hw/loader.h | 3 +-
>> hw/avr/sample.c | 293 +++
>> hw/core/loader.c | 13 +-
>> hw/Kconfig | 1 +
>> hw/avr/Kconfig | 6 +
>> hw/avr/Makefile.objs | 1 +
>> 8 files changed, 317 insertions(+), 8 deletions(-)
>> create mode 100644 hw/avr/sample.c
>> create mode 100644 hw/avr/Kconfig
>> create mode 100644 hw/avr/Makefile.objs
>>
>> diff --git a/include/elf.h b/include/elf.h
>> index 3501e0c8d0..53cdfa23b7 100644
>> --- a/include/elf.h
>> +++ b/include/elf.h
>> @@ -202,6 +202,8 @@ typedef struct mips_elf_abiflags_v0 {
>> #define EM_MOXIE 223 /* Moxie processor family */
>> #define EM_MOXIE_OLD 0xFEED
>>
>> +#define EM_AVR 83 /* AVR 8-bit microcontroller */
>> +
>> /* This is the info that is needed to parse the dynamic section of the
>> file */
>> #define DT_NULL0
>> #define DT_NEEDED 1
>> diff --git a/include/hw/elf_ops.h b/include/hw/elf_ops.h
>> index e07d276df7..9f28c16490 100644
>> --- a/include/hw/elf_ops.h
>> +++ b/include/hw/elf_ops.h
>> @@ -316,7 +316,8 @@ static int glue(load_elf, SZ)(const char *name, int
>> fd,
>>void *translate_opaque,
>>int must_swab, uint64_t *pentry,
>>uint64_t *lowaddr, uint64_t *highaddr,
>> - int elf_machine, int clear_lsb, int
>> data_swab,
>> + int elf_machine, uint32_t *pflags,
>> + int clear_lsb, int data_swab,
>>AddressSpace *as, bool load_rom,
>>symbol_fn_t sym_cb)
>
>
>>
> New parameter uint32_t *pflags should go before int elf_machine, so that
> input and output parameters are grouped together. The mane should be more
> precise, like pe_flags.
>
> But, it looks to me that you are breaking all other platforms with this
> change. Did you try full qemu build after your series is applied?
>
>
>>
>
> {
>> @@ -594,6 +595,9 @@ static int glue(load_elf, SZ)(const char *name, int
>> fd,
>> }
>> }
>>
>> +if (pflags) {
>> +*pflags = (uint32_t)(elf_sword)ehdr.e_flags;
>> +}
>> if (lowaddr)
>> *lowaddr = (uint64_t)(elf_sword)low;
>> if (highaddr)
>> diff --git a/include/hw/loader.h b/include/hw/loader.h
>> index 48a96cd559..3dbdd1868d 100644
>> --- a/include/hw/loader.h
>> +++ b/include/hw/loader.h
>> @@ -132,7 +132,8 @@ int load_elf_ram_sym(const char *filename,
>> uint64_t (*translate_fn)(void *, uint64_t),
>> void *translate_opaque, uint64_t *pentry,
>> uint64_t *lowaddr, uint64_t *highaddr, int
>> big_endian,
>> - int elf_machine, int clear_lsb, int data_swab,
>> + int elf_machine, uint32_t *pflags,
>> + int clear_lsb, int data_swab,
>> AddressSpace *as, bool load_rom, symbol_fn_t
>> sym_cb);
>>
>> /** load_elf_ram:
>> diff --git a/hw/avr/sample.c b/hw/avr/sample.c
>> new file mode 100644
>> index 00..6574733b57
>> --- /dev/null
>> +++ b/hw/avr/sample.c
>> @@ -0,0 +1,293 @@
>> +/*
>> + * QEMU AVR CPU
>> + *
>> + * Copyright (c) 2019 Michael Rolnik
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with this library; if not, see
>> + *
>> + */
>> +
>> +/*
>> + * NOTE:
>> + * This is not a real AVR board, this is an example!
>> + * The CPU is an approximation of an ATmega2560, but is missing
>> various
>> + * built-in peripherals.
>> + *
>> + * This example board loads provided binar
[PATCH v1 31/36] target/riscv: Implement second stage MMU
Signed-off-by: Alistair Francis
---
target/riscv/cpu.h| 1 +
target/riscv/cpu_helper.c | 193 ++
2 files changed, 175 insertions(+), 19 deletions(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index eb089fbdb6..b411a1f900 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -104,6 +104,7 @@ struct CPURISCVState {
target_ulong frm;
target_ulong badaddr;
+target_ulong guest_phys_fault_addr;
target_ulong priv_ver;
target_ulong misa;
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 8b234790a7..8667e5ffce 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -287,11 +287,12 @@ void riscv_cpu_set_mode(CPURISCVState *env, target_ulong
newpriv)
* @mmu_idx: Indicates current privilege level
* @first_stage: Are we in first stage translation?
* Second stage is used for hypervisor guest translation
+ * @two_stage: Are we going to perform two stage translation
*/
static int get_physical_address(CPURISCVState *env, hwaddr *physical,
int *prot, target_ulong addr,
int access_type, int mmu_idx,
-bool first_stage)
+bool first_stage, bool two_stage)
{
/* NOTE: the env->pc value visible here will not be
* correct, but the value visible to the exception handler
@@ -299,13 +300,40 @@ static int get_physical_address(CPURISCVState *env,
hwaddr *physical,
MemTxResult res;
MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
int mode = mmu_idx;
+bool use_background = false;
+/*
+ * Check if we should use the background registers for the two
+ * stage translation. We don't need to check if we actually need
+ * two stage translation as that happened before this function
+ * was called. Background registers will be used if the guest has
+ * forced a two stage translation to be on (in HS or M mode).
+ */
if (mode == PRV_M && access_type != MMU_INST_FETCH) {
if (get_field(*env->mstatus, MSTATUS_MPRV)) {
mode = get_field(*env->mstatus, MSTATUS_MPP);
+
+if (riscv_has_ext(env, RVH) &&
+get_field(*env->mstatus, MSTATUS_MPV)) {
+use_background = true;
+}
+}
+}
+
+if (mode == PRV_S && access_type != MMU_INST_FETCH &&
+riscv_has_ext(env, RVH) && !riscv_cpu_virt_enabled(env)) {
+if (get_field(env->hstatus, HSTATUS_SPRV)) {
+mode = get_field(*env->mstatus, SSTATUS_SPP);
+use_background = true;
}
}
+if (first_stage == false) {
+/* We are in stage 2 translation, this is similar to stage 1. */
+/* Stage 2 is always taken as U-mode */
+mode = PRV_U;
+}
+
if (mode == PRV_M || !riscv_feature(env, RISCV_FEATURE_MMU)) {
*physical = addr;
*prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
@@ -315,13 +343,30 @@ static int get_physical_address(CPURISCVState *env,
hwaddr *physical,
*prot = 0;
hwaddr base;
-int levels, ptidxbits, ptesize, vm, sum;
-int mxr = get_field(*env->mstatus, MSTATUS_MXR);
+int levels, ptidxbits, ptesize, vm, sum, mxr, widened;
+
+if (first_stage == true) {
+mxr = get_field(*env->mstatus, MSTATUS_MXR);
+} else {
+mxr = get_field(env->vsstatus, MSTATUS_MXR);
+}
if (env->priv_ver >= PRIV_VERSION_1_10_0) {
-base = (hwaddr)get_field(env->satp, SATP_PPN) << PGSHIFT;
+if (first_stage == true) {
+if (use_background) {
+base = (hwaddr)get_field(env->vsatp, SATP_PPN) << PGSHIFT;
+vm = get_field(env->vsatp, SATP_MODE);
+} else {
+base = (hwaddr)get_field(env->satp, SATP_PPN) << PGSHIFT;
+vm = get_field(env->satp, SATP_MODE);
+}
+widened = 0;
+} else {
+base = (hwaddr)get_field(env->hgatp, HGATP_PPN) << PGSHIFT;
+vm = get_field(env->hgatp, HGATP_MODE);
+widened = 2;
+}
sum = get_field(*env->mstatus, MSTATUS_SUM);
-vm = get_field(env->satp, SATP_MODE);
switch (vm) {
case VM_1_10_SV32:
levels = 2; ptidxbits = 10; ptesize = 4; break;
@@ -339,6 +384,7 @@ static int get_physical_address(CPURISCVState *env, hwaddr
*physical,
g_assert_not_reached();
}
} else {
+widened = 0;
base = (hwaddr)(env->sptbr) << PGSHIFT;
sum = !get_field(*env->mstatus, MSTATUS_PUM);
vm = get_field(*env->mstatus, MSTATUS_VM);
@@ -359,9 +405,16 @@ static int get_physical_address(CPURISCVState *env, hwaddr
*physical,
}
CPUState *cs = env_cpu(env);
-int va_bits = PGSHIFT + levels * ptidxbits;
-target_ulong mask = (1L << (TARGET_LONG_BITS - (va_bits - 1))) - 1;
-target_ulong masked
[PATCH v1 34/36] target/riscv: Add support for the 32-bit MSTATUSH CSR
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c| 6 ++
target/riscv/cpu.h| 7 +++
target/riscv/cpu_bits.h | 3 +++
target/riscv/cpu_helper.c | 7 +++
target/riscv/csr.c| 25 +
target/riscv/op_helper.c | 4
6 files changed, 52 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index e61cf46a73..ac8f53a49d 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -237,6 +237,9 @@ static void riscv_cpu_dump_state(CPUState *cs, FILE *f, int
flags)
#ifndef CONFIG_USER_ONLY
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mhartid ", env->mhartid);
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mstatus ", *env->mstatus);
+#ifdef TARGET_RISCV32
+qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mstatush ", *env->mstatush);
+#endif
if (riscv_has_ext(env, RVH)) {
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "hstatus ", env->hstatus);
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "vsstatus ", env->vsstatus);
@@ -473,6 +476,9 @@ static void riscv_cpu_init(Object *obj)
#ifndef CONFIG_USER_ONLY
env->mstatus = &env->mstatus_novirt;
+# ifdef TARGET_RISCV32
+env->mstatush = &env->mstatush_novirt;
+# endif
#endif
}
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index b411a1f900..84a07971dc 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -127,6 +127,10 @@ struct CPURISCVState {
target_ulong mip;
+#ifdef TARGET_RISCV32
+target_ulong *mstatush;
+#endif
+
uint32_t miclaim;
target_ulong mie;
@@ -153,6 +157,9 @@ struct CPURISCVState {
* required to handle the Hypervisor register swapping.
*/
target_ulong mstatus_novirt;
+#ifdef TARGET_RISCV32
+target_ulong mstatush_novirt;
+#endif
/* Hypervisor CSRs */
target_ulong hstatus;
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index a24654d137..049032f2ae 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -135,6 +135,9 @@
#define CSR_MTVEC 0x305
#define CSR_MCOUNTEREN 0x306
+/* 32-bit only */
+#define CSR_MSTATUSH0x310
+
/* Legacy Counter Setup (priv v1.9.1) */
/* Update to #define CSR_MCOUNTINHIBIT 0x320 for 1.11.0 */
#define CSR_MUCOUNTEREN 0x320
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index aa033b8590..c2ad0bbce7 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -938,10 +938,17 @@ void riscv_cpu_do_interrupt(CPUState *cs)
if (riscv_cpu_virt_enabled(env)) {
riscv_cpu_swap_hypervisor_regs(env);
}
+#ifdef TARGET_RISCV32
+*env->mstatush = set_field(*env->mstatush, MSTATUS_MPV,
+ riscv_cpu_virt_enabled(env));
+*env->mstatush = set_field(*env->mstatush, MSTATUS_MTL,
+ riscv_cpu_force_hs_excep_enabled(env));
+#else
*env->mstatus = set_field(*env->mstatus, MSTATUS_MPV,
riscv_cpu_virt_enabled(env));
*env->mstatus = set_field(*env->mstatus, MSTATUS_MTL,
riscv_cpu_force_hs_excep_enabled(env));
+#endif
mtval2 = env->guest_phys_fault_addr;
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index d028dfb60b..b28058f9d5 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -372,6 +372,27 @@ static int write_mstatus(CPURISCVState *env, int csrno,
target_ulong val)
return 0;
}
+#ifdef TARGET_RISCV32
+static int read_mstatush(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = *env->mstatush;
+return 0;
+}
+
+static int write_mstatush(CPURISCVState *env, int csrno, target_ulong val)
+{
+if ((val ^ *env->mstatush) & (MSTATUS_MPV)) {
+tlb_flush(env_cpu(env));
+}
+
+val &= MSTATUS_MPV | MSTATUS_MTL;
+
+*env->mstatush = val;
+
+return 0;
+}
+#endif
+
static int read_misa(CPURISCVState *env, int csrno, target_ulong *val)
{
*val = env->misa;
@@ -1215,6 +1236,10 @@ static riscv_csr_operations csr_ops[CSR_TABLE_SIZE] = {
[CSR_MTVEC] = { any, read_mtvec, write_mtvec },
[CSR_MCOUNTEREN] = { any, read_mcounteren, write_mcounteren },
+#if defined(TARGET_RISCV32)
+[CSR_MSTATUSH] ={ any, read_mstatush,write_mstatush},
+#endif
+
/* Legacy Counter Setup (priv v1.9.1) */
[CSR_MUCOUNTEREN] = { any, read_mucounteren, write_mucounteren },
[CSR_MSCOUNTEREN] = { any, read_mscounteren, write_mscounteren },
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index e5128570e6..a0a631d722 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -153,7 +153,11 @@ target_ulong helper_mret(CPURISCVState *env, target_ulong
cpu_pc_deb)
get_field(mstatus, MSTATUS_MPIE));
mstatus = set_field(mstatus, MSTATUS_MPIE, 1);
mstatus
[PATCH v1 26/36] target/riscv: Remove the hret instruction
The hret instruction does not exist in the new spec versions, so remove
it from QEMU.
Signed-off-by: Alistair Francis
---
target/riscv/insn32.decode | 1 -
target/riscv/insn_trans/trans_privileged.inc.c | 5 -
2 files changed, 6 deletions(-)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index cfd9ca6d2b..b883672e63 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -75,7 +75,6 @@ ecall 0 000 0 1110011
ebreak 0001 0 000 0 1110011
uret00000010 0 000 0 1110011
sret000100000010 0 000 0 1110011
-hret00100010 0 000 0 1110011
mret001100000010 0 000 0 1110011
wfi 000100000101 0 000 0 1110011
hfence_gvma 0110001. . 000 0 1110011 @hfence_gvma
diff --git a/target/riscv/insn_trans/trans_privileged.inc.c
b/target/riscv/insn_trans/trans_privileged.inc.c
index b9b5a89b52..76c2fad71c 100644
--- a/target/riscv/insn_trans/trans_privileged.inc.c
+++ b/target/riscv/insn_trans/trans_privileged.inc.c
@@ -58,11 +58,6 @@ static bool trans_sret(DisasContext *ctx, arg_sret *a)
#endif
}
-static bool trans_hret(DisasContext *ctx, arg_hret *a)
-{
-return false;
-}
-
static bool trans_mret(DisasContext *ctx, arg_mret *a)
{
#ifndef CONFIG_USER_ONLY
--
2.24.0
Re: [PATCH v38 18/22] target/avr: Add machine none test
:)
no idea. all other machines / CPUs have it, so I added as well
On Mon, Dec 9, 2019 at 8:13 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Sunday, December 8, 2019, Michael Rolnik wrote:
>
>> Signed-off-by: Michael Rolnik
>> Tested-by: Philippe Mathieu-Daudé
>> Reviewed-by: Aleksandar Markovic
>> ---
>> tests/machine-none-test.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>>
> You need to add a commit message explaining how adding a test is achieved
> with this single line.
>
>
>
>> diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
>> index 5953d31755..3e5c74e73e 100644
>> --- a/tests/machine-none-test.c
>> +++ b/tests/machine-none-test.c
>> @@ -27,6 +27,7 @@ static struct arch2cpu cpus_map[] = {
>> /* tested targets list */
>> { "arm", "cortex-a15" },
>> { "aarch64", "cortex-a57" },
>> +{ "avr", "avr6-avr-cpu" },
>> { "x86_64", "qemu64,apic-id=0" },
>> { "i386", "qemu32,apic-id=0" },
>> { "alpha", "ev67" },
>> --
>> 2.17.2 (Apple Git-113)
>>
>>
--
Best Regards,
Michael Rolnik
[PATCH v1 28/36] target/riscv: Mark both sstatus and vsstatus as dirty
Mark both sstatus and vsstatus as dirty (3).
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
target/riscv/translate.c | 12
1 file changed, 12 insertions(+)
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 1a379bd2ae..1d879b34db 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -44,6 +44,7 @@ typedef struct DisasContext {
/* pc_succ_insn points to the instruction following base.pc_next */
target_ulong pc_succ_insn;
target_ulong priv_ver;
+bool virt_enabled;
uint32_t opcode;
uint32_t mstatus_fs;
uint32_t misa;
@@ -396,6 +397,12 @@ static void mark_fs_dirty(DisasContext *ctx)
tcg_gen_ld_tl(tmp, cpu_env, offsetof(CPURISCVState, mstatus));
tcg_gen_ori_tl(tmp, tmp, MSTATUS_FS);
tcg_gen_st_tl(tmp, cpu_env, offsetof(CPURISCVState, mstatus));
+
+if (ctx->virt_enabled) {
+tcg_gen_ld_tl(tmp, cpu_env, offsetof(CPURISCVState, vsstatus));
+tcg_gen_ori_tl(tmp, tmp, MSTATUS_FS);
+tcg_gen_st_tl(tmp, cpu_env, offsetof(CPURISCVState, vsstatus));
+}
tcg_temp_free(tmp);
}
#else
@@ -740,6 +747,11 @@ static void riscv_tr_init_disas_context(DisasContextBase
*dcbase, CPUState *cs)
ctx->mem_idx = ctx->base.tb->flags & TB_FLAGS_MMU_MASK;
ctx->mstatus_fs = ctx->base.tb->flags & TB_FLAGS_MSTATUS_FS;
ctx->priv_ver = env->priv_ver;
+#if !defined(CONFIG_USER_ONLY)
+ctx->virt_enabled = riscv_cpu_virt_enabled(env);
+#else
+ctx->virt_enabled = false;
+#endif
ctx->misa = env->misa;
ctx->frm = -1; /* unknown rounding mode */
ctx->ext_ifencei = cpu->cfg.ext_ifencei;
--
2.24.0
[PATCH v1 30/36] target/riscv: Allow specifying MMU stage
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 39 ++-
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 2040fc0208..8b234790a7 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -279,10 +279,19 @@ void riscv_cpu_set_mode(CPURISCVState *env, target_ulong
newpriv)
*
* Adapted from Spike's mmu_t::translate and mmu_t::walk
*
+ * @env: CPURISCVState
+ * @physical: This will be set to the calculated physical address
+ * @prot: The returned protection attributes
+ * @addr: The virtual address to be translated
+ * @access_type: The type of MMU access
+ * @mmu_idx: Indicates current privilege level
+ * @first_stage: Are we in first stage translation?
+ * Second stage is used for hypervisor guest translation
*/
static int get_physical_address(CPURISCVState *env, hwaddr *physical,
int *prot, target_ulong addr,
-int access_type, int mmu_idx)
+int access_type, int mmu_idx,
+bool first_stage)
{
/* NOTE: the env->pc value visible here will not be
* correct, but the value visible to the exception handler
@@ -485,13 +494,23 @@ restart:
}
static void raise_mmu_exception(CPURISCVState *env, target_ulong address,
-MMUAccessType access_type, bool pmp_violation)
+MMUAccessType access_type, bool pmp_violation,
+bool first_stage)
{
CPUState *cs = env_cpu(env);
-int page_fault_exceptions =
-(env->priv_ver >= PRIV_VERSION_1_10_0) &&
-get_field(env->satp, SATP_MODE) != VM_1_10_MBARE &&
-!pmp_violation;
+int page_fault_exceptions;
+if (first_stage) {
+page_fault_exceptions =
+(env->priv_ver >= PRIV_VERSION_1_10_0) &&
+get_field(env->satp, SATP_MODE) != VM_1_10_MBARE &&
+!pmp_violation;
+riscv_cpu_set_force_hs_excep(env, 0);
+} else {
+page_fault_exceptions =
+get_field(env->hgatp, HGATP_MODE) != VM_1_10_MBARE &&
+!pmp_violation;
+riscv_cpu_set_force_hs_excep(env, 1);
+}
switch (access_type) {
case MMU_INST_FETCH:
cs->exception_index = page_fault_exceptions ?
@@ -518,7 +537,8 @@ hwaddr riscv_cpu_get_phys_page_debug(CPUState *cs, vaddr
addr)
int prot;
int mmu_idx = cpu_mmu_index(&cpu->env, false);
-if (get_physical_address(&cpu->env, &phys_addr, &prot, addr, 0, mmu_idx)) {
+if (get_physical_address(&cpu->env, &phys_addr, &prot, addr, 0, mmu_idx,
+ true)) {
return -1;
}
return phys_addr;
@@ -583,7 +603,8 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int
size,
qemu_log_mask(CPU_LOG_MMU, "%s ad %" VADDR_PRIx " rw %d mmu_idx %d\n",
__func__, address, access_type, mmu_idx);
-ret = get_physical_address(env, &pa, &prot, address, access_type, mmu_idx);
+ret = get_physical_address(env, &pa, &prot, address, access_type, mmu_idx,
+ true);
if (mode == PRV_M && access_type != MMU_INST_FETCH) {
if (get_field(*env->mstatus, MSTATUS_MPRV)) {
@@ -610,7 +631,7 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int
size,
} else if (probe) {
return false;
} else {
-raise_mmu_exception(env, address, access_type, pmp_violation);
+raise_mmu_exception(env, address, access_type, pmp_violation, true);
riscv_raise_exception(env, cs->exception_index, retaddr);
}
#else
--
2.24.0
[PATCH v1 25/36] target/riscv: Add hfence instructions
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
target/riscv/insn32.decode| 23 ++-
.../riscv/insn_trans/trans_privileged.inc.c | 40 +++
2 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 77f794ed70..cfd9ca6d2b 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -63,20 +63,25 @@
@r2_rm ... . . ... . ... %rs1 %rm %rd
@r2 ... . . ... . ... %rs1 %rd
+@hfence_gvma ... . . ... . ... %rs2 %rs1
+@hfence_bvma ... . . ... . ... %rs2 %rs1
+
@sfence_vma ... . . ... . ... %rs2 %rs1
@sfence_vm ... . . ... . ... %rs1
# *** Privileged Instructions ***
-ecall 0 000 0 1110011
-ebreak 0001 0 000 0 1110011
-uret 00000010 0 000 0 1110011
-sret 000100000010 0 000 0 1110011
-hret 00100010 0 000 0 1110011
-mret 001100000010 0 000 0 1110011
-wfi000100000101 0 000 0 1110011
-sfence_vma 0001001. . 000 0 1110011 @sfence_vma
-sfence_vm 000100000100 . 000 0 1110011 @sfence_vm
+ecall 0 000 0 1110011
+ebreak 0001 0 000 0 1110011
+uret00000010 0 000 0 1110011
+sret000100000010 0 000 0 1110011
+hret00100010 0 000 0 1110011
+mret001100000010 0 000 0 1110011
+wfi 000100000101 0 000 0 1110011
+hfence_gvma 0110001. . 000 0 1110011 @hfence_gvma
+hfence_bvma 0010001. . 000 0 1110011 @hfence_bvma
+sfence_vma 0001001. . 000 0 1110011 @sfence_vma
+sfence_vm 000100000100 . 000 0 1110011 @sfence_vm
# *** RV32I Base Instruction Set ***
lui . 0110111 @u
diff --git a/target/riscv/insn_trans/trans_privileged.inc.c
b/target/riscv/insn_trans/trans_privileged.inc.c
index c5e4b3e49a..b9b5a89b52 100644
--- a/target/riscv/insn_trans/trans_privileged.inc.c
+++ b/target/riscv/insn_trans/trans_privileged.inc.c
@@ -108,3 +108,43 @@ static bool trans_sfence_vm(DisasContext *ctx,
arg_sfence_vm *a)
#endif
return false;
}
+
+static bool trans_hfence_gvma(DisasContext *ctx, arg_sfence_vma *a)
+{
+#ifndef CONFIG_USER_ONLY
+if (ctx->priv_ver >= PRIV_VERSION_1_10_0 &&
+has_ext(ctx, RVH)) {
+/* Hpervisor extensions exist */
+/*
+ * if (env->priv == PRV_M ||
+ * (env->priv == PRV_S &&
+ *!riscv_cpu_virt_enabled(env) &&
+ *get_field(ctx->mstatus_fs, MSTATUS_TVM))) {
+ */
+gen_helper_tlb_flush(cpu_env);
+return true;
+/* } */
+}
+#endif
+return false;
+}
+
+static bool trans_hfence_bvma(DisasContext *ctx, arg_sfence_vma *a)
+{
+#ifndef CONFIG_USER_ONLY
+if (ctx->priv_ver >= PRIV_VERSION_1_10_0 &&
+has_ext(ctx, RVH)) {
+/* Hpervisor extensions exist */
+/*
+ * if (env->priv == PRV_M ||
+ * (env->priv == PRV_S &&
+ *!riscv_cpu_virt_enabled(env) &&
+ *get_field(ctx->mstatus_fs, MSTATUS_TVM))) {
+ */
+gen_helper_tlb_flush(cpu_env);
+return true;
+/* } */
+}
+#endif
+return false;
+}
--
2.24.0
Re: [for-5.0 PATCH v2 3/3] cpu: Use cpu_class_set_parent_reset()
On Mon, 09 Dec 2019 18:55:30 +0100 Greg Kurz wrote: > Convert all targets to use cpu_class_set_parent_reset() with the following > coccinelle script: > > @@ > type CPUParentClass; > CPUParentClass *pcc; > CPUClass *cc; > identifier parent_fn; > identifier child_fn; > @@ > +cpu_class_set_parent_reset(cc, child_fn, &pcc->parent_fn); > -pcc->parent_fn = cc->reset; > ... > -cc->reset = child_fn; > > Signed-off-by: Greg Kurz > Acked-by: David Gibson > Reviewed-by: Alistair Francis > --- > target/arm/cpu.c|3 +-- > target/cris/cpu.c |3 +-- > target/i386/cpu.c |3 +-- > target/lm32/cpu.c |3 +-- > target/m68k/cpu.c |3 +-- > target/microblaze/cpu.c |3 +-- > target/mips/cpu.c |3 +-- > target/moxie/cpu.c |3 +-- > target/nios2/cpu.c |3 +-- > target/openrisc/cpu.c |3 +-- > target/ppc/translate_init.inc.c |3 +-- > target/riscv/cpu.c |3 +-- > target/s390x/cpu.c |3 +-- > target/sh4/cpu.c|3 +-- > target/sparc/cpu.c |3 +-- > target/tilegx/cpu.c |3 +-- > target/tricore/cpu.c|3 +-- > target/xtensa/cpu.c |3 +-- > 18 files changed, 18 insertions(+), 36 deletions(-) Reviewed-by: Cornelia Huck
[PATCH v1 21/36] target/ricsv: Flush the TLB on virtulisation mode changes
To ensure our TLB isn't out-of-date we flush it on all virt mode
changes. Unlike priv mode this isn't saved in the mmu_idx as all
guests share V=1. The easiest option is just to flush on all changes.
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
target/riscv/cpu_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 85eed5d885..1b747abf93 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -183,6 +183,11 @@ void riscv_cpu_set_virt_enabled(CPURISCVState *env, bool
enable)
return;
}
+/* Flush the TLB on all virt mode changes. */
+if (get_field(env->virt, VIRT_ONOFF) != enable) {
+tlb_flush(env_cpu(env));
+}
+
env->virt = set_field(env->virt, VIRT_ONOFF, enable);
}
--
2.24.0
[PATCH v1 24/36] target/riscv: Add Hypervisor trap return support
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
target/riscv/op_helper.c | 66
1 file changed, 54 insertions(+), 12 deletions(-)
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index beb34e705b..e5128570e6 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -73,6 +73,8 @@ target_ulong helper_csrrc(CPURISCVState *env, target_ulong
src,
target_ulong helper_sret(CPURISCVState *env, target_ulong cpu_pc_deb)
{
+target_ulong prev_priv, prev_virt, mstatus;
+
if (!(env->priv >= PRV_S)) {
riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC());
}
@@ -87,16 +89,46 @@ target_ulong helper_sret(CPURISCVState *env, target_ulong
cpu_pc_deb)
riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC());
}
-target_ulong mstatus = *env->mstatus;
-target_ulong prev_priv = get_field(mstatus, MSTATUS_SPP);
-mstatus = set_field(mstatus,
-env->priv_ver >= PRIV_VERSION_1_10_0 ?
-MSTATUS_SIE : MSTATUS_UIE << prev_priv,
-get_field(mstatus, MSTATUS_SPIE));
-mstatus = set_field(mstatus, MSTATUS_SPIE, 0);
-mstatus = set_field(mstatus, MSTATUS_SPP, PRV_U);
+mstatus = *env->mstatus;
+
+if (riscv_has_ext(env, RVH) && !riscv_cpu_virt_enabled(env)) {
+/* We support Hypervisor extensions and virtulisation is disabled */
+target_ulong hstatus = env->hstatus;
+
+prev_priv = get_field(mstatus, MSTATUS_SPP);
+prev_virt = get_field(hstatus, HSTATUS_SPV);
+
+hstatus = set_field(hstatus, HSTATUS_SPV,
+ get_field(hstatus, HSTATUS_SP2V));
+mstatus = set_field(mstatus, MSTATUS_SPP,
+get_field(hstatus, HSTATUS_SP2P));
+hstatus = set_field(hstatus, HSTATUS_SP2V, 0);
+hstatus = set_field(hstatus, HSTATUS_SP2P, 0);
+mstatus = set_field(mstatus, SSTATUS_SIE,
+get_field(mstatus, SSTATUS_SPIE));
+mstatus = set_field(mstatus, SSTATUS_SPIE, 1);
+
+*env->mstatus = mstatus;
+env->hstatus = hstatus;
+
+if (prev_virt) {
+riscv_cpu_swap_hypervisor_regs(env);
+}
+
+riscv_cpu_set_virt_enabled(env, prev_virt);
+} else {
+prev_priv = get_field(mstatus, MSTATUS_SPP);
+
+mstatus = set_field(mstatus,
+env->priv_ver >= PRIV_VERSION_1_10_0 ?
+MSTATUS_SIE : MSTATUS_UIE << prev_priv,
+get_field(mstatus, MSTATUS_SPIE));
+mstatus = set_field(mstatus, MSTATUS_SPIE, 0);
+mstatus = set_field(mstatus, MSTATUS_SPP, PRV_U);
+*env->mstatus = mstatus;
+}
+
riscv_cpu_set_mode(env, prev_priv);
-*env->mstatus = mstatus;
return retpc;
}
@@ -114,14 +146,24 @@ target_ulong helper_mret(CPURISCVState *env, target_ulong
cpu_pc_deb)
target_ulong mstatus = *env->mstatus;
target_ulong prev_priv = get_field(mstatus, MSTATUS_MPP);
+target_ulong prev_virt = get_field(mstatus, MSTATUS_MPV);
mstatus = set_field(mstatus,
env->priv_ver >= PRIV_VERSION_1_10_0 ?
MSTATUS_MIE : MSTATUS_UIE << prev_priv,
get_field(mstatus, MSTATUS_MPIE));
-mstatus = set_field(mstatus, MSTATUS_MPIE, 0);
-mstatus = set_field(mstatus, MSTATUS_MPP, PRV_U);
-riscv_cpu_set_mode(env, prev_priv);
+mstatus = set_field(mstatus, MSTATUS_MPIE, 1);
+mstatus = set_field(mstatus, MSTATUS_MPP, 0);
+mstatus = set_field(mstatus, MSTATUS_MPV, 0);
*env->mstatus = mstatus;
+riscv_cpu_set_mode(env, prev_priv);
+
+if (riscv_has_ext(env, RVH)) {
+if (prev_virt) {
+riscv_cpu_swap_hypervisor_regs(env);
+}
+
+riscv_cpu_set_virt_enabled(env, prev_virt);
+}
return retpc;
}
--
2.24.0
[PATCH v1 23/36] target/riscv: Add hypvervisor trap support
Signed-off-by: Alistair Francis
Reviewed-by: Palmer Dabbelt
---
target/riscv/cpu_helper.c | 65 +--
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 1b747abf93..2c6d2bc3a3 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -641,6 +641,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
RISCVCPU *cpu = RISCV_CPU(cs);
CPURISCVState *env = &cpu->env;
+target_ulong s;
/* cs->exception is 32-bits wide unlike mcause which is XLEN-bits wide
* so we mask off the MSB and separate into trap type and cause.
@@ -650,13 +651,6 @@ void riscv_cpu_do_interrupt(CPUState *cs)
target_ulong deleg = async ? env->mideleg : env->medeleg;
target_ulong tval = 0;
-static const int ecall_cause_map[] = {
-[PRV_U] = RISCV_EXCP_U_ECALL,
-[PRV_S] = RISCV_EXCP_S_ECALL,
-[PRV_H] = RISCV_EXCP_VS_ECALL,
-[PRV_M] = RISCV_EXCP_M_ECALL
-};
-
if (!async) {
/* set tval to badaddr for traps with address information */
switch (cause) {
@@ -680,7 +674,16 @@ void riscv_cpu_do_interrupt(CPUState *cs)
/* ecall is dispatched as one cause so translate based on mode */
if (cause == RISCV_EXCP_U_ECALL) {
assert(env->priv <= 3);
-cause = ecall_cause_map[env->priv];
+
+if (env->priv == PRV_M) {
+cause = RISCV_EXCP_M_ECALL;
+} else if (env->priv == PRV_S && riscv_cpu_virt_enabled(env)) {
+cause = RISCV_EXCP_VS_ECALL;
+} else if (env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) {
+cause = RISCV_EXCP_S_ECALL;
+} else if (env->priv == PRV_U) {
+cause = RISCV_EXCP_U_ECALL;
+}
}
}
@@ -690,7 +693,36 @@ void riscv_cpu_do_interrupt(CPUState *cs)
if (env->priv <= PRV_S &&
cause < TARGET_LONG_BITS && ((deleg >> cause) & 1)) {
/* handle the trap in S-mode */
-target_ulong s = *env->mstatus;
+if (riscv_has_ext(env, RVH)) {
+target_ulong hdeleg = async ? env->hideleg : env->hedeleg;
+
+if (riscv_cpu_virt_enabled(env) && ((hdeleg >> cause) & 1) &&
+!riscv_cpu_force_hs_excep_enabled(env)) {
+/* Trap to VS mode */
+} else if (riscv_cpu_virt_enabled(env)) {
+/* Trap into HS mode, from virt */
+riscv_cpu_swap_hypervisor_regs(env);
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2V,
+ get_field(env->hstatus, HSTATUS_SPV));
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2P,
+ get_field(*env->mstatus,
SSTATUS_SPP));
+env->hstatus = set_field(env->hstatus, HSTATUS_SPV,
+ riscv_cpu_virt_enabled(env));
+
+riscv_cpu_set_virt_enabled(env, 0);
+riscv_cpu_set_force_hs_excep(env, 0);
+} else {
+/* Trap into HS mode */
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2V,
+ get_field(env->hstatus, HSTATUS_SPV));
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2P,
+ get_field(*env->mstatus,
SSTATUS_SPP));
+env->hstatus = set_field(env->hstatus, HSTATUS_SPV,
+ riscv_cpu_virt_enabled(env));
+}
+}
+
+s = *env->mstatus;
s = set_field(s, MSTATUS_SPIE, env->priv_ver >= PRIV_VERSION_1_10_0 ?
get_field(s, MSTATUS_SIE) : get_field(s, MSTATUS_UIE <<
env->priv));
s = set_field(s, MSTATUS_SPP, env->priv);
@@ -704,7 +736,20 @@ void riscv_cpu_do_interrupt(CPUState *cs)
riscv_cpu_set_mode(env, PRV_S);
} else {
/* handle the trap in M-mode */
-target_ulong s = *env->mstatus;
+if (riscv_has_ext(env, RVH)) {
+if (riscv_cpu_virt_enabled(env)) {
+riscv_cpu_swap_hypervisor_regs(env);
+}
+*env->mstatus = set_field(*env->mstatus, MSTATUS_MPV,
+ riscv_cpu_virt_enabled(env));
+*env->mstatus = set_field(*env->mstatus, MSTATUS_MTL,
+ riscv_cpu_force_hs_excep_enabled(env));
+
+/* Trapping to M mode, virt is disabled */
+riscv_cpu_set_virt_enabled(env, 0);
+}
+
+s = *env->mstatus;
s = set_field(s, MSTATUS_MPIE, env->priv_ver >= PRIV_VERSION_1_10_0 ?
get_field(s, MSTATUS_MIE) : get_field(s, MSTATUS_UIE <<
env->priv));
s = set_field(s, MSTATUS_MPP, env->priv);
--
2.24.0
