date:20210707

This provides standard look and feel for the about panel and reduces
code.

Signed-off-by: Akihiko Odaki 
---
 ui/cocoa.m | 111 +++--
 1 file changed, 23 insertions(+), 88 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 9f72844b079..3e1ae24739a 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -83,7 +83,7 @@ static void cocoa_switch(DisplayChangeListener *dcl,
 
 static void cocoa_refresh(DisplayChangeListener *dcl);
 
-static NSWindow *normalWindow, *about_window;
+static NSWindow *normalWindow;
 static const DisplayChangeListenerOps dcl_ops = {
 .dpy_name  = "cocoa",
 .dpy_gfx_update = cocoa_update,
@@ -1115,7 +1115,6 @@ - (void)changeDeviceMedia:(id)sender;
 - (BOOL)verifyQuit;
 - (void)openDocumentation:(NSString *)filename;
 - (IBAction) do_about_menu_item: (id) sender;
-- (void)make_about_window;
 - (void)adjustSpeed:(id)sender;
 @end
 
@@ -1166,7 +1165,6 @@ - (id) init
 supportedImageFileTypes = [NSArray arrayWithObjects: @"img", @"iso", 
@"dmg",
  @"qcow", @"qcow2", @"cloop", @"vmdk", @"cdr",
   @"toast", nil];
-[self make_about_window];
 }
 return self;
 }
@@ -1451,92 +1449,29 @@ - (BOOL)verifyQuit
 /* The action method for the About menu item */
 - (IBAction) do_about_menu_item: (id) sender
 {
-[about_window makeKeyAndOrderFront: nil];
-}
-
-/* Create and display the about dialog */
-- (void)make_about_window
-{
-/* Make the window */
-int x = 0, y = 0, about_width = 400, about_height = 200;
-NSRect window_rect = NSMakeRect(x, y, about_width, about_height);
-about_window = [[NSWindow alloc] initWithContentRect:window_rect
-styleMask:NSWindowStyleMaskTitled | 
NSWindowStyleMaskClosable |
-NSWindowStyleMaskMiniaturizable
-backing:NSBackingStoreBuffered
-defer:NO];
-[about_window setTitle: @"About"];
-[about_window setReleasedWhenClosed: NO];
-[about_window center];
-NSView *superView = [about_window contentView];
-
-/* Create the dimensions of the picture */
-int picture_width = 80, picture_height = 80;
-x = (about_width - picture_width)/2;
-y = about_height - picture_height - 10;
-NSRect picture_rect = NSMakeRect(x, y, picture_width, picture_height);
-
-/* Make the picture of QEMU */
-NSImageView *picture_view = [[NSImageView alloc] initWithFrame:
- picture_rect];
-char *qemu_image_path_c = get_relocated_path(CONFIG_QEMU_ICONDIR 
"/hicolor/512x512/apps/qemu.png");
-NSString *qemu_image_path = [NSString 
stringWithUTF8String:qemu_image_path_c];
-g_free(qemu_image_path_c);
-NSImage *qemu_image = [[NSImage alloc] 
initWithContentsOfFile:qemu_image_path];
-[picture_view setImage: qemu_image];
-[picture_view setImageScaling: NSImageScaleProportionallyUpOrDown];
-[superView addSubview: picture_view];
-
-/* Make the name label */
-NSBundle *bundle = [NSBundle mainBundle];
-if (bundle) {
-x = 0;
-y = y - 25;
-int name_width = about_width, name_height = 20;
-NSRect name_rect = NSMakeRect(x, y, name_width, name_height);
-NSTextField *name_label = [[NSTextField alloc] initWithFrame: 
name_rect];
-[name_label setEditable: NO];
-[name_label setBezeled: NO];
-[name_label setDrawsBackground: NO];
-[name_label setAlignment: NSTextAlignmentCenter];
-NSString *qemu_name = [[bundle executablePath] lastPathComponent];
-[name_label setStringValue: qemu_name];
-[superView addSubview: name_label];
+NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
+char *icon_path_c = get_relocated_path(CONFIG_QEMU_ICONDIR 
"/hicolor/512x512/apps/qemu.png");
+NSString *icon_path = [NSString stringWithUTF8String:icon_path_c];
+g_free(icon_path_c);
+NSImage *icon = [[NSImage alloc] initWithContentsOfFile:icon_path];
+NSString *version = @"QEMU emulator version " QEMU_FULL_VERSION;
+NSString *copyright = @QEMU_COPYRIGHT;
+NSDictionary *options;
+if (icon) {
+options = @{
+NSAboutPanelOptionApplicationIcon : icon,
+NSAboutPanelOptionApplicationVersion : version,
+@"Copyright" : copyright,
+};
+[icon release];
+} else {
+options = @{
+NSAboutPanelOptionApplicationVersion : version,
+@"Copyright" : copyright,
+};
 }
-
-/* Set the version label's attributes */
-x = 0;
-y = 50;
-int version_width = about_width, version_height = 20;
-NSRect version_rect = NSMakeRect(x, y, version_width, version_height);
-NSTextField *version_label = [[NSTextField alloc] initWithFrame:
-  version_rect];
-[version_label setEditable: NO];
-

[PATCH] ui/cocoa: Do not perform unsafe cast of argv

Signed-off-by: Akihiko Odaki 
---
 ui/cocoa.m | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 9f72844b079..68a6302184a 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -1888,12 +1888,12 @@ static void cocoa_clipboard_request(QemuClipboardInfo 
*info,
 exit(status);
 }
 
-int main (int argc, const char * argv[]) {
+int main (int argc, char **argv) {
 QemuThread thread;
 
 COCOA_DEBUG("Entered main()\n");
 gArgc = argc;
-gArgv = (char **)argv;
+gArgv = argv;
 
 qemu_sem_init(_init_sem, 0);
 qemu_sem_init(_started_sem, 0);
-- 
2.30.1 (Apple Git-130)

[PATCH v3] net/macos: implement vmnet-based netdev

From: Phillip Tennen 

This patch implements a new netdev device, reachable via -netdev
vmnet-macos, that’s backed by macOS’s vmnet framework.

The vmnet framework provides native bridging support, and its usage in
this patch is intended as a replacement for attempts to use a tap device
via the tuntaposx kernel extension. Notably, the tap/tuntaposx approach
never would have worked in the first place, as QEMU interacts with the
tap device via poll(), and macOS does not support polling device files.

vmnet requires either a special entitlement, granted via a provisioning
profile, or root access. Otherwise attempts to create the virtual
interface will fail with a “generic error” status code. QEMU may not
currently be signed with an entitlement granted in a provisioning
profile, as this would necessitate pre-signed binary build distribution,
rather than source-code distribution. As such, using this netdev
currently requires that qemu be run with root access. I’ve opened a
feedback report with Apple to allow the use of the relevant entitlement
with this use case:
https://openradar.appspot.com/radar?id=5007417364447232

vmnet offers three operating modes, all of which are supported by this
patch via the “mode=host|shared|bridge” option:

* "Host" mode: Allows the vmnet interface to communicate with other
* vmnet
interfaces that are in host mode and also with the native host.
* "Shared" mode: Allows traffic originating from the vmnet interface to
reach the Internet through a NAT. The vmnet interface can also
communicate with the native host.
* "Bridged" mode: Bridges the vmnet interface with a physical network
interface.

Each of these modes also provide some extra configuration that’s
supported by this patch:

* "Bridged" mode: The user may specify the physical interface to bridge
with. Defaults to en0.
* "Host" mode / "Shared" mode: The user may specify the DHCP range and
subnet. Allocated by vmnet if not provided.

vmnet also offers some extra configuration options that are not
supported by this patch:

* Enable isolation from other VMs using vmnet
* Port forwarding rules
* Enabling TCP segmentation offload
* Only applicable in "shared" mode: specifying the NAT IPv6 prefix
* Only available in "host" mode: specifying the IP address for the VM
within an isolated network

Note that this patch requires macOS 10.15 as a minimum, as this is when
bridging support was implemented in vmnet.framework.

Rebased to commit 9aef0954195cc592e86846dbbe7f3c2c5603690a by Akihiko
Odaki.

Signed-off-by: Phillip Tennen 
Signed-off-by: Akihiko Odaki 
Message-Id: <20210315103209.20870-1-akihiko.od...@gmail.com>
---
 meson.build   |   3 +
 net/clients.h |   5 +
 net/meson.build   |   1 +
 net/net.c |   3 +
 net/vmnet-macos.c | 447 ++
 qapi/net.json | 120 -
 qemu-options.hx   |   9 +
 7 files changed, 586 insertions(+), 2 deletions(-)
 create mode 100644 net/vmnet-macos.c

diff --git a/meson.build b/meson.build
index b9a9b2120fe..0d2ceaa880e 100644
--- a/meson.build
+++ b/meson.build
@@ -178,6 +178,7 @@ socket = []
 version_res = []
 coref = []
 iokit = []
+vmnet = not_found
 emulator_link_args = []
 nvmm =not_found
 hvf = not_found
@@ -192,6 +193,7 @@ if targetos == 'windows'
 elif targetos == 'darwin'
   coref = dependency('appleframeworks', modules: 'CoreFoundation')
   iokit = dependency('appleframeworks', modules: 'IOKit', required: false)
+  vmnet = dependency('appleframeworks', modules: 'vmnet')
 elif targetos == 'sunos'
   socket = [cc.find_library('socket'),
 cc.find_library('nsl'),
@@ -1259,6 +1261,7 @@ config_host_data.set('CONFIG_FUSE', fuse.found())
 config_host_data.set('CONFIG_FUSE_LSEEK', fuse_lseek.found())
 config_host_data.set('CONFIG_X11', x11.found())
 config_host_data.set('CONFIG_CFI', get_option('cfi'))
+config_host_data.set('CONFIG_VMNET', vmnet.found())
 config_host_data.set('QEMU_VERSION', '"@0@"'.format(meson.project_version()))
 config_host_data.set('QEMU_VERSION_MAJOR', 
meson.project_version().split('.')[0])
 config_host_data.set('QEMU_VERSION_MINOR', 
meson.project_version().split('.')[1])
diff --git a/net/clients.h b/net/clients.h
index 92f9b59aedc..2c2af67f82a 100644
--- a/net/clients.h
+++ b/net/clients.h
@@ -63,4 +63,9 @@ int net_init_vhost_user(const Netdev *netdev, const char 
*name,
 
 int net_init_vhost_vdpa(const Netdev *netdev, const char *name,
 NetClientState *peer, Error **errp);
+
+#ifdef CONFIG_VMNET
+int net_init_vmnet_macos(const Netdev *netdev, const char *name,
+NetClientState *peer, Error **errp);
+#endif
 #endif /* QEMU_NET_CLIENTS_H */
diff --git a/net/meson.build b/net/meson.build
index 1076b0a7ab4..ba6a5b7fa0b 100644
--- a/net/meson.build
+++ b/net/meson.build
@@ -37,5 +37,6 @@ endif
 softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files(tap_posix))
 softmmu_ss.add(when: 'CONFIG_WIN32', if_true: files('tap-win32.c'))
 softmmu_ss.add(when:

Re: Picture missing in About dialog on cocoa ui

Hi,

My installation correctly shows the picture. Please make sure you
install it and run the installed binary (not the binary located in the
build directory). The new code should work reliably once you install
it while the old code may or may not work depending on how you execute
the binary.

Regards,
Akihiko Odaki

On Thu, Jul 8, 2021 at 2:00 AM Programmingkid  wrote:
>
> Hello, now that the code to add the icon to QEMU has been restored for Mac 
> OS, I think it is time to revert patch 
> e31746ecf8dd2f25f687c94ac14016a3ba5debfc. This patch was made to fix the 
> missing icon in the About dialog but it doesn't seem to work any more. I do 
> not see a picture in the About dialog on Mac OS 11.1. The easiest fix for 
> this issue is to revert the mentioned patch. When I ran
> 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' the picture in the 
> About dialog appeared again.

Re: [PATCH v2 4/4] hw/nvme: fix controller hot unplugging

2021-07-07 Thread Klaus Jensen


On Jul  7 18:56, Klaus Jensen wrote:

On Jul  7 17:57, Hannes Reinecke wrote:

On 7/7/21 5:49 PM, Klaus Jensen wrote:

From: Klaus Jensen 

Prior to this patch the nvme-ns devices are always children of the
NvmeBus owned by the NvmeCtrl. This causes the namespaces to be
unrealized when the parent device is removed. However, when subsystems
are involved, this is not what we want since the namespaces may be
attached to other controllers as well.

This patch adds an additional NvmeBus on the subsystem device. When
nvme-ns devices are realized, if the parent controller device is linked
to a subsystem, the parent bus is set to the subsystem one instead. This
makes sure that namespaces are kept alive and not unrealized.

Signed-off-by: Klaus Jensen 
---
hw/nvme/nvme.h   | 15 ---
hw/nvme/ctrl.c   | 14 ++
hw/nvme/ns.c | 18 ++
hw/nvme/subsys.c |  3 +++
4 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/hw/nvme/nvme.h b/hw/nvme/nvme.h
index c4065467d877..83ffabade4cf 100644
--- a/hw/nvme/nvme.h
+++ b/hw/nvme/nvme.h
@@ -33,12 +33,20 @@ QEMU_BUILD_BUG_ON(NVME_MAX_NAMESPACES > NVME_NSID_BROADCAST 
- 1);
typedef struct NvmeCtrl NvmeCtrl;
typedef struct NvmeNamespace NvmeNamespace;
+#define TYPE_NVME_BUS "nvme-bus"
+OBJECT_DECLARE_SIMPLE_TYPE(NvmeBus, NVME_BUS)
+
+typedef struct NvmeBus {
+BusState parent_bus;
+} NvmeBus;
+
#define TYPE_NVME_SUBSYS "nvme-subsys"
#define NVME_SUBSYS(obj) \
OBJECT_CHECK(NvmeSubsystem, (obj), TYPE_NVME_SUBSYS)
typedef struct NvmeSubsystem {
DeviceState parent_obj;
+NvmeBus bus;
uint8_t subnqn[256];
NvmeCtrl  *ctrls[NVME_MAX_CONTROLLERS];
@@ -365,13 +373,6 @@ typedef struct NvmeCQueue {
QTAILQ_HEAD(, NvmeRequest) req_list;
} NvmeCQueue;
-#define TYPE_NVME_BUS "nvme-bus"
-#define NVME_BUS(obj) OBJECT_CHECK(NvmeBus, (obj), TYPE_NVME_BUS)
-
-typedef struct NvmeBus {
-BusState parent_bus;
-} NvmeBus;
-
#define TYPE_NVME "nvme"
#define NVME(obj) \
OBJECT_CHECK(NvmeCtrl, (obj), TYPE_NVME)
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index 90e3ee2b70ee..9a3b3a27c293 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -6514,16 +6514,14 @@ static void nvme_exit(PCIDevice *pci_dev)
nvme_ctrl_reset(n);
-for (i = 1; i <= NVME_MAX_NAMESPACES; i++) {
-ns = nvme_ns(n, i);
-if (!ns) {
-continue;
+if (n->subsys) {
+for (i = 1; i <= NVME_MAX_NAMESPACES; i++) {
+ns = nvme_ns(n, i);
+if (ns) {
+ns->attached--;
+}
}
-nvme_ns_cleanup(ns);


So who is removing the namespaces, then?
I would have expected some cleanup action from the subsystem, seeing 
that we reparent to that ...




Since we "move" the namespaces to the subsystem, and since the 
subsystem is non-hotpluggable, they will (and can) not be removed. In 
the case that there is no subsystem, nvme_ns_unrealize() will be 
called for each child namespace on the controller NvmeBus.



-}
-
-if (n->subsys) {
nvme_subsys_unregister_ctrl(n->subsys, n);
}
diff --git a/hw/nvme/ns.c b/hw/nvme/ns.c
index 3c4f5b8c714a..b7cf1494e75b 100644
--- a/hw/nvme/ns.c
+++ b/hw/nvme/ns.c
@@ -441,6 +441,15 @@ void nvme_ns_cleanup(NvmeNamespace *ns)
}
}
+static void nvme_ns_unrealize(DeviceState *dev)
+{
+NvmeNamespace *ns = NVME_NS(dev);
+
+nvme_ns_drain(ns);
+nvme_ns_shutdown(ns);
+nvme_ns_cleanup(ns);
+}
+
static void nvme_ns_realize(DeviceState *dev, Error **errp)
{
NvmeNamespace *ns = NVME_NS(dev);
@@ -462,6 +471,14 @@ static void nvme_ns_realize(DeviceState *dev, Error **errp)
   "linked to an nvme-subsys device");
return;
}
+} else {
+/*
+ * If this namespace belongs to a subsystem (through a link on the
+ * controller device), reparent the device.
+ */
+if (!qdev_set_parent_bus(dev, >bus.parent_bus, errp)) {
+return;
+}


What happens if that fails?
Will we abort? Not create the namespace?



Good point!

It can actually only fail if the bus implements check_address(), which 
it does not, so it always succeeds, so it should assert instead.




Nah, the 'if' is fine. If check_address() should be implemented at some 
point, errp will be set and invocation of qemu will stop with an error. 
So I think the error handling is fine as-is.


signature.asc
Description: PGP signature

Re: [External] Re: [PATCH] target/i386: Fix cpuid level for AMD

2021-07-07 Thread Michael Roth

Quoting Eduardo Habkost (2021-07-02 12:35:34)
> On Fri, Jul 02, 2021 at 10:43:22AM -0500, Michael Roth wrote:
> > On Fri, Jul 02, 2021 at 01:14:56PM +0800, zhenwei pi wrote:
> > > On 7/2/21 4:35 AM, Michael Roth wrote:
> > > > Quoting Igor Mammedov (2021-07-01 03:43:13)
> > > > > On Wed, 30 Jun 2021 14:18:09 -0500
> > > > > Michael Roth  wrote:
> > > > > 
> > > > > > Quoting Dr. David Alan Gilbert (2021-06-29 09:06:02)
> > > > > > > * zhenwei pi (pizhen...@bytedance.com) wrote:
> > > > > > > > A AMD server typically has cpuid level 0x10(test on 
> > > > > > > > Rome/Milan), it
> > > > > > > > should not be changed to 0x1f in multi-dies case.
> > > > > > > > 
> > > > > > > > Fixes: a94e1428991 (target/i386: Add CPUID.1F generation support
> > > > > > > > for multi-dies PCMachine)
> > > > > > > > Signed-off-by: zhenwei pi 
> > > > > > > 
> > > > > > > (Copying in Babu)
> > > > > > > 
> > > > > > > Hmm I think you're right.  I've cc'd in Babu and Wei.
> > > > > > > 
> > > > > > > Eduardo: What do we need to do about compatibility, do we need to 
> > > > > > > wire
> > > > > > > this to machine type or CPU version?
> > > > > > 
> > > > > > FWIW, there are some other CPUID entries like leaves 2 and 4 that 
> > > > > > are
> > > > > > also Intel-specific. With SEV-SNP CPUID enforcement, advertising 
> > > > > > them to
> > > > > > guests will result in failures when host SNP firmware checks the
> > > > > > hypervisor-provided CPUID values against the host-supported ones.
> > > > > > 
> > > > > > To address this we've been planning to add an 'amd-cpuid-only' 
> > > > > > property
> > > > > > to suppress them:
> > > > > > 
> > > > > >
> > > > > > https://github.com/mdroth/qemu/commit/28d0553fe748d30a8af09e5e58a7da3eff03e21b
> > > > > > 
> > > > > > My thinking is this property should be off by default, and only 
> > > > > > defined
> > > > > > either via explicit command-line option, or via new CPU types. 
> > > > > > We're also
> > > > > > planning to add new CPU versions for EPYC* CPU types that set this
> > > > > > 'amd-cpuid-only' property by default:
> > > > > > 
> > > > > >https://github.com/mdroth/qemu/commits/new-cpu-types-upstream
> > > > > It look like having new cpu versions is enough to change behavior,
> > > > > maybe keep 'amd-cpuid-only' as internal field and not expose it to 
> > > > > users
> > > > > as a property.
> > > > 
> > > > Hmm, I defined it as a property mainly to make use of
> > > > X86CPUVersionDefinition.props to create new versions of the CPU types
> > > > with those properties set.
> > > > 
> > > > There's a patch there that adds X86CPUVersionDefinition.cache_info so
> > > > that new cache definitions can be provided for new CPU versions. So
> > > > would you suggest a similar approach here, e.g. adding an
> > > > X86CPUVersionDefinition.amd_cpuid_only field that could be used directly
> > > > rather than going through X86CPUVersionDefinition.props?
> > > > 
> > > > There's also another new "amd-xsave" prop in that series that does 
> > > > something
> > > > similar to "amd-cpuid-only", so a little worried about tacking to much 
> > > > extra
> > > > into X86CPUVersionDefinition. But maybe that one could just be rolled 
> > > > into
> > > > "amd-cpuid-only" since it is basically fixing up xsave-related cpuid
> > > > entries for AMD...
> > > > 
> > > Hi, this patch wants to fix the issue:
> > > AMD CPU (Rome/Milan) should get the cpuid level 0x10, not 0x1F in the 
> > > guest.
> > > If QEMU reports a 0x1F to guest, guest(Linux) would use leaf 0x1F instead 
> > > of
> > > leaf 0xB to get extended topology:
> > > 
> > > https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/topology.c#L49
> > > 
> > > static int detect_extended_topology_leaf(struct cpuinfo_x86 *c)
> > > {
> > > if (c->cpuid_level >= 0x1f) {
> > > if (check_extended_topology_leaf(0x1f) == 0)
> > > return 0x1f;
> > > }
> > > 
> > > if (c->cpuid_level >= 0xb) {
> > > if (check_extended_topology_leaf(0xb) == 0)
> > > return 0xb;
> > > }
> > > 
> > > return -1;
> > > }
> > > 
> > > Because of the wrong cpuid level, the guest gets unexpected topology from
> > > leaf 0x1F.
> > > 
> > > I tested https://github.com/mdroth/qemu/commits/new-cpu-types-upstream, 
> > > and
> > > it seems that these patches could not fix this issue.
> > 
> > Yes, I think your patch would still be needed. The question is whether it's
> > okay to change it for existing CPU types, e.g. EPYC-Milan, or only for new 
> > ones
> > when they set a certain flag/property, like the proposed "amd-cpuid-only" 
> > (which
> > the proposed EPYC-Milan-v2 would set).
> 
> I tried to answer this in a separate reply in this thread, but
> answering here for visibility:
> 
> You can safely do it on existing CPU types, because the new
> behavior doesn't introduce host software or hardware requirements
> when enabled.  You just need to disable the new behavior in
>

Re: [PATCH] docs/system: riscv: Update Microchip Icicle Kit for direct kernel boot

2021-07-07 Thread Alistair Francis

On Tue, Jul 6, 2021 at 7:50 PM Bin Meng  wrote:
>
> From: Bin Meng 
>
> This adds a new section in the documentation to demonstrate how to
> use the new direct kernel boot feature for Microchip Icicle Kit,
> other than the HSS bootflow, using an upstream U-Boot v2021.07 image
> as an example.
>
> It also updates the truth table to have a new '-dtb' column which is
> required by direct kernel boot.
>
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

> ---
>
>  docs/system/riscv/microchip-icicle-kit.rst | 54 +++---
>  1 file changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/docs/system/riscv/microchip-icicle-kit.rst 
> b/docs/system/riscv/microchip-icicle-kit.rst
> index 54ced661e3..817d2aec9c 100644
> --- a/docs/system/riscv/microchip-icicle-kit.rst
> +++ b/docs/system/riscv/microchip-icicle-kit.rst
> @@ -47,13 +47,13 @@ The user provided DTB should have the following 
> requirements:
>
>  QEMU follows below truth table to select which payload to execute:
>
> -=  == ===
> --bios -kernel payload
> -=  == ===
> -N   N HSS
> -Y  don't care HSS
> -N   Y  kernel
> -=  == ===
> += == == ===
> +-bios-kernel   -dtb payload
> += == == ===
> +N  N don't care HSS
> +Y don't care don't care HSS
> +N  Y  Y  kernel
> += == == ===
>
>  The memory is set to 1537 MiB by default which is the minimum required high
>  memory size by HSS. A sanity check on ram size is performed in the machine
> @@ -106,4 +106,44 @@ HSS output is on the first serial port (stdio) and 
> U-Boot outputs on the
>  second serial port. U-Boot will automatically load the Linux kernel from
>  the SD card image.
>
> +Direct Kernel Boot
> +--
> +
> +Sometimes we just want to test booting a new kernel, and transforming the
> +kernel image to the format required by the HSS bootflow is tedious. We can
> +use '-kernel' for direct kernel booting just like other RISC-V machines do.
> +
> +In this mode, the OpenSBI fw_dynamic BIOS image for 'generic' platform is
> +used to boot an S-mode payload like U-Boot or OS kernel directly.
> +
> +For example, the following commands show building a U-Boot image from U-Boot
> +mainline v2021.07 for the Microchip Icicle Kit board:
> +
> +.. code-block:: bash
> +
> +  $ export CROSS_COMPILE=riscv64-linux-
> +  $ make microchip_mpfs_icicle_defconfig
> +
> +Then we can boot the machine by:
> +
> +.. code-block:: bash
> +
> +  $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 -m 2G \
> +  -sd path/to/sdcard.img \
> +  -nic user,model=cadence_gem \
> +  -nic tap,ifname=tap,model=cadence_gem,script=no \
> +  -display none -serial stdio \
> +  -kernel path/to/u-boot/build/dir/u-boot.bin \
> +  -dtb path/to/u-boot/build/dir/u-boot.dtb
> +
> +CAVEATS:
> +
> +* Check the "stdout-path" property in the /chosen node in the DTB to 
> determine
> +  which serial port is used for the serial console, e.g.: if the console is 
> set
> +  to the second serial port, change to use "-serial null -serial stdio".
> +* The default U-Boot configuration uses CONFIG_OF_SEPARATE hence the ELF 
> image
> +  ``u-boot`` cannot be passed to "-kernel" as it does not contain the DTB 
> hence
> +  ``u-boot.bin`` has to be used which does contain one. To use the ELF image,
> +  we need to change to CONFIG_OF_EMBED or CONFIG_OF_PRIOR_STAGE.
> +
>  .. _HSS: https://github.com/polarfire-soc/hart-software-services
> --
> 2.25.1
>
>

Re: [PATCH] Fix libpmem configuration option

2021-07-07 Thread Pankaj Gupta

> For some reason, libpmem option setting was set to work in an opposite
> way (--enable-libpmem disabled it and vice versa). Fixing this so
> configuration works properly.
>
> Signed-off-by: Miroslav Rezanina 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 7994bdee92..ffa93cc5fd 100755
> --- a/configure
> +++ b/configure
> @@ -1501,9 +1501,9 @@ for opt do
>;;
>--disable-debug-mutex) debug_mutex=no
>;;
> -  --enable-libpmem) libpmem=disabled
> +  --enable-libpmem) libpmem="enabled"
>;;
> -  --disable-libpmem) libpmem=enabled
> +  --disable-libpmem) libpmem="disabled"
>;;
>--enable-xkbcommon) xkbcommon="enabled"
>;;

Reviewed-by: Pankaj Gupta

Re: [PATCH] hw/riscv: sifive_u: Correct the CLINT timebase frequency

2021-07-07 Thread Alistair Francis

On Tue, Jul 6, 2021 at 8:48 PM Bin Meng  wrote:
>
> From: Bin Meng 
>
> At present the CLINT timebase frequency is set to 10MHz on sifive_u,
> but on the real hardware the timebase frequency is 1Mhz.
>
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

> ---
>
>  hw/riscv/sifive_u.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 273c86418c..e75ca38783 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -62,6 +62,9 @@
>
>  #include 
>
> +/* CLINT timebase frequency */
> +#define CLINT_TIMEBASE_FREQ 100
> +
>  static const MemMapEntry sifive_u_memmap[] = {
>  [SIFIVE_U_DEV_DEBUG] ={0x0,  0x100 },
>  [SIFIVE_U_DEV_MROM] = { 0x1000, 0xf000 },
> @@ -165,7 +168,7 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry 
> *memmap,
>
>  qemu_fdt_add_subnode(fdt, "/cpus");
>  qemu_fdt_setprop_cell(fdt, "/cpus", "timebase-frequency",
> -SIFIVE_CLINT_TIMEBASE_FREQ);
> +CLINT_TIMEBASE_FREQ);
>  qemu_fdt_setprop_cell(fdt, "/cpus", "#size-cells", 0x0);
>  qemu_fdt_setprop_cell(fdt, "/cpus", "#address-cells", 0x1);
>
> @@ -847,7 +850,7 @@ static void sifive_u_soc_realize(DeviceState *dev, Error 
> **errp)
>  sifive_clint_create(memmap[SIFIVE_U_DEV_CLINT].base,
>  memmap[SIFIVE_U_DEV_CLINT].size, 0, ms->smp.cpus,
>  SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> -SIFIVE_CLINT_TIMEBASE_FREQ, false);
> +CLINT_TIMEBASE_FREQ, false);
>
>  if (!sysbus_realize(SYS_BUS_DEVICE(>prci), errp)) {
>  return;
> --
> 2.25.1
>
>

Re: [PATCH 0/4] ppc/Pegasos2: Firmware replacement using VOF

On Sun, Jun 27, 2021 at 06:27:13PM +0200, BALATON Zoltan wrote:
> Based-on: <20210625055155.2252896-1-...@ozlabs.ru>
> ^ That is v22 of Alexey's VOF patch
> 
> With this series on top of VOF v22 I can now boot Linux and MorphOS on
> pegasos2 without a firmware blob so I hope this is enough to get this
> board in 6.1 and also have it enabled so people can start using it
> eventually (a lot of people don't compile their QEMU but rely on
> binaries from distros and other sources). Provided that VOF will also
> be merged by then. This gives VOF another use case that may help it
> getting merged at last.
> 
> Further info and example command lines can be found at
> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2

Applied to ppc-for-6.1, thanks.

> 
> Regards,
> BALATON Zoltan
> 
> BALATON Zoltan (4):
>   ppc/pegasos2: Introduce Pegasos2MachineState structure
>   target/ppc: Allow virtual hypervisor on CPU without HV
>   ppc/pegasos2: Use Virtual Open Firmware as firmware replacement
>   ppc/pegasos2: Implement some RTAS functions with VOF
> 
>  default-configs/devices/ppc-softmmu.mak |   2 +-
>  hw/ppc/Kconfig  |   1 +
>  hw/ppc/pegasos2.c   | 783 +++-
>  target/ppc/cpu.c|   2 +-
>  4 files changed, 771 insertions(+), 17 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] target/riscv: hardwire bits in hideleg and hedeleg

2021-07-07 Thread Alistair Francis

On Thu, Jun 24, 2021 at 11:48 PM Jose Martins  wrote:
>
> > > +static const target_ulong vs_delegable_excps = delegable_excps &
> > > +~((1ULL << (RISCV_EXCP_S_ECALL)) |
> >
> > > +(1ULL << (RISCV_EXCP_VS_ECALL)) |
> > > +(1ULL << (RISCV_EXCP_M_ECALL)) |
> >
> > These two are both read only 0, shouldn't they not be included in this list?
> >
> > >  static int write_hedeleg(CPURISCVState *env, int csrno, target_ulong val)
> > >  {
> > > -env->hedeleg = val;
> > > +env->hedeleg = val & vs_delegable_excps;
> >
> > Because we then allow a write to occur here.
>
> Note that the list is being bitwise negated, so both of these are
> actually not writable (ie read-only 0). There is still the question
> regarding the VS_ECALL (exception 10) bit raised by Zhiwei, since
> table 5.2 in the spec does not explicitly classify it. However, I
> believe it is safe to assume that exception 10 is non-delegable.

Ah, I see.

Reviewed-by: Alistair Francis 

Applied to riscv-to-apply.next

I improved the indentation and rebased this on the latest master.

Alistair

>
> José

Re: [PATCH qemu v22] spapr: Implement Open Firmware client interface

On Thu, Jul 08, 2021 at 01:15:10PM +1000, Alexey Kardashevskiy wrote:
> 
> 
> On 08/07/2021 12:40, David Gibson wrote:
> > On Fri, Jun 25, 2021 at 03:51:55PM +1000, Alexey Kardashevskiy wrote:
[snip]
> > > +void spapr_vof_client_dt_finalize(SpaprMachineState *spapr, void *fdt)
> > > +{
> > > +char *stdout_path = spapr_vio_stdout_path(spapr->vio_bus);
> > > +int chosen;
> > > +
> > > +vof_build_dt(fdt, spapr->vof);
> > > +
> > > +_FDT(chosen = fdt_path_offset(fdt, "/chosen"));
> > > +_FDT(fdt_setprop_string(fdt, chosen, "bootargs",
> > > +spapr->vof->bootargs ? : ""));
> > 
> > You do several things with vof->bootargs, but if you've initialized it
> > from machine->kernel_cmdline, I didn't spot it.
> 
> 
> GRUB initilizes it and updates via spapr_vof_setprop().

Right, but my point is if an OF client doesn't poke it, it should have
the value from qemu's -append option which is in
machine->kernel_cmdline.

[snip]
> > > +static int path_offset(const void *fdt, const char *path)
> > > +{
> > > +g_autofree char *p = NULL;
> > > +char *at;
> > > +
> > > +/*
> > > + * 
> > > https://www.devicetree.org/open-firmware/bindings/ppc/release/ppc-2_1.html#HDR16
> > > + *
> > > + * "Conversion from numeric representation to text representation 
> > > shall use
> > > + * the lower case forms of the hexadecimal digits in the range a..f,
> > > + * suppressing leading zeros".
> > 
> > Huh... that suggests that Zoltan's firmware which passes a caps hex
> > and expects it to work is doing the wrong thing.  We still need to
> > accomodate it, though.
> > 
> > > + */
> > > +at = strchr(path, '@');
> > > +if (!at) {
> > > +return fdt_path_offset(fdt, path);
> > > +}
> > > +
> > > +p = g_strdup(path);
> > > +for (at = at - path + p + 1; *at; ++at) {
> > > +*at = tolower(*at);
> > > +}
> > 
> > This isn't quite right, though we might get away with it in practice.
> > You're taking a whole path here, and each path component could
> > potentially have a unit address.  This will tolower() everything after
> > the first @, potentially case mangling the base names of later
> > components.
> 
> Ah. I need the last "@" here, at least. But I do not think we need to go any
> further than this here.

That's closer to correct, and will probably work in practice.  That
will fail, though, if we find a client that uses bad caps for an
intermediate path component.

[snip]
> > > +static uint32_t vof_setprop(MachineState *ms, void *fdt, Vof *vof,
> > > +uint32_t nodeph, uint32_t pname,
> > > +uint32_t valaddr, uint32_t vallen)
> > > +{
> > > +char propname[OF_PROPNAME_LEN_MAX + 1];
> > > +uint32_t ret = -1;
> > > +int offset;
> > > +char trval[64] = "";
> > > +char nodepath[VOF_MAX_PATH] = "";
> > > +Object *vmo = object_dynamic_cast(OBJECT(ms), TYPE_VOF_MACHINE_IF);
> > > +g_autofree char *val = NULL;
> > > +
> > > +if (vallen > VOF_MAX_SETPROPLEN) {
> > > +goto trace_exit;
> > > +}
> > > +if (readstr(pname, propname, sizeof(propname))) {
> > > +goto trace_exit;
> > > +}
> > > +offset = fdt_node_offset_by_phandle(fdt, nodeph);
> > > +if (offset < 0) {
> > > +goto trace_exit;
> > > +}
> > > +ret = get_path(fdt, offset, nodepath, sizeof(nodepath));
> > > +if (ret <= 0) {
> > > +goto trace_exit;
> > > +}
> > > +
> > > +val = g_malloc0(vallen);
> > > +if (VOF_MEM_READ(valaddr, val, vallen) != MEMTX_OK) {
> > > +goto trace_exit;
> > > +}
> > > +
> > > +if (vmo) {
> > > +VofMachineIfClass *vmc = VOF_MACHINE_GET_CLASS(vmo);
> > > +
> > > +if (vmc->setprop &&
> > > +!vmc->setprop(ms, nodepath, propname, val, vallen)) {
> > > +goto trace_exit;
> > 
> > This defaults to allowing the setprop if the machine doesn't provide a
> > setprop callback.  I think it would be safer to default to prohibiting
> > all setprops except those the machine explicitly allows.
> 
> 
> Mmmm... I can imagine the client using the device tree as a temporary
> storage. I'd rather add a trace for such cases.

If they do, I think that's something we'll need to consider and
account for that platform, rather than something we want to allow to
begin with.

[snip]
> > > +static uint32_t vof_write(Vof *vof, uint32_t ihandle, uint32_t buf,
> > > +  uint32_t len)
> > > +{
> > > +char tmp[VOF_VTY_BUF_SIZE];
> > > +unsigned cb;
> > > +OfInstance *inst = (OfInstance *)
> > > +g_hash_table_lookup(vof->of_instances, GINT_TO_POINTER(ihandle));
> > > +
> > > +if (!inst) {
> > > +trace_vof_error_write(ihandle);
> > > +return -1;
> > > +}
> > > +
> > > +for ( ; len > 0; len -= cb) {
> > > +cb = MIN(len, sizeof(tmp) - 1);
> > > +if (VOF_MEM_READ(buf, tmp, cb) != MEMTX_OK) {
>

Re: [PATCH 4/4] ppc/pegasos2: Implement some RTAS functions with VOF

On Sun, Jun 27, 2021 at 06:27:13PM +0200, BALATON Zoltan wrote:
> Linux uses RTAS functions to access PCI devices so we need to provide
> these with VOF. Implement some of the most important functions to
> allow booting Linux with VOF. With this the board is now usable
> without a binary ROM image and we can enable it by default as other
> boards.
> 
> Signed-off-by: BALATON Zoltan 

Applied, but...

> @@ -687,6 +795,29 @@ static void *build_fdt(MachineState *machine, int 
> *fdt_size)
>  qemu_fdt_setprop_string(fdt, "/failsafe", "device_type", "serial");
>  qemu_fdt_setprop_string(fdt, "/failsafe", "name", "failsafe");
>  
> +qemu_fdt_add_subnode(fdt, "/rtas");
> +qemu_fdt_setprop_cell(fdt, "/rtas", "system-reboot", 20);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "hibernate", 19);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "suspend", 18);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "power-off", 17);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "set-indicator", 11);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "display-character", 10);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "write-pci-config", 9);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "read-pci-config", 8);
> +/* Pegasos2 firmware misspells check-exception and guests use that */
> +qemu_fdt_setprop_cell(fdt, "/rtas", "check-execption", 7);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "event-scan", 6);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "set-time-of-day", 4);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "get-time-of-day", 3);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "nvram-store", 2);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "nvram-fetch", 1);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "restart-rtas", 0);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "rtas-error-log-max", 0);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "rtas-event-scan-rate", 0);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "rtas-display-device", 0);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "rtas-size", 20);
> +qemu_fdt_setprop_cell(fdt, "/rtas", "rtas-version", 1);

..you really want to be using your symbolic names here as well.

-- 
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

[Bug 1679358] Re: ARM: RES0/RES1 SCTLR fields not read-only

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1679358

Title:
  ARM: RES0/RES1 SCTLR fields not read-only

Status in QEMU:
  Expired

Bug description:
  There are fields in SCTLR that are RAO/SBOP or WI or in the case of
  the RR field, accessible only in secure mode. Currently it seems that
  qemu just propagates any write to SCTLR to the register and this
  screwed up in a bootloader that I am debugging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1679358/+subscriptions

[Bug 1892533] Re: Meson: Missing config-host.mak

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1892533

Title:
  Meson: Missing config-host.mak

Status in QEMU:
  Expired

Bug description:
  Wanted to give a try to the new build system, but a simple "meson
  build" gives that error:

  meson.build:15:0: ERROR: Failed to load
  /home/xclaesse/programmation/qemu/build/config-host.mak: [Errno 2] No
  such file or directory: '/home/xclaesse/programmation/qemu/build
  /config-host.mak'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1892533/+subscriptions

[Bug 1890395] Re: qmp/hmp: crash if client closes socket too early

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890395

Title:
  qmp/hmp: crash if client closes socket too early

Status in QEMU:
  Expired

Bug description:
  Qemu crashes on qmp/hmp command if client closes connection before
  reading the whole response from the socket.

  Reproducer:

  1. Start arbitrary vm via qemu
  2. Send e.g. hmp command 'info mem'
  3. Abort before whole response came back

  
  Stack Trace:

  Stack trace of thread 6493:
  #0  0x559902fd2d30 object_get_class (qemu-system-x86_64)
  #1  0x559903071020 qio_channel_create_watch (qemu-system-x86_64)
  #2  0x55990305f437 qemu_chr_fe_add_watch (qemu-system-x86_64)
  #3  0x559902f7340d monitor_flush_locked (qemu-system-x86_64)
  #4  0x559902f7360e monitor_flush_locked (qemu-system-x86_64)
  #5  0x559902f74342 qmp_send_response (qemu-system-x86_64)
  #6  0x559902f74409 monitor_qmp_respond (qemu-system-x86_64)
  #7  0x559902f74bc0 monitor_qmp_bh_dispatcher (qemu-system-x86_64)
  #8  0x5599030c37be aio_bh_call (qemu-system-x86_64)
  #9  0x5599030c6dd0 aio_dispatch (qemu-system-x86_64)
  #10 0x5599030c369e aio_ctx_dispatch (qemu-system-x86_64)
  #11 0x7f5b6d37f417 g_main_context_dispatch (libglib-2.0.so.0)
  #12 0x5599030c5e0a glib_pollfds_poll (qemu-system-x86_64)
  #13 0x559902dd75df main_loop (qemu-system-x86_64)
  #14 0x559902c59f49 main (qemu-system-x86_64)
  #15 0x7f5b6bfeab97 __libc_start_main (libc.so.6)
  #16 0x559902c5d38a _start (qemu-system-x86_64)

  #0  0x559902fd2d30 in object_get_class (obj=obj@entry=0x0) at 
./qom/object.c:909
  #1  0x559903071020 in qio_channel_create_watch (ioc=0x0, 
condition=(G_IO_OUT | G_IO_HUP)) at ./io/channel.c:281
  klass = 
  __func__ = "qio_channel_create_watch"
  ret = 
  #2  0x55990305f437 in qemu_chr_fe_add_watch (be=be@entry=0x559905a7f460, 
cond=cond@entry=(G_IO_OUT | G_IO_HUP), func=func@entry=0x559902f734b0 
, user_data=user_data@entry=0x559905a7f460) at 
./chardev/char-fe.c:367
  s = 0x5599055782c0
  src = 
  tag = 
  __func__ = "qemu_chr_fe_add_watch"
  #3  0x559902f7340d in monitor_flush_locked (mon=mon@entry=0x559905a7f460) 
at ./monitor/monitor.c:140
  rc = 219264
  len = 3865832
  buf = 0x7f5afc00e480 "{\"return\": 
\"9eb48000-9eb480099000 ", '0' , "99000 
-rw\\r\\n9eb480099000-9eb48009b000 ", '0' , "2000 
-r-\\r\\n9eb48009b000-9eb48680 06765000 
-rw\\r\\n9eb4868000"...
  #4  0x559902f7360e in monitor_flush_locked (mon=0x559905a7f460) at 
./monitor/monitor.c:160
  i = 3865830
  c = 
  #5  0x559902f7360e in monitor_puts (mon=mon@entry=0x559905a7f460, 
str=0x7f5aa1eda010 "{\"return\": \"9eb48000-9eb480099000 ", '0' 
, "99000 -rw\\r\\n9eb480099000-9eb48009b000 ", '0' 
, "2000 -r-\\r\\n9eb48009b000-9eb48680 
06765000 -rw\\r\\n9eb4868000"...) at ./monitor/monitor.c:167
  i = 3865830
  c = 
  #6  0x559902f74342 in qmp_send_response (mon=0x559905a7f460, 
rsp=) at ./monitor/qmp.c:119
  data = 
  json = 0x559906c88380
  #7  0x559902f74409 in monitor_qmp_respond (rsp=0x559905bbf740, 
mon=0x559905a7f460) at ./monitor/qmp.c:132
  old_mon = 
  rsp = 0x559905bbf740
  error = 
  #8  0x559902f74409 in monitor_qmp_dispatch (mon=0x559905a7f460, 
req=) at ./monitor/qmp.c:161
  old_mon = 
  rsp = 0x559905bbf740
  error = 
  #9  0x559902f74bc0 in monitor_qmp_bh_dispatcher (data=) at 
./monitor/qmp.c:234
  id = 
  rsp = 
  need_resume = true
  mon = 0x559905a7f460
  __PRETTY_FUNCTION__ = "monitor_qmp_bh_dispatcher"
  #10 0x5599030c37be in aio_bh_call (bh=0x559905571b40) at ./util/async.c:89
  bh = 0x559905571b40
  bhp = 
  next = 0x5599055718f0
  ret = 1
  deleted = false
  #11 0x5599030c37be in aio_bh_poll (ctx=ctx@entry=0x5599055706f0) at 
./util/async.c:117
  bh = 0x559905571b40
  bhp = 
  next = 0x5599055718f0
  ret = 1
  deleted = false
  #12 0x5599030c6dd0 in aio_dispatch (ctx=0x5599055706f0) at 
./util/aio-posix.c:459
  #13 0x5599030c369e in aio_ctx_dispatch (source=, 
callback=, user_data=) at ./util/async.c:260
  ctx = 
  #14 0x7f5b6d37f417 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
  #15 0x5599030c5e0a in glib_pollfds_poll () at ./util/main-loop.c:219
  context = 0x559905652420
  pfds = 
  context = 0x559905652420
  ret = 1
  mlpoll = {state = 0, timeout = 4294967295, pollfds =

[Bug 1892541] Re: qemu 5.1 on windows 10 with whpx can not install Windows 7 guest

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1892541

Title:
  qemu 5.1 on windows 10 with whpx can not install Windows 7 guest

Status in QEMU:
  Expired

Bug description:
  Command install and start win7

  qemu-system-x86_64  -smbios type=1,uuid=e77aacd6-0acb-4a5c-9a83-a80d029b36f1 
-smp 2,sockets=1,cores=2,maxcpus=2 -nodefaults -boot 
menu=on,strict=on,reboot-timeout=1000 -m 8192 ^
  -readconfig pve-q35-4.0.cfg ^
  -device vmgenid,guid=6d4865f5-353e-4cf1-b8ca-f5abbd062736 -device 
usb-tablet,id=tablet,bus=ehci.0,port=1 -device VGA,id=vga,bus=pcie.0,addr=0x1 ^
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 ^
  -drive 
file=en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso,if=none,id=drive-ide2,media=cdrom,aio=threads
 ^
  -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 
-device ahci,id=ahci0,multifunction=on,bus=pci.0,addr=0x7 ^
  -drive 
id=drive-sata0,if=none,file=win7.qcow2,format=qcow2,cache=none,aio=native,detect-zeroes=on
 ^
  -device ide-hd,bus=ahci0.0,drive=drive-sata0,id=sata0,bootindex=100 ^
  -netdev type=tap,id=mynet0,ifname=tap1,script=no,downscript=no ^
  -device 
e1000,netdev=mynet0,mac=52:55:00:d1:55:10,bus=pci.0,addr=0x12,id=net0,bootindex=300
 ^
  -machine type=q35,accel=whpx

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1892541/+subscriptions

[Bug 1892684] Re: curl and wget segfaults when link has redirects

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1892684

Title:
  curl and wget segfaults when link has redirects

Status in QEMU:
  Expired

Bug description:
  Hello,

  I've been using qemu-user-static with aarch64 docker images and faced the 
problem
  using binares from the following release: 
https://github.com/multiarch/qemu-user-static/releases/tag/v5.0.0-2.

  curl and wget fails with segmentation fault when trying to fetch something 
from the link
  that has some redirects.

  In order to reproduce you can run the following:

  1) Register qemu on x86_64 machine
 docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
  2) Run arm64v8 docker image and try to run wget or curl
 docker run --rm -it arm64v8/ubuntu bash
 $ apt update
 $ apt install curl wget
 $ curl -L http://erratique.ch/software/astring/releases/astring-0.8.3.tbz
 $ wget  http://erratique.ch/software/astring/releases/astring-0.8.3.tbz

  This error cannot be reproduced with binaries from eariler release 
https://github.com/multiarch/qemu-user-static/releases/tag/v4.2.0-7.
  curl and wget work fine with the given link and don't fail with segfault when 
using
  older qemu-user-static binaries

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1892684/+subscriptions

[Bug 1893634] Re: blk_get_max_transfer() works only with sg

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1893634

Title:
  blk_get_max_transfer() works only with sg

Status in QEMU:
  Expired

Bug description:
  blk_get_max_transfer() is supposed to be able to get the max_sectors
  queue limit of the scsi device on the host side and is used in both
  scsi-generic.c (for scsi-generic and scsi-block) and scsi-disk.c (for
  scsi-hd) to set/change the max_xfer_len (and opt_xfer_len in the case
  of scsi-generic.c).

  However, it only works with the sg driver in doing so. It cannot get
  the queue limit with the sd driver and simply returns MAX_INT.

  qemu version 5.1.0
  kernel version 5.8.5

  Btw, is there a particular reason that it doesn't MIN_NON_ZERO against
  the original max_xfer_len:
  https://github.com/qemu/qemu/blob/v5.1.0/hw/scsi/scsi-generic.c#L172?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1893634/+subscriptions

[Bug 1890775] Re: Aten USB to Serial bridge does not work with qemu under Windows 10

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890775

Title:
  Aten USB to Serial bridge does not work with qemu under Windows 10

Status in QEMU:
  Expired

Bug description:
  I would like to use MSDOS 6.22 with qemu (unfortunatelly lot of our test 
programs has been written in dos).
  I tried to connect two laptop by RS232 port, one of the machine have a 
built-in serial port and run with native MSDOS 6.22 with 4.0 norton commander. 
Another machine have only USB ports and i try to use a new Aten USB to Serial 
device. Ok. Has been started qemu with -serial and -chardev parameters, at 
startup appear a window with serial port setting such as baud rate, start bit, 
etc...

  Quemu has been satrted succeeded but serial port cannot be used
  becouse was nothing activited on usb serial adapter :(

  I tried same configuration with VirtualBox and everything was worked
  fine (serial connection was estabiled and copied several files from
  one machine into another machine), seems to be the emulated serial
  port has been worked fine.

  I would like to use qemu, i just thougt qemu is better, simple and
  faster...

  Exists solution or is this a qemu bug?

  Thank you!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890775/+subscriptions

[Bug 1893807] Re: Crash when launching windows qemu version from WSL2

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1893807

Title:
  Crash when launching windows qemu version from WSL2

Status in QEMU:
  Expired

Bug description:
  Version: 5.1.0
  Command line from WSL2:
  qemu-system-x86_64.exe -hdd 
/home/jesus/proyectos/RWivOS/bin/RELEASE/image.hdd -m 4G -smp 4 -machine q35 
-debugcon stdio

  OS: Windows 10(64 bits) from WSL2 Ubuntu 18.04

  The error:
  
ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/block.c:1325:bdrv_open_driver: 
assertion
   failed: (is_power_of_2(bs->bl.request_alignment))

  The problem i'm seeing when i lauch from wsl2 only occurs when
  launched with argument -hdd from WSL2, if i launch it from Windows
  pointing to the WSL path where the file is stored works.

  It occurs on other versions, i tried 4.1.0 too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1893807/+subscriptions

[Bug 1894804] Re: Second DEVICE_DELETED event missing during virtio-blk disk device detach

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894804

Title:
  Second DEVICE_DELETED event missing during virtio-blk disk device
  detach

Status in QEMU:
  Expired
Status in qemu package in Ubuntu:
  Expired

Bug description:
  We are in the process of moving OpenStack CI across to use 20.04 Focal
  as the underlying OS and encountering the following issue in any test
  attempting to detach disk devices from running QEMU instances.

  We can see a single DEVICE_DELETED event raised to libvirtd for the
  /machine/peripheral/virtio-disk1/virtio-backend device but we do not
  see a second event for the actual disk. As a result the device is
  still marked as present in libvirt but QEMU reports it as missing in
  subsequent attempts to remove the device.

  The following log snippets can also be found in the following pastebin
  that's slightly easier to gork:

  http://paste.openstack.org/show/797564/

  https://review.opendev.org/#/c/746981/ libvirt: Bump
  MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION

  https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260
  nova-ceph-multistore

  
https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/dpkg-l.txt

  ii  libvirt-daemon   6.0.0-0ubuntu8.3 
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu   6.0.0-0ubuntu8.3 
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-system6.0.0-0ubuntu8.3 
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd6.0.0-0ubuntu8.3 
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt-dev:amd646.0.0-0ubuntu8.3 
 amd64development files for the libvirt library
  ii  libvirt0:amd64   6.0.0-0ubuntu8.3 
 amd64library for interfacing with different virtualization systems
  [..]
  ii  qemu-block-extra:amd64   1:4.2-3ubuntu6.4 
 amd64extra block backend modules for qemu-system and qemu-utils
  ii  qemu-slof20191209+dfsg-1  
 all  Slimline Open Firmware -- QEMU PowerPC version
  ii  qemu-system  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries
  ii  qemu-system-arm  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (arm)
  ii  qemu-system-common   1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-data 1:4.2-3ubuntu6.4 
 all  QEMU full system emulation (data files)
  ii  qemu-system-mips 1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (mips)
  ii  qemu-system-misc 1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (miscellaneous)
  ii  qemu-system-ppc  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (ppc)
  ii  qemu-system-s390x1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (s390x)
  ii  qemu-system-sparc1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (sparc)
  ii  qemu-system-x86  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (x86)
  ii  qemu-utils   1:4.2-3ubuntu6.4 
 amd64QEMU utilities

  
https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/libvirt/qemu
  /instance-003a_log.txt

  2020-09-07 19:29:55.021+: starting up libvirt version: 6.0.0, package: 
0ubuntu8.3 (Marc Deslauriers  Thu, 30 Jul 2020 
06:40:28 -0400), qemu version: 4.2.0Debian 1:4.2-3ubuntu6.4, kernel: 
5.4.0-45-generic, hostname: ubuntu-focal-ovh-bhs1-0019682147
  LC_ALL=C \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  HOME=/var/lib/libvirt/qemu/domain-86-instance-003a \
  XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-86-instance-003a/.local/share \
  XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-86-instance-003a/.cache \
  XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-86-instance-003a/.config \
  QEMU_AUDIO_DRV=none \
  /usr/bin/qemu-system-x86_64 \
  -name guest=instance-003a,debug-threads=on \
  -S \
  -object

[Bug 1895053] Re: Cannot nspawn raspbian 10 [FAILED] Failed to start Journal Service.

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895053

Title:
  Cannot nspawn raspbian 10 [FAILED] Failed to start Journal Service.

Status in QEMU:
  Expired

Bug description:
  Hi, I'm using nspawn and asked the question @systemd-devel. They redirected 
me to you, guessing that nspawn calls a syscall or ioctl qemu isnt aware of and 
can't implement properly?
  They were like: "Sorry, that's not my department." ^^

  Maybe you can reproduce the issue or help me investigating whats wrong
  or put the ball right back into their court? :D

  Testscript:
  wget https://downloads.raspberrypi.org/raspios_lite_armhf_latest -o r.zip
  unzip r.zip
  LOOP=$(losetup --show -Pf *raspios-buster-armhf-lite.img)
  mount ${LOOP}p2 /mnt
  mount ${LOOP}p1 /mnt/boot
  systemd-nspawn --bind /usr/bin/qemu-arm-static --boot --directory=/mnt -- 
systemd.log_level=debug

  Output:
  see attachment

  System:
  uname -a
  Linux MArch 5.8.7-arch1-1 #1 SMP PREEMPT Sat, 05 Sep 2020 12:31:32 +
  x86_64 GNU/Linux

  qemu-arm-static --version
  qemu-arm version 5.1.0

  systemd-nspawn --version
  systemd 246 (246.4-1-arch)
  +PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP
  +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN
  +PCRE2 default-hierarchy=hybrid

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1895053/+subscriptions

[Bug 1891829] Re: High bit(s) sometimes set high on rcvd serial bytes when char size < 8 bits

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1891829

Title:
  High bit(s) sometimes set high on rcvd serial bytes when char size < 8
  bits

Status in QEMU:
  Expired

Bug description:
  I *believe* (not confirmed) that the old standard PC serial ports,
  when configured with a character size of 7 bits or less, should set
  non-data bits to 0 when the CPU reads received chars from the read
  register.  qemu doesn't do this.

  Windows 1.01 will not make use of a serial mouse when bit 7 is 1.  The
  ID byte that the mouse sends on reset is ignored.  I added a temporary
  hack to set bit 7 to 0 on all incoming bytes, and this convinced
  windows 1.01 to use the mouse.

  note 1:  This was using a real serial mouse through a passed-through
  serial port.  The emulated msmouse doesn't work for other reasons.

  note 2:  The USB serial port I am passing through to the guest sets
  non-data bits to 1.  Not sure if this is the USB hardware or linux.

  note 3:  I also needed to add an -icount line to slow down the guest
  CPU, so that certain cpu-sensitive timing code in the guest didn't
  give up too quickly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1891829/+subscriptions

[Bug 1894617] Re: qemu-i386 mmap but offset greater than 32 bits

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894617

Title:
  qemu-i386 mmap but offset greater than 32 bits

Status in QEMU:
  Expired

Bug description:
  I don't know if it's a problem, but I did, and it bothered me for a long time.
  When I use qemu-i386 and interact with the video card device,an error has 
occurred:

  18534 ioctl(4,DRM_IOCTL_MODE_GETENCODER,{39,0,0,0,0}) = 0 ({39,4,34,3,0})
  18534 ioctl(4,DRM_IOCTL_MODE_CREATE_DUMB,{1080,1920,32,0,0,0,0}) = 0 
({1080,1920,32,0,1,7680,8294400})
  18534 ioctl(4,DRM_IOCTL_MODE_ADDFB,{0,1920,1080,7680,32,24,1}) = 0 
({66,1920,1080,7680,32,24,1})
  18534 ioctl(4,DRM_IOCTL_MODE_MAP_DUMB,{1,0,0}) = 0 ({1,0,5543018496})
  18534 mmap2(NULL,8294400,PROT_READ|PROT_WRITE,MAP_SHARED,4,0x14a63c) = -1 
errno=22 (Invalid argument)

  "5543018496" is the offset through ioctl() and it is "0x14a63c000".
  In qemu：
  ret = target_mmap(arg1, arg2, arg3,
target_to_host_bitmask(arg4, mmap_flags_tbl),
arg5, arg6 << MMAP_SHIFT);

  The type of "arg6" is ulong.When use qemu-i386, arg6 can't be set to
  "0x14a63c000".So it's wrong for my program.

  I want to find a good way to deal with this kind of problem, but I'm not very 
familiar with QEMU，
  so I came to ask how to deal with this problem.

  Thank you！

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1894617/+subscriptions

[Bug 1895219] Re: qemu git -vnc fails due to missing en-us keymap

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895219

Title:
  qemu git -vnc fails due to missing en-us keymap

Status in QEMU:
  Expired

Bug description:
  If trying to run qemu with -vnc :0, it will fail with:
  ./qemu-system-x86_64 -vnc :2
  qemu-system-x86_64: -vnc :2: could not read keymap file: 'en-us'

  share/keymaps is missing en-us keymap and only has sl and sv,
  confirmed previous stable versions had en-us.

  Tried with multiple targets, on arm64 and amd64

  Git commit hash: 9435a8b3dd35f1f926f1b9127e8a906217a5518a (head)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1895219/+subscriptions

[Bug 1894804] Re: Second DEVICE_DELETED event missing during virtio-blk disk device detach

[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894804

Title:
  Second DEVICE_DELETED event missing during virtio-blk disk device
  detach

Status in QEMU:
  Expired
Status in qemu package in Ubuntu:
  Expired

Bug description:
  We are in the process of moving OpenStack CI across to use 20.04 Focal
  as the underlying OS and encountering the following issue in any test
  attempting to detach disk devices from running QEMU instances.

  We can see a single DEVICE_DELETED event raised to libvirtd for the
  /machine/peripheral/virtio-disk1/virtio-backend device but we do not
  see a second event for the actual disk. As a result the device is
  still marked as present in libvirt but QEMU reports it as missing in
  subsequent attempts to remove the device.

  The following log snippets can also be found in the following pastebin
  that's slightly easier to gork:

  http://paste.openstack.org/show/797564/

  https://review.opendev.org/#/c/746981/ libvirt: Bump
  MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION

  https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260
  nova-ceph-multistore

  
https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/dpkg-l.txt

  ii  libvirt-daemon   6.0.0-0ubuntu8.3 
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu   6.0.0-0ubuntu8.3 
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-system6.0.0-0ubuntu8.3 
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd6.0.0-0ubuntu8.3 
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt-dev:amd646.0.0-0ubuntu8.3 
 amd64development files for the libvirt library
  ii  libvirt0:amd64   6.0.0-0ubuntu8.3 
 amd64library for interfacing with different virtualization systems
  [..]
  ii  qemu-block-extra:amd64   1:4.2-3ubuntu6.4 
 amd64extra block backend modules for qemu-system and qemu-utils
  ii  qemu-slof20191209+dfsg-1  
 all  Slimline Open Firmware -- QEMU PowerPC version
  ii  qemu-system  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries
  ii  qemu-system-arm  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (arm)
  ii  qemu-system-common   1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-data 1:4.2-3ubuntu6.4 
 all  QEMU full system emulation (data files)
  ii  qemu-system-mips 1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (mips)
  ii  qemu-system-misc 1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (miscellaneous)
  ii  qemu-system-ppc  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (ppc)
  ii  qemu-system-s390x1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (s390x)
  ii  qemu-system-sparc1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (sparc)
  ii  qemu-system-x86  1:4.2-3ubuntu6.4 
 amd64QEMU full system emulation binaries (x86)
  ii  qemu-utils   1:4.2-3ubuntu6.4 
 amd64QEMU utilities

  
https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/libvirt/qemu
  /instance-003a_log.txt

  2020-09-07 19:29:55.021+: starting up libvirt version: 6.0.0, package: 
0ubuntu8.3 (Marc Deslauriers  Thu, 30 Jul 2020 
06:40:28 -0400), qemu version: 4.2.0Debian 1:4.2-3ubuntu6.4, kernel: 
5.4.0-45-generic, hostname: ubuntu-focal-ovh-bhs1-0019682147
  LC_ALL=C \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  HOME=/var/lib/libvirt/qemu/domain-86-instance-003a \
  XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-86-instance-003a/.local/share \
  XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-86-instance-003a/.cache \
  XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-86-instance-003a/.config \
  QEMU_AUDIO_DRV=none \
  /usr/bin/qemu-system-x86_64 \
  -name guest=instance-003a,debug-threads=on \

[Bug 1895122] Re: qemu on wsl tests failed, this configured with debug

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895122

Title:
  qemu on wsl tests failed, this configured with debug

Status in QEMU:
  Expired

Bug description:
  
  ../configure --enable-debug-info --enable-debug

  **
  ERROR:../tests/test-util-filemonitor.c:704:test_file_monitor_events: 
assertion failed: (err == 0)
  Aborted (core dumped)

  
TESTiotest-qcow2: 271 [fail]
  QEMU  -- 
"/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-system-x86_64" 
-nodefaults -display none -accel qtest
  QEMU_IMG  -- 
"/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-img" 
  QEMU_IO   -- 
"/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-io"  --cache 
writeback --aio threads -f qcow2
  QEMU_NBD  -- 
"/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-nbd" 
  IMGFMT-- qcow2 (compat=1.1)
  IMGPROTO  -- file
  PLATFORM  -- Linux/x86_64 DESKTOP-BLLJ03T 4.4.0-19041-Microsoft
  TEST_DIR  -- /home/lygstate/work/qemu/build/tests/qemu-iotests/scratch
  SOCK_DIR  -- /tmp/tmp.eyVcw8nLNQ
  SOCKET_SCM_HELPER -- 
/home/lygstate/work/qemu/build/tests/qemu-iotests/socket_scm_helper

  --- /home/lygstate/work/qemu/tests/qemu-iotests/271.out   2020-09-10 
15:00:58.190763400 +0800
  +++ /home/lygstate/work/qemu/build/tests/qemu-iotests/271.out.bad 
2020-09-10 18:38:25.625090800 +0800
  @@ -37,6 +37,7 @@
   write -q -P PATTERN 0 64k
   L2 entry #0: 0x8005 
   discard -q 0 64k
  +Content mismatch at offset 0!
   L2 entry #0: 0x 
   write -q -c -P PATTERN 0 64k
   L2 entry #0: 0x4005 
  @@ -79,6 +80,7 @@
   write -q -P PATTERN 0 64k
   L2 entry #0: 0x8005 
   discard -q 0 64k
  +Content mismatch at offset 0!
   L2 entry #0: 0x 
   write -q -c -P PATTERN 0 64k
   L2 entry #0: 0x4005 
TESTiotest-qcow2: 283
TESTiotest-qcow2: 287
TESTiotest-qcow2: 290
TESTiotest-qcow2: 292
TESTiotest-qcow2: 299
  Not run: 060 181 220 259
  Failures: 271
  Failed 1 of 118 iotests
  make: [/home/lygstate/work/qemu/tests/Makefile.include:144: check-block] 
Error 1 (ignored)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1895122/+subscriptions

[Bug 1894818] Re: COLO's guest VNC client hang after failover

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894818

Title:
  COLO's guest VNC client hang after failover

Status in QEMU:
  Expired

Bug description:
  Hello,

  After setting up COLO's primary and secondary VMs,
  I installed the vncserver and xrdp (apt install tightvncserver xrdp) inside 
the VM.

  I access the VM from another PC via VNC/RDP client, and everything is OK.
  Then, kill the primary VM and issue the failover commands.

  The expected result is that the VNC/RDP client can reconnect and
  resume automatically after failover. (I've confirmed the VNC/RDP
  client can reconnect automatically.)

  But in my test, the VNC client's screen hangs and cannot be recovered
  no longer. I need to restart VNC client by myself.

  BTW, it works well after killing SVM.

  Here is my QEMU networking device
  ```
  -device virtio-net-pci,id=e0,netdev=hn0 \
  -netdev 
tap,id=hn0,br=br0,vhost=off,helper=/usr/local/libexec/qemu-bridge-helper \
  ```

  Thanks.

  Regards,
  Derek

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1894818/+subscriptions

Re: [PATCH 2/2] docs/system: ppc: Update ppce500 documentation with eTSEC support

On Thu, Jul 08, 2021 at 09:22:48AM +0800, Bin Meng wrote:
> Hi David,
> 
> On Thu, Jul 8, 2021 at 9:08 AM David Gibson  
> wrote:
> >
> > On Tue, Jul 06, 2021 at 12:31:24PM +0800, Bin Meng wrote:
> > > This adds eTSEC support to the PowerPC `ppce500` machine documentation.
> > >
> > > Signed-off-by: Bin Meng 
> >
> > Applied to ppc-for-6.1, thanks.
> 
> Thanks!
> 
> Are both 2 patches applied, or only this one?

Both, sorry I wasn't clear.

-- 
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/4] target/ppc: Allow virtual hypervisor on CPU without HV

On Sun, Jun 27, 2021 at 06:27:13PM +0200, BALATON Zoltan wrote:
> Change the assert in ppc_store_sdr1() to allow vhyp to be set on CPUs
> without HV bit. This allows using the vhyp interface for firmware
> emulation on pegasos2.
> 
> Signed-off-by: BALATON Zoltan 

Kind of a hack, but a simple one, so applied to ppc-for-6.1.

> ---
>  target/ppc/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/cpu.c b/target/ppc/cpu.c
> index 19d67b5b07..a29299882a 100644
> --- a/target/ppc/cpu.c
> +++ b/target/ppc/cpu.c
> @@ -72,7 +72,7 @@ void ppc_store_sdr1(CPUPPCState *env, target_ulong value)
>  {
>  PowerPCCPU *cpu = env_archcpu(env);
>  qemu_log_mask(CPU_LOG_MMU, "%s: " TARGET_FMT_lx "\n", __func__, value);
> -assert(!cpu->vhyp);
> +assert(!cpu->env.has_hv_mode || !cpu->vhyp);
>  #if defined(TARGET_PPC64)
>  if (mmu_is_64bit(env->mmu_model)) {
>  target_ulong sdr_mask = SDR_64_HTABORG | SDR_64_HTABSIZE;

-- 
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] target/ppc: mtmsrd is an illegal instruction on BookE

On Tue, Jul 06, 2021 at 03:13:21PM +1000, Nicholas Piggin wrote:
> MSR is a 32-bit register in BookE and there is no mtmsrd instruction.
> 
> Cc: Christian Zigotzky 
> Signed-off-by: Nicholas Piggin 

Applied to ppc-for-6.1, thanks.

> ---
>  target/ppc/translate.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index f65d1e81ea..d1f482b0f3 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -4940,6 +4940,11 @@ static void gen_mtcrf(DisasContext *ctx)
>  #if defined(TARGET_PPC64)
>  static void gen_mtmsrd(DisasContext *ctx)
>  {
> +if (unlikely(!is_book3s_arch2x(ctx))) {
> +gen_invalid(ctx);
> +return;
> +}
> +
>  CHK_SV;
>  
>  #if !defined(CONFIG_USER_ONLY)

-- 
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] target/ppc/spapr: Update H_GET_CPU_CHARACTERISTICS L1D cache flush bits

On Tue, Jun 15, 2021 at 02:41:07PM +1000, Nicholas Piggin wrote:
> There are several new L1D cache flush bits added to the hcall which reflect
> hardware security features for speculative cache access issues.
> 
> These behaviours are now being specified as negative in order to simplify
> patched kernel compatibility with older firmware (a new problem found in
> existing systems would automatically be vulnerable).
> 
> Signed-off-by: Nicholas Piggin 

After our discussion, I'm convinced that the small behaviour change
for old machine types is safe.  I've added an explanatory note to the
commit message and merged to ppc-for-6.1.

> ---
>  hw/ppc/spapr_hcall.c   | 2 ++
>  include/hw/ppc/spapr.h | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index f25014afda..dfd9df469d 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1299,6 +1299,8 @@ static target_ulong 
> h_get_cpu_characteristics(PowerPCCPU *cpu,
>  behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
>  break;
>  case SPAPR_CAP_FIXED:
> +behaviour |= H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY;
> +behaviour |= H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS;
>  break;
>  default: /* broken */
>  assert(safe_cache == SPAPR_CAP_BROKEN);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index f05219f75e..0f25d081a8 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -398,10 +398,13 @@ struct SpaprMachineState {
>  #define H_CPU_CHAR_THR_RECONF_TRIG  PPC_BIT(6)
>  #define H_CPU_CHAR_CACHE_COUNT_DIS  PPC_BIT(7)
>  #define H_CPU_CHAR_BCCTR_FLUSH_ASSIST   PPC_BIT(9)
> +
>  #define H_CPU_BEHAV_FAVOUR_SECURITY PPC_BIT(0)
>  #define H_CPU_BEHAV_L1D_FLUSH_PRPPC_BIT(1)
>  #define H_CPU_BEHAV_BNDS_CHK_SPEC_BAR   PPC_BIT(2)
>  #define H_CPU_BEHAV_FLUSH_COUNT_CACHE   PPC_BIT(5)
> +#define H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY  PPC_BIT(7)
> +#define H_CPU_BEHAV_NO_L1D_FLUSH_UACCESSPPC_BIT(8)
>  
>  /* Each control block has to be on a 4K boundary */
>  #define H_CB_ALIGNMENT 4096

-- 
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/4] ppc/pegasos2: Introduce Pegasos2MachineState structure

On Sun, Jun 27, 2021 at 06:27:13PM +0200, BALATON Zoltan wrote:
> Add own machine state structure which will be used to store state
> needed for firmware emulation.
> 
> Signed-off-by: BALATON Zoltan 
> Reviewed-by: Philippe Mathieu-Daudé 

Applied to ppc-for-6.1.

> ---
>  hw/ppc/pegasos2.c | 50 +++
>  1 file changed, 37 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c
> index 0bfd0928aa..07971175c9 100644
> --- a/hw/ppc/pegasos2.c
> +++ b/hw/ppc/pegasos2.c
> @@ -1,7 +1,7 @@
>  /*
>   * QEMU PowerPC CHRP (Genesi/bPlan Pegasos II) hardware System Emulator
>   *
> - * Copyright (c) 2018-2020 BALATON Zoltan
> + * Copyright (c) 2018-2021 BALATON Zoltan
>   *
>   * This work is licensed under the GNU GPL license version 2 or later.
>   *
> @@ -41,6 +41,15 @@
>  
>  #define BUS_FREQ_HZ 1
>  
> +#define TYPE_PEGASOS2_MACHINE  MACHINE_TYPE_NAME("pegasos2")
> +OBJECT_DECLARE_TYPE(Pegasos2MachineState, MachineClass, PEGASOS2_MACHINE)
> +
> +struct Pegasos2MachineState {
> +MachineState parent_obj;
> +PowerPCCPU *cpu;
> +DeviceState *mv;
> +};
> +
>  static void pegasos2_cpu_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
> @@ -51,9 +60,9 @@ static void pegasos2_cpu_reset(void *opaque)
>  
>  static void pegasos2_init(MachineState *machine)
>  {
> -PowerPCCPU *cpu = NULL;
> +Pegasos2MachineState *pm = PEGASOS2_MACHINE(machine);
> +CPUPPCState *env;
>  MemoryRegion *rom = g_new(MemoryRegion, 1);
> -DeviceState *mv;
>  PCIBus *pci_bus;
>  PCIDevice *dev;
>  I2CBus *i2c_bus;
> @@ -63,15 +72,16 @@ static void pegasos2_init(MachineState *machine)
>  uint8_t *spd_data;
>  
>  /* init CPU */
> -cpu = POWERPC_CPU(cpu_create(machine->cpu_type));
> -if (PPC_INPUT(>env) != PPC_FLAGS_INPUT_6xx) {
> +pm->cpu = POWERPC_CPU(cpu_create(machine->cpu_type));
> +env = >cpu->env;
> +if (PPC_INPUT(env) != PPC_FLAGS_INPUT_6xx) {
>  error_report("Incompatible CPU, only 6xx bus supported");
>  exit(1);
>  }
>  
>  /* Set time-base frequency */
> -cpu_ppc_tb_init(>env, BUS_FREQ_HZ / 4);
> -qemu_register_reset(pegasos2_cpu_reset, cpu);
> +cpu_ppc_tb_init(env, BUS_FREQ_HZ / 4);
> +qemu_register_reset(pegasos2_cpu_reset, pm->cpu);
>  
>  /* RAM */
>  memory_region_add_subregion(get_system_memory(), 0, machine->ram);
> @@ -96,16 +106,16 @@ static void pegasos2_init(MachineState *machine)
>  g_free(filename);
>  
>  /* Marvell Discovery II system controller */
> -mv = DEVICE(sysbus_create_simple(TYPE_MV64361, -1,
> -((qemu_irq 
> *)cpu->env.irq_inputs)[PPC6xx_INPUT_INT]));
> -pci_bus = mv64361_get_pci_bus(mv, 1);
> +pm->mv = DEVICE(sysbus_create_simple(TYPE_MV64361, -1,
> + ((qemu_irq 
> *)env->irq_inputs)[PPC6xx_INPUT_INT]));
> +pci_bus = mv64361_get_pci_bus(pm->mv, 1);
>  
>  /* VIA VT8231 South Bridge (multifunction PCI device) */
>  /* VT8231 function 0: PCI-to-ISA Bridge */
>  dev = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(12, 0), true,
>TYPE_VT8231_ISA);
>  qdev_connect_gpio_out(DEVICE(dev), 0,
> -  qdev_get_gpio_in_named(mv, "gpp", 31));
> +  qdev_get_gpio_in_named(pm->mv, "gpp", 31));
>  
>  /* VT8231 function 1: IDE Controller */
>  dev = pci_create_simple(pci_bus, PCI_DEVFN(12, 1), "via-ide");
> @@ -129,8 +139,10 @@ static void pegasos2_init(MachineState *machine)
>  pci_vga_init(pci_bus);
>  }
>  
> -static void pegasos2_machine(MachineClass *mc)
> +static void pegasos2_machine_class_init(ObjectClass *oc, void *data)
>  {
> +MachineClass *mc = MACHINE_CLASS(oc);
> +
>  mc->desc = "Genesi/bPlan Pegasos II";
>  mc->init = pegasos2_init;
>  mc->block_default_type = IF_IDE;
> @@ -141,4 +153,16 @@ static void pegasos2_machine(MachineClass *mc)
>  mc->default_ram_size = 512 * MiB;
>  }
>  
> -DEFINE_MACHINE("pegasos2", pegasos2_machine)
> +static const TypeInfo pegasos2_machine_info = {
> +.name  = TYPE_PEGASOS2_MACHINE,
> +.parent= TYPE_MACHINE,
> +.class_init= pegasos2_machine_class_init,
> +.instance_size = sizeof(Pegasos2MachineState),
> +};
> +
> +static void pegasos2_machine_register_types(void)
> +{
> +type_register_static(_machine_info);
> +}
> +
> +type_init(pegasos2_machine_register_types)

-- 
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] python: Configure tox to skip missing interpreters

On Wed, Jun 30, 2021 at 5:00 PM Willian Rampazzo 
wrote:

> On Wed, Jun 30, 2021 at 3:46 PM Wainer dos Santos Moschetta
>  wrote:
> >
> > Currently tox tests against the installed interpreters, however if any
> > supported interpreter is absent then it will return fail. It seems not
> > reasonable to expect developers to have all supported interpreters
> > installed on their systems. Luckily tox can be configured to skip
> > missing interpreters.
> >
> > This changed the tox setup so that missing interpreters are skipped by
> > default. On the CI, however, we still want to enforce it tests
> > against all supported. This way on CI the
> > --skip-missing-interpreters=false option is passed to tox.
> >
> > Signed-off-by: Wainer dos Santos Moschetta 
> > ---
> > Tested locally with `make check-tox` and where I only Python 3.6 and 3.9
> > installed.
> > Tested on CI: https://gitlab.com/wainersm/qemu/-/jobs/1390010988
> > Still on CI, but I deliberately removed Python 3.8:
> https://gitlab.com/wainersm/qemu/-/jobs/1390046531
> >
> >  .gitlab-ci.d/static_checks.yml | 1 +
> >  python/Makefile| 5 -
> >  python/setup.cfg   | 1 +
> >  3 files changed, 6 insertions(+), 1 deletion(-)
> >
>
> Seems reasonable.
>
> Reviewed-by: Willian Rampazzo 
>
>
Nice, I get to have my cake and eat it too :)

Reviewed-by: John Snow

Re: [PATCH 3/6] python/aqmp-tui: Add AQMP TUI draft

On Fri, Jul 2, 2021 at 5:26 PM G S Niteesh Babu 
wrote:

> Added a draft of AQMP TUI.
>
> Implements the follwing basic features:
> 1) Command transmission/reception.
> 2) Shows events asynchronously.
> 3) Shows server status in the bottom status bar.
>
> Also added necessary pylint, mypy configurations
>
> Signed-off-by: G S Niteesh Babu 
> ---
>  python/qemu/aqmp/aqmp_tui.py | 246 +++
>  python/setup.cfg |  16 ++-
>  2 files changed, 261 insertions(+), 1 deletion(-)
>  create mode 100644 python/qemu/aqmp/aqmp_tui.py
>
> diff --git a/python/qemu/aqmp/aqmp_tui.py b/python/qemu/aqmp/aqmp_tui.py
> new file mode 100644
> index 00..8e9e8ac8ff
> --- /dev/null
> +++ b/python/qemu/aqmp/aqmp_tui.py
> @@ -0,0 +1,246 @@
> +# Copyright (c) 2021
> +#
> +# Authors:
> +#  Niteesh Babu G S 
> +#
> +# 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 argparse
> +import asyncio
> +import logging
> +import signal
> +
> +import urwid
> +import urwid_readline
> +
> +from .protocol import ConnectError
> +from .qmp_protocol import QMP, ExecInterruptedError, ExecuteError
> +from .util import create_task, pretty_traceback
> +
> +
> +UPDATE_MSG = 'UPDATE_MSG'
>
+
> +
> +class StatusBar(urwid.Text):
> +"""
> +A simple Text widget that currently only shows connection status.
> +"""
> +def __init__(self, text=''):
> +super().__init__(text, align='right')
> +
> +
> +class Editor(urwid_readline.ReadlineEdit):
> +"""
> +Support urwid_readline features along with
> +history support which lacks in urwid_readline
> +"""
> +def __init__(self, master):
> +super().__init__(caption='> ', multiline=True)
> +self.master = master
> +self.history = []
> +self.last_index = -1
> +self.show_history = False
> +
> +def keypress(self, size, key):
> +# TODO: Add some logic for down key and clean up logic if
> possible.
> +# Returning None means the key has been handled by this widget
> +# which otherwise is propogated to the parent widget to be
> +# handled
> +msg = self.get_edit_text()
> +if key == 'up' and not msg:
> +# Show the history when 'up arrow' is pressed with no input
> text.
> +# NOTE: The show_history logic is necessary because in
> 'multiline'
> +# mode (which we use) 'up arrow' is used to move between
> lines.
> +self.show_history = True
> +last_msg = self.history[self.last_index] if self.history else
> ''
> +self.set_edit_text(last_msg)
> +self.edit_pos = len(last_msg)
> +self.last_index += 1
> +elif key == 'up' and self.show_history:
> +if self.last_index < len(self.history):
> +self.set_edit_text(self.history[self.last_index])
> +self.edit_pos = len(self.history[self.last_index])
> +self.last_index += 1
> +elif key == 'meta enter':
> +# When using multiline, enter inserts a new line into the
> editor
> +# send the input to the server on alt + enter
> +self.master.cb_send_to_server(msg)
> +self.history.insert(0, msg)
> +self.set_edit_text('')
> +self.last_index = 0
> +self.show_history = False
> +else:
> +self.show_history = False
> +self.last_index = 0
> +return super().keypress(size, key)
> +return None
> +
> +
> +class EditorWidget(urwid.Filler):
> +"""
> +Wraps CustomEdit
> +"""
> +def __init__(self, master):
> +super().__init__(Editor(master), valign='top')
> +
> +
> +class HistoryBox(urwid.ListBox):
> +"""
> +Shows all the QMP message transmitted/received
> +"""
> +def __init__(self, master):
> +self.master = master
> +self.history = urwid.SimpleFocusListWalker([])
> +super().__init__(self.history)
> +
> +def add_to_history(self, history):
> +self.history.append(urwid.Text(history))
> +if self.history:
> +self.history.set_focus(len(self.history) - 1)
> +
> +
> +class HistoryWindow(urwid.Frame):
> +"""
> +Composes the HistoryBox and EditorWidget
> +"""
> +def __init__(self, master):
> +self.master = master
> +self.editor = EditorWidget(master)
> +self.editor_widget = urwid.LineBox(self.editor)
> +self.history = HistoryBox(master)
> +self.body = urwid.Pile([('weight', 80, self.history),
> +('weight', 10, self.editor_widget)])
> +super().__init__(self.body)
> +urwid.connect_signal(self.master, UPDATE_MSG,
> self.cb_add_to_history)
> +
> +def cb_add_to_history(self, msg):
> +self.history.add_to_history(msg)
> +
> +
> +class Window(urwid.Frame):
> +

Re: [PATCH qemu v22] spapr: Implement Open Firmware client interface

2021-07-07 Thread Alexey Kardashevskiy





On 08/07/2021 12:40, David Gibson wrote:

On Fri, Jun 25, 2021 at 03:51:55PM +1000, Alexey Kardashevskiy wrote:

The PAPR platform describes an OS environment that's presented by
a combination of a hypervisor and firmware. The features it specifies
require collaboration between the firmware and the hypervisor.

Since the beginning, the runtime component of the firmware (RTAS) has
been implemented as a 20 byte shim which simply forwards it to
a hypercall implemented in qemu. The boot time firmware component is
SLOF - but a build that's specific to qemu, and has always needed to be
updated in sync with it. Even though we've managed to limit the amount
of runtime communication we need between qemu and SLOF, there's some,
and it has become increasingly awkward to handle as we've implemented
new features.

This implements a boot time OF client interface (CI) which is
enabled by a new "x-vof" pseries machine option (stands for "Virtual Open
Firmware). When enabled, QEMU implements the custom H_OF_CLIENT hcall
which implements Open Firmware Client Interface (OF CI). This allows
using a smaller stateless firmware which does not have to manage
the device tree.

The new "vof.bin" firmware image is included with source code under
pc-bios/. It also includes RTAS blob.

This implements a handful of CI methods just to get -kernel/-initrd
working. In particular, this implements the device tree fetching and
simple memory allocator - "claim" (an OF CI memory allocator) and updates
"/memory@0/available" to report the client about available memory.

This implements changing some device tree properties which we know how
to deal with, the rest is ignored. To allow changes, this skips
fdt_pack() when x-vof=on as not packing the blob leaves some room for
appending.

In absence of SLOF, this assigns phandles to device tree nodes to make
device tree traversing work.

When x-vof=on, this adds "/chosen" every time QEMU (re)builds a tree.

This adds basic instances support which are managed by a hash map
ihandle -> [phandle].

Before the guest started, the used memory is:
0..e60 - the initial firmware
8000..1 - stack
40.. - kernel
3ea.. - initramdisk

This OF CI does not implement "interpret".

Unlike SLOF, this does not format uninitialized nvram. Instead, this
includes a disk image with pre-formatted nvram.

With this basic support, this can only boot into kernel directly.
However this is just enough for the petitboot kernel and initradmdisk to
boot from any possible source. Note this requires reasonably recent guest
kernel with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5be5be8735

The immediate benefit is much faster booting time which especially
crucial with fully emulated early CPU bring up environments. Also this
may come handy when/if GRUB-in-the-userspace sees light of the day.

This separates VOF and sPAPR in a hope that VOF bits may be reused by
other POWERPC boards which do not support pSeries.

This assumes potential support for booting from QEMU backends
such as blockdev or netdev without devices/drivers used.

Signed-off-by: Alexey Kardashevskiy 


Applied to ppc-for-6.1.  However, I'm going to make a number of
comments on minor nits.  If they can be addressed as follow up
patches, I'd appreciate it.

[snip]

diff --git a/pc-bios/vof/vof.h b/pc-bios/vof/vof.h
new file mode 100644
index ..2d8958076907
--- /dev/null
+++ b/pc-bios/vof/vof.h
@@ -0,0 +1,43 @@
+/*
+ * Virtual Open Firmware
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#include 
+
+typedef unsigned char uint8_t;
+typedef unsigned short uint16_t;
+typedef unsigned long uint32_t;
+typedef unsigned long long uint64_t;
+#define NULL (0)
+#define PROM_ERROR (-1u)
+typedef unsigned long ihandle;
+typedef unsigned long phandle;
+typedef int size_t;
+typedef void client(void);


AFAICT 'client' is only used in one place, might as well just open
code it.


+
+/* globals */
+extern void _prom_entry(void); /* OF CI entry point (i.e. this firmware) */
+
+void do_boot(unsigned long addr, unsigned long r3, unsigned long r4);
+
+/* libc */
+int strlen(const char *s);
+int strcmp(const char *s1, const char *s2);
+void *memcpy(void *dest, const void *src, size_t n);
+int memcmp(const void *ptr1, const void *ptr2, size_t n);
+void *memmove(void *dest, const void *src, size_t n);
+void *memset(void *dest, int c, size_t size);
+
+/* CI wrappers */
+void ci_panic(const char *str);
+phandle ci_finddevice(const char *path);
+uint32_t ci_getprop(phandle ph, const char *propname, void *prop, int len);
+
+/* booting from -kernel */
+void boot_from_memory(uint64_t initrd, uint64_t initrdsize);
+
+/* Entry points for CI and RTAS */
+extern uint32_t ci_entry(uint32_t params);
+extern unsigned long hv_rtas(unsigned long params);
+extern unsigned int hv_rtas_size;
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 9e19c570327e..e9b6d0f58756 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -101,6 +101,7 @@

[PATCH REBASED v5 2/2] spapr: nvdimm: Introduce spapr-nvdimm device

2021-07-07 Thread Shivaprasad G Bhat

If the device backend is not persistent memory for the nvdimm, there is
need for explicit IO flushes on the backend to ensure persistence.

On SPAPR, the issue is addressed by adding a new hcall to request for
an explicit flush from the guest when the backend is not pmem. So, the
approach here is to convey when the hcall flush is required in a device
tree property. The guest once it knows the device backend is not pmem,
makes the hcall whenever flush is required.

To set the device tree property, the patch introduces a new papr specific
device type inheriting the nvdimm device. When the backend doesn't have
pmem="yes", the device tree property "ibm,hcall-flush-required" is set,
and the guest makes hcall H_SCM_FLUSH requesting for an explicit flush.

Signed-off-by: Shivaprasad G Bhat 
---
 hw/ppc/spapr_nvdimm.c |   46 +
 include/hw/ppc/spapr_nvdimm.h |4 
 2 files changed, 50 insertions(+)

diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
index 4f8931ab15..4dc7c3f147 100644
--- a/hw/ppc/spapr_nvdimm.c
+++ b/hw/ppc/spapr_nvdimm.c
@@ -54,6 +54,8 @@ bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, 
NVDIMMDevice *nvdimm,
 {
 const MachineClass *mc = MACHINE_GET_CLASS(hotplug_dev);
 const MachineState *ms = MACHINE(hotplug_dev);
+PCDIMMDevice *dimm = PC_DIMM(nvdimm);
+MemoryRegion *mr = host_memory_backend_get_memory(dimm->hostmem);
 g_autofree char *uuidstr = NULL;
 QemuUUID uuid;
 int ret;
@@ -91,6 +93,14 @@ bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, 
NVDIMMDevice *nvdimm,
 return false;
 }
 
+if (object_dynamic_cast(OBJECT(nvdimm), TYPE_SPAPR_NVDIMM) &&
+(memory_region_get_fd(mr) < 0)) {
+error_setg(errp, "spapr-nvdimm device requires the "
+   "memdev %s to be of memory-backend-file type",
+   object_get_canonical_path_component(OBJECT(dimm->hostmem)));
+return false;
+}
+
 return true;
 }
 
@@ -162,6 +172,21 @@ static int spapr_dt_nvdimm(SpaprMachineState *spapr, void 
*fdt,
  "operating-system")));
 _FDT(fdt_setprop(fdt, child_offset, "ibm,cache-flush-required", NULL, 0));
 
+if (object_dynamic_cast(OBJECT(nvdimm), TYPE_SPAPR_NVDIMM)) {
+bool is_pmem = false;
+#ifdef CONFIG_LIBPMEM
+PCDIMMDevice *dimm = PC_DIMM(nvdimm);
+HostMemoryBackend *hostmem = dimm->hostmem;
+
+is_pmem = object_property_get_bool(OBJECT(hostmem), "pmem",
+   _abort);
+#endif
+if (!is_pmem) {
+_FDT(fdt_setprop(fdt, child_offset, "ibm,hcall-flush-required",
+ NULL, 0));
+}
+}
+
 return child_offset;
 }
 
@@ -585,7 +610,16 @@ static target_ulong h_scm_flush(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 }
 
 dimm = PC_DIMM(drc->dev);
+if (!object_dynamic_cast(OBJECT(dimm), TYPE_SPAPR_NVDIMM)) {
+return H_PARAMETER;
+}
+
 backend = MEMORY_BACKEND(dimm->hostmem);
+#ifdef CONFIG_LIBPMEM
+if (object_property_get_bool(OBJECT(backend), "pmem", _abort)) {
+return H_UNSUPPORTED;
+}
+#endif
 fd = memory_region_get_fd(>mr);
 
 if (fd < 0) {
@@ -766,3 +800,15 @@ static void spapr_scm_register_types(void)
 }
 
 type_init(spapr_scm_register_types)
+
+static TypeInfo spapr_nvdimm_info = {
+.name  = TYPE_SPAPR_NVDIMM,
+.parent= TYPE_NVDIMM,
+};
+
+static void spapr_nvdimm_register_types(void)
+{
+type_register_static(_nvdimm_info);
+}
+
+type_init(spapr_nvdimm_register_types)
diff --git a/include/hw/ppc/spapr_nvdimm.h b/include/hw/ppc/spapr_nvdimm.h
index 24d8e37b33..fb4e56418e 100644
--- a/include/hw/ppc/spapr_nvdimm.h
+++ b/include/hw/ppc/spapr_nvdimm.h
@@ -13,6 +13,10 @@
 #include "hw/mem/nvdimm.h"
 #include "migration/vmstate.h"
 
+#define TYPE_SPAPR_NVDIMM "spapr-nvdimm"
+OBJECT_DECLARE_SIMPLE_TYPE(SpaprNVDIMMDevice, SPAPR_NVDIMM)
+
+typedef struct SpaprNVDIMMDevice  SpaprNVDIMMDevice;
 typedef struct SpaprDrc SpaprDrc;
 typedef struct SpaprMachineState SpaprMachineState;

Re: [PATCH v5 2/3] fuzz: add an instrumentation filter

2021-07-07 Thread Alexander Bulekov

On 210629 2341, Alexander Bulekov wrote:
> By default, -fsanitize=fuzzer instruments all code with coverage
> information. However, this means that libfuzzer will track coverage over
> hundreds of source files that are unrelated to virtual-devices. This
> means that libfuzzer will optimize inputs for coverage observed in timer
> code, memory APIs etc. This slows down the fuzzer and stores many inputs
> that are not relevant to the actual virtual-devices.
> 
> With this change, clang versions that support the
> "-fsanitize-coverage-allowlist" will only instrument a subset of the
> compiled code, that is directly related to virtual-devices.
> 
> Signed-off-by: Alexander Bulekov 

Ping?

Are there any other device-related subdirectories we should add to the
filter besides slirp? I'm considering net/ , since it do not seem to
generate much coverage noise, and there might be some tricky codepaths
there that benefit from the coverage guidance.

-Alex

> ---
>  configure| 13 +
>  scripts/oss-fuzz/instrumentation-filter-template | 14 ++
>  2 files changed, 27 insertions(+)
>  create mode 100644 scripts/oss-fuzz/instrumentation-filter-template
> 
> diff --git a/configure b/configure
> index 38704b4e11..3b6ca054b9 100755
> --- a/configure
> +++ b/configure
> @@ -5189,6 +5189,11 @@ if test "$fuzzing" = "yes" && test -z 
> "${LIB_FUZZING_ENGINE+xxx}"; then
>  error_exit "Your compiler doesn't support -fsanitize=fuzzer"
>  exit 1
>fi
> +  have_clang_coverage_filter=no
> +  echo > $TMPTXT
> +  if compile_prog "$CPU_CFLAGS -Werror -fsanitize=fuzzer 
> -fsanitize-coverage-allowlist=$TMPTXT" ""; then
> +  have_clang_coverage_filter=yes
> +  fi
>  fi
>  
>  # Thread sanitizer is, for now, much noisier than the other sanitizers;
> @@ -6120,6 +6125,14 @@ if test "$fuzzing" = "yes" ; then
>  # rule for the fuzzer adds these to the link_args. They need to be
>  # configurable, to support OSS-Fuzz
>  FUZZ_EXE_LDFLAGS="-fsanitize=fuzzer"
> +
> +# Specify a filter to only instrument code that is directly related to
> +# virtual-devices.
> +if test "$have_clang_coverage_filter" = "yes" ; then
> +cp "$source_path/scripts/oss-fuzz/instrumentation-filter-template" \
> +instrumentation-filter
> +QEMU_CFLAGS="$QEMU_CFLAGS 
> -fsanitize-coverage-allowlist=instrumentation-filter"
> +fi
>else
>  FUZZ_EXE_LDFLAGS="$LIB_FUZZING_ENGINE"
>fi
> diff --git a/scripts/oss-fuzz/instrumentation-filter-template 
> b/scripts/oss-fuzz/instrumentation-filter-template
> new file mode 100644
> index 00..44e853159c
> --- /dev/null
> +++ b/scripts/oss-fuzz/instrumentation-filter-template
> @@ -0,0 +1,14 @@
> +# Code that we actually want the fuzzer to target
> +# See: 
> https://clang.llvm.org/docs/SanitizerCoverage.html#disabling-instrumentation-without-source-modification
> +#
> +src:*/hw/*
> +src:*/include/hw/*
> +src:*/slirp/*
> +
> +# We don't care about coverage over fuzzer-specific code, however we should
> +# instrument the fuzzer entry-point so libFuzzer always sees at least some
> +# coverage - otherwise it will exit after the first input
> +src:*/tests/qtest/fuzz/fuzz.c
> +
> +# Enable instrumentation for all functions in those files
> +fun:*
> -- 
> 2.28.0
>

[PATCH REBASED v5 1/2] spapr: nvdimm: Implement H_SCM_FLUSH hcall

2021-07-07 Thread Shivaprasad G Bhat

The patch adds support for the SCM flush hcall for the nvdimm devices.
To be available for exploitation by guest through the next patch.

The hcall expects the semantics such that the flush to return
with one of H_LONG_BUSY when the operation is expected to take longer
time along with a continue_token. The hcall to be called again providing
the continue_token to get the status. So, all fresh requests are put into
a 'pending' list and flush worker is submitted to the thread pool. The
thread pool completion callbacks move the requests to 'completed' list,
which are cleaned up after reporting to guest in subsequent hcalls to
get the status.

The semantics makes it necessary to preserve the continue_tokens and
their return status across migrations. So, the completed flush states
are forwarded to the destination and the pending ones are restarted
at the destination in post_load. The necessary nvdimm flush specific
vmstate structures are added to the spapr machine vmstate.

Signed-off-by: Shivaprasad G Bhat 
---
 hw/ppc/spapr.c|6 +
 hw/ppc/spapr_nvdimm.c |  240 +
 include/hw/ppc/spapr.h|   11 ++
 include/hw/ppc/spapr_nvdimm.h |   13 ++
 4 files changed, 269 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 4dd90b75cc..546d825dde 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1622,6 +1622,8 @@ static void spapr_machine_reset(MachineState *machine)
 spapr->ov5_cas = spapr_ovec_clone(spapr->ov5);
 }
 
+spapr_nvdimm_finish_flushes(spapr);
+
 /* DRC reset may cause a device to be unplugged. This will cause troubles
  * if this device is used by another device (eg, a running vhost backend
  * will crash QEMU if the DIMM holding the vring goes away). To avoid such
@@ -2018,6 +2020,7 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_cap_ccf_assist,
 _spapr_cap_fwnmi,
 _spapr_fwnmi,
+_spapr_nvdimm_states,
 NULL
 }
 };
@@ -3014,6 +3017,9 @@ static void spapr_machine_init(MachineState *machine)
 }
 
 qemu_cond_init(>fwnmi_machine_check_interlock_cond);
+
+QLIST_INIT(>pending_flush_states);
+QLIST_INIT(>completed_flush_states);
 }
 
 #define DEFAULT_KVM_TYPE "auto"
diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
index 91de1052f2..4f8931ab15 100644
--- a/hw/ppc/spapr_nvdimm.c
+++ b/hw/ppc/spapr_nvdimm.c
@@ -22,6 +22,7 @@
  * THE SOFTWARE.
  */
 #include "qemu/osdep.h"
+#include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "hw/ppc/spapr_drc.h"
 #include "hw/ppc/spapr_nvdimm.h"
@@ -30,6 +31,7 @@
 #include "hw/ppc/fdt.h"
 #include "qemu/range.h"
 #include "hw/ppc/spapr_numa.h"
+#include "block/thread-pool.h"
 
 /* DIMM health bitmap bitmap indicators. Taken from kernel's papr_scm.c */
 /* SCM device is unable to persist memory contents */
@@ -375,6 +377,243 @@ static target_ulong h_scm_bind_mem(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 return H_SUCCESS;
 }
 
+static uint64_t flush_token;
+
+static int flush_worker_cb(void *opaque)
+{
+int ret = H_SUCCESS;
+SpaprNVDIMMDeviceFlushState *state = opaque;
+
+/* flush raw backing image */
+if (qemu_fdatasync(state->backend_fd) < 0) {
+error_report("papr_scm: Could not sync nvdimm to backend file: %s",
+ strerror(errno));
+ret = H_HARDWARE;
+}
+
+return ret;
+}
+
+static void spapr_nvdimm_flush_completion_cb(void *opaque, int hcall_ret)
+{
+SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
+SpaprNVDIMMDeviceFlushState *state = opaque;
+
+state->hcall_ret = hcall_ret;
+QLIST_REMOVE(state, node);
+QLIST_INSERT_HEAD(>completed_flush_states, state, node);
+}
+
+static const VMStateDescription vmstate_spapr_nvdimm_flush_state = {
+ .name = "spapr_nvdimm_flush_state",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT64(continue_token, SpaprNVDIMMDeviceFlushState),
+ VMSTATE_INT64(hcall_ret, SpaprNVDIMMDeviceFlushState),
+ VMSTATE_UINT32(drcidx, SpaprNVDIMMDeviceFlushState),
+ VMSTATE_END_OF_LIST()
+ },
+};
+
+static bool spapr_nvdimm_states_needed(void *opaque)
+{
+ SpaprMachineState *spapr = (SpaprMachineState *)opaque;
+
+ return (!QLIST_EMPTY(>pending_flush_states) ||
+ !QLIST_EMPTY(>completed_flush_states));
+}
+
+static int spapr_nvdimm_post_load(void *opaque, int version_id)
+{
+SpaprMachineState *spapr = (SpaprMachineState *)opaque;
+SpaprNVDIMMDeviceFlushState *state, *next;
+PCDIMMDevice *dimm;
+HostMemoryBackend *backend = NULL;
+ThreadPool *pool = aio_get_thread_pool(qemu_get_aio_context());
+SpaprDrc *drc;
+
+QLIST_FOREACH_SAFE(state, >completed_flush_states, node, next) {
+if (flush_token < state->continue_token) {
+flush_token = state->continue_token;
+}
+}
+
+

[PATCH REBASED v5 0/3] spapr: nvdimm: Introduce spapr-nvdimm device

2021-07-07 Thread Shivaprasad G Bhat

If the device backend is not persistent memory for the nvdimm, there
is need for explicit IO flushes to ensure persistence.

On SPAPR, the issue is addressed by adding a new hcall to request for
an explicit flush from the guest when the backend is not pmem.
So, the approach here is to convey when the hcall flush is required
in a device tree property. The guest once it knows the device needs
explicit flushes, makes the hcall as and when required.

It was suggested to create a new device type to address the
explicit flush for such backends on PPC instead of extending the
generic nvdimm device with new property. So, the patch introduces
the spapr-nvdimm device. The new device inherits the nvdimm device
with the new bahviour such that if the backend has pmem=no, the
device tree property is set.

The below demonstration shows the map_sync behavior for non-pmem
backends.
(https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/ndctl.py.data/map_sync.c)

The pmem0 is from spapr-nvdimm with with backend pmem=yes, and pmem1 is
from spapr-nvdimm with pmem=no, mounted as
/dev/pmem0 on /mnt1 type xfs
(rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)
/dev/pmem1 on /mnt2 type xfs
(rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)

[root@atest-guest ~]# ./mapsync /mnt1/newfile > When pmem=yes
[root@atest-guest ~]# ./mapsync /mnt2/newfile > when pmem=no
Failed to mmap with Operation not supported

First patch implements the hcall, adds the necessary
vmstate properties to spapr machine structure for carrying the hcall
status during save-restore. The nature of the hcall being asynchronus,
the patch uses aio utilities to offload the flush. The second patch
introduces the spapr-nvdimm device, adds the device tree property
for the guest when spapr-nvdimm is used with pmem="no" on the backend.

The kernel changes to exploit this hcall is at
https://github.com/linuxppc/linux/commit/75b7c05ebf9026.patch

---
v4 - https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg05982.html
Changes from v4:
- Introduce spapr-nvdimm device with nvdimm device as the parent.
- The new spapr-nvdimm has no new properties. As this is a new
device and there is no migration related dependencies to be
taken care of, the device behavior is made to set the device tree
property and enable hcall when the device type spapr-nvdimm is
used with pmem="no"
- Fixed commit messages
- Added checks to ensure the backend is actualy file and not memory
- Addressed things pointed out by Eric

v3 - https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg07916.html
Changes from v3:
- Fixed the forward declaration coding guideline violations in 1st patch.
- Removed the code waiting for the flushes to complete during migration,
instead restart the flush worker on destination qemu in post load.
- Got rid of the randomization of the flush tokens, using simple
counter.
- Got rid of the redundant flush state lock, relying on the BQL now.
- Handling the memory-backend-ram usage
- Changed the sync-dax symantics from on/off to 'unsafe','writeback' and
'direct'.
Added prevention code using 'writeback' on arm and x86_64.
- Fixed all the miscellaneous comments.

v2 - https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg07031.html
Changes from v2:
- Using the thread pool based approach as suggested
- Moved the async hcall handling code to spapr_nvdimm.c along
with some simplifications
- Added vmstate to preserve the hcall status during save-restore
along with pre_save handler code to complete all ongoning flushes.
- Added hw_compat magic for sync-dax 'on' on previous machines.
- Miscellanious minor fixes.

v1 - https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg06330.html
Changes from v1
- Fixed a missed-out unlock
- using QLIST_FOREACH instead of QLIST_FOREACH_SAFE while generating token

Shivaprasad G Bhat (2):
spapr: nvdimm: Implement H_SCM_FLUSH hcall
spapr: nvdimm: Introduce spapr-nvdimm device

hw/ppc/spapr.c|6 +
hw/ppc/spapr_nvdimm.c | 286 +
include/hw/ppc/spapr.h| 11 +-
include/hw/ppc/spapr_nvdimm.h | 17 ++
4 files changed, 319 insertions(+), 1 deletion(-)

--
Signature

RE: [PATCH] migration: Move bitmap_mutex out of migration_bitmap_clear_dirty()

2021-07-07 Thread Wang, Wei W

On Thursday, July 8, 2021 12:55 AM, Peter Xu wrote:
> On Wed, Jul 07, 2021 at 08:34:50AM +, Wang, Wei W wrote:
> > On Wednesday, July 7, 2021 1:47 AM, Peter Xu wrote:
> > > On Sat, Jul 03, 2021 at 02:53:27AM +, Wang, Wei W wrote:
> > > > +   do {
> > > > +page_to_clear = start + (i++ <<
> > > > + block->clear_bmap_shift);
> > >
> > > Why "i" needs to be shifted?
> >
> > Just move to the next clear chunk, no?
> > For example, (1 << 18) pages chunk (i.e. 1GB).
> 
> But migration_clear_memory_region_dirty_bitmap() has done the shifting?
> 

Please see this example: start=0, npages = 2 * (1 <<18), i.e. we have 2 chunks 
of pages to clear, and start from 0.
First chunk: from 0 to (1 <<18);
Second chunk: from (1 << 18) to 2*(1<<18).

To clear the second chunk, we need to pass (start + "1 << 18") to 
migration_clear_memory_region_dirty_bitmap(),
and clear_bmap_test_and_clear() there will do ">>18" to transform it into the 
id of clear_bitmap, which is 1.

Best,
Wei

RE: [PATCH] migration: Move bitmap_mutex out of migration_bitmap_clear_dirty()

2021-07-07 Thread Wang, Wei W

On Thursday, July 8, 2021 12:44 AM, Peter Xu wrote:
> > > Not to mention the hard migration issues are mostly with non-idle
> > > guest, in that case having the balloon in the guest will be
> > > disastrous from this pov since it'll start to take mutex for each
> > > page, while balloon would hardly report anything valid since most guest 
> > > pages
> are being used.
> >
> > If no pages are reported, migration thread wouldn't wait on the lock then.
> 
> Yes I think this is the place I didn't make myself clear.  It's not about 
> sleeping, it's
> about the cmpxchg being expensive already when the vm is huge.

OK.
How did you root cause that it's caused by cmpxchg, instead of lock contention 
(i.e. syscall and sleep) or
some other code inside pthread_mutex_lock(). Do you have cycles about cmpxchg 
v.s. cycles of pthread_mutex_lock()?

I check the implementation of pthread_mutex_lock(). The code path for lock 
acquire is long. QemuSpin looks more efficient.
(probably we also don’t want migration thread to sleep in any case)

I think it's also better to see the comparison of migration throughput data 
(i.e. pages per second) in the following cases, before we make a decision:
- per-page mutex
- per-page spinlock
- 50-ms mutex

Best,
Wei

Re: [PATCH qemu v22] spapr: Implement Open Firmware client interface

On Fri, Jun 25, 2021 at 03:51:55PM +1000, Alexey Kardashevskiy wrote:
> The PAPR platform describes an OS environment that's presented by
> a combination of a hypervisor and firmware. The features it specifies
> require collaboration between the firmware and the hypervisor.
> 
> Since the beginning, the runtime component of the firmware (RTAS) has
> been implemented as a 20 byte shim which simply forwards it to
> a hypercall implemented in qemu. The boot time firmware component is
> SLOF - but a build that's specific to qemu, and has always needed to be
> updated in sync with it. Even though we've managed to limit the amount
> of runtime communication we need between qemu and SLOF, there's some,
> and it has become increasingly awkward to handle as we've implemented
> new features.
> 
> This implements a boot time OF client interface (CI) which is
> enabled by a new "x-vof" pseries machine option (stands for "Virtual Open
> Firmware). When enabled, QEMU implements the custom H_OF_CLIENT hcall
> which implements Open Firmware Client Interface (OF CI). This allows
> using a smaller stateless firmware which does not have to manage
> the device tree.
> 
> The new "vof.bin" firmware image is included with source code under
> pc-bios/. It also includes RTAS blob.
> 
> This implements a handful of CI methods just to get -kernel/-initrd
> working. In particular, this implements the device tree fetching and
> simple memory allocator - "claim" (an OF CI memory allocator) and updates
> "/memory@0/available" to report the client about available memory.
> 
> This implements changing some device tree properties which we know how
> to deal with, the rest is ignored. To allow changes, this skips
> fdt_pack() when x-vof=on as not packing the blob leaves some room for
> appending.
> 
> In absence of SLOF, this assigns phandles to device tree nodes to make
> device tree traversing work.
> 
> When x-vof=on, this adds "/chosen" every time QEMU (re)builds a tree.
> 
> This adds basic instances support which are managed by a hash map
> ihandle -> [phandle].
> 
> Before the guest started, the used memory is:
> 0..e60 - the initial firmware
> 8000..1 - stack
> 40.. - kernel
> 3ea.. - initramdisk
> 
> This OF CI does not implement "interpret".
> 
> Unlike SLOF, this does not format uninitialized nvram. Instead, this
> includes a disk image with pre-formatted nvram.
> 
> With this basic support, this can only boot into kernel directly.
> However this is just enough for the petitboot kernel and initradmdisk to
> boot from any possible source. Note this requires reasonably recent guest
> kernel with:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5be5be8735
> 
> The immediate benefit is much faster booting time which especially
> crucial with fully emulated early CPU bring up environments. Also this
> may come handy when/if GRUB-in-the-userspace sees light of the day.
> 
> This separates VOF and sPAPR in a hope that VOF bits may be reused by
> other POWERPC boards which do not support pSeries.
> 
> This assumes potential support for booting from QEMU backends
> such as blockdev or netdev without devices/drivers used.
> 
> Signed-off-by: Alexey Kardashevskiy 

Applied to ppc-for-6.1.  However, I'm going to make a number of
comments on minor nits.  If they can be addressed as follow up
patches, I'd appreciate it.

[snip]
> diff --git a/pc-bios/vof/vof.h b/pc-bios/vof/vof.h
> new file mode 100644
> index ..2d8958076907
> --- /dev/null
> +++ b/pc-bios/vof/vof.h
> @@ -0,0 +1,43 @@
> +/*
> + * Virtual Open Firmware
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +#include 
> +
> +typedef unsigned char uint8_t;
> +typedef unsigned short uint16_t;
> +typedef unsigned long uint32_t;
> +typedef unsigned long long uint64_t;
> +#define NULL (0)
> +#define PROM_ERROR (-1u)
> +typedef unsigned long ihandle;
> +typedef unsigned long phandle;
> +typedef int size_t;
> +typedef void client(void);

AFAICT 'client' is only used in one place, might as well just open
code it.

> +
> +/* globals */
> +extern void _prom_entry(void); /* OF CI entry point (i.e. this firmware) */
> +
> +void do_boot(unsigned long addr, unsigned long r3, unsigned long r4);
> +
> +/* libc */
> +int strlen(const char *s);
> +int strcmp(const char *s1, const char *s2);
> +void *memcpy(void *dest, const void *src, size_t n);
> +int memcmp(const void *ptr1, const void *ptr2, size_t n);
> +void *memmove(void *dest, const void *src, size_t n);
> +void *memset(void *dest, int c, size_t size);
> +
> +/* CI wrappers */
> +void ci_panic(const char *str);
> +phandle ci_finddevice(const char *path);
> +uint32_t ci_getprop(phandle ph, const char *propname, void *prop, int len);
> +
> +/* booting from -kernel */
> +void boot_from_memory(uint64_t initrd, uint64_t initrdsize);
> +
> +/* Entry points for CI and RTAS */
> +extern uint32_t ci_entry(uint32_t params);
> +extern unsigned long hv_rtas(unsigned long params);
>

Re: pipe2 & configure script

2021-07-07 Thread Richard Zak

În mie., 7 iul. 2021 la 10:32, Paolo Bonzini  a scris:

> On 07/07/21 05:24, Richard Zak wrote:
> > What conditions are required for "#define CONFIG_PIPE2" to be set in
> > build/config-host.h? It prevents building for Haiku as pipe2() doesn't
> > exist. I didn't see anything in the configure script regarding pipe2. I
> > also updated my code to the latest in the repository and this issue just
> > popped up.
>
> Does this help?
>
> diff --git a/meson.build b/meson.build
> index 660e294b7e..32d5bd3685 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1339,7 +1339,7 @@ config_host_data.set('HAVE_STRUCT_STAT_ST_ATIM',
>   config_host_data.set('CONFIG_EVENTFD', cc.compiles('''
> #include 
> int main(void) { return eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); }'''))
> -config_host_data.set('CONFIG_FDATASYNC', cc.compiles(gnu_source_prefix +
> '''
> +config_host_data.set('CONFIG_FDATASYNC', cc.links(gnu_source_prefix + '''
> #include 
> int main(void) {
> #if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
> @@ -1356,14 +1356,14 @@ config_host_data.set('CONFIG_MADVISE',
> cc.compiles(gnu_source_prefix + '''
>   config_host_data.set('CONFIG_MEMFD', cc.compiles(gnu_source_prefix + '''
> #include 
> int main(void) { return memfd_create("foo", MFD_ALLOW_SEALING); }'''))
> -config_host_data.set('CONFIG_OPEN_BY_HANDLE',
> cc.compiles(gnu_source_prefix + '''
> +config_host_data.set('CONFIG_OPEN_BY_HANDLE', cc.links(gnu_source_prefix
> + '''
> #include 
> #if !defined(AT_EMPTY_PATH)
> # error missing definition
> #else
> int main(void) { struct file_handle fh; return open_by_handle_at(0,
> , 0); }
> #endif'''))
> -config_host_data.set('CONFIG_PIPE2', cc.compiles(gnu_source_prefix + '''
> +config_host_data.set('CONFIG_PIPE2', cc.links(gnu_source_prefix + '''
> #include 
> #include 
>
> ?
>
> Paolo
>
>
That did it! build/config-host.h now has "#undef CONFIG_PIPE2" and the code
compiles.

-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

Re: [PATCH v8 3/3] target/i386: Correct implementation for FCS, FIP, FDS and FDP

2021-07-07 Thread Ziqiao Kong

Hello!

Thanks for applying fixes for me. Is there anything else I should do?

Ziqiao


On Thu, Jul 8, 2021 at 6:24 AM Richard Henderson
 wrote:
>
> From: Ziqiao Kong 
>
> Update FCS:FIP and FDS:FDP according to the Intel Manual Vol.1 8.1.8.
> Note that CPUID.(EAX=07H,ECX=0H):EBX[bit 13] is not implemented by
> design in this patch and will be added along with TCG features flag
> in a separate patch later.
>
> Signed-off-by: Ziqiao Kong 
> Message-Id: <20210530150112.74411-2-ziqiaok...@gmail.com>
> [rth: Push FDS/FDP handling down into mod != 3 case; free last_addr.]
> Signed-off-by: Richard Henderson 
> ---
>  target/i386/cpu.h|  2 ++
>  target/i386/tcg/fpu_helper.c | 20 ++---
>  target/i386/tcg/translate.c  | 43 +++-
>  3 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 0f7ddbfeae..8921bf5318 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1435,6 +1435,8 @@ typedef struct CPUX86State {
>  FPReg fpregs[8];
>  /* KVM-only so far */
>  uint16_t fpop;
> +uint16_t fpcs;
> +uint16_t fpds;
>  uint64_t fpip;
>  uint64_t fpdp;
>
> diff --git a/target/i386/tcg/fpu_helper.c b/target/i386/tcg/fpu_helper.c
> index beb63be432..cdd8e9f947 100644
> --- a/target/i386/tcg/fpu_helper.c
> +++ b/target/i386/tcg/fpu_helper.c
> @@ -731,6 +731,10 @@ static void do_fninit(CPUX86State *env)
>  {
>  env->fpus = 0;
>  env->fpstt = 0;
> +env->fpcs = 0;
> +env->fpds = 0;
> +env->fpip = 0;
> +env->fpdp = 0;
>  cpu_set_fpuc(env, 0x37f);
>  env->fptags[0] = 1;
>  env->fptags[1] = 1;
> @@ -2378,19 +2382,19 @@ static void do_fstenv(CPUX86State *env, target_ulong 
> ptr, int data32,
>  cpu_stl_data_ra(env, ptr, env->fpuc, retaddr);
>  cpu_stl_data_ra(env, ptr + 4, fpus, retaddr);
>  cpu_stl_data_ra(env, ptr + 8, fptag, retaddr);
> -cpu_stl_data_ra(env, ptr + 12, 0, retaddr); /* fpip */
> -cpu_stl_data_ra(env, ptr + 16, 0, retaddr); /* fpcs */
> -cpu_stl_data_ra(env, ptr + 20, 0, retaddr); /* fpoo */
> -cpu_stl_data_ra(env, ptr + 24, 0, retaddr); /* fpos */
> +cpu_stl_data_ra(env, ptr + 12, env->fpip, retaddr); /* fpip */
> +cpu_stl_data_ra(env, ptr + 16, env->fpcs, retaddr); /* fpcs */
> +cpu_stl_data_ra(env, ptr + 20, env->fpdp, retaddr); /* fpoo */
> +cpu_stl_data_ra(env, ptr + 24, env->fpds, retaddr); /* fpos */
>  } else {
>  /* 16 bit */
>  cpu_stw_data_ra(env, ptr, env->fpuc, retaddr);
>  cpu_stw_data_ra(env, ptr + 2, fpus, retaddr);
>  cpu_stw_data_ra(env, ptr + 4, fptag, retaddr);
> -cpu_stw_data_ra(env, ptr + 6, 0, retaddr);
> -cpu_stw_data_ra(env, ptr + 8, 0, retaddr);
> -cpu_stw_data_ra(env, ptr + 10, 0, retaddr);
> -cpu_stw_data_ra(env, ptr + 12, 0, retaddr);
> +cpu_stw_data_ra(env, ptr + 6, env->fpip, retaddr);
> +cpu_stw_data_ra(env, ptr + 8, env->fpcs, retaddr);
> +cpu_stw_data_ra(env, ptr + 10, env->fpdp, retaddr);
> +cpu_stw_data_ra(env, ptr + 12, env->fpds, retaddr);
>  }
>  }
>
> diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
> index 886d3d80f3..888ead0d49 100644
> --- a/target/i386/tcg/translate.c
> +++ b/target/i386/tcg/translate.c
> @@ -5930,6 +5930,8 @@ static target_ulong disas_insn(DisasContext *s, 
> CPUState *cpu)
>  /* floats */
>  case 0xd8 ... 0xdf:
>  {
> +bool update_fip = true;
> +
>  if (s->flags & (HF_EM_MASK | HF_TS_MASK)) {
>  /* if CR0.EM or CR0.TS are set, generate an FPU exception */
>  /* XXX: what to do if illegal op ? */
> @@ -5942,7 +5944,14 @@ static target_ulong disas_insn(DisasContext *s, 
> CPUState *cpu)
>  op = ((b & 7) << 3) | ((modrm >> 3) & 7);
>  if (mod != 3) {
>  /* memory op */
> -gen_lea_modrm(env, s, modrm);
> +AddressParts a = gen_lea_modrm_0(env, s, modrm);
> +TCGv ea = gen_lea_modrm_1(s, a);
> +TCGv last_addr = tcg_temp_new();
> +bool update_fdp = true;
> +
> +tcg_gen_mov_tl(last_addr, ea);
> +gen_lea_v_seg(s, s->aflag, ea, a.def_seg, s->override);
> +
>  switch (op) {
>  case 0x00 ... 0x07: /* fxxxs */
>  case 0x10 ... 0x17: /* fixxxl */
> @@ -6070,20 +6079,24 @@ static target_ulong disas_insn(DisasContext *s, 
> CPUState *cpu)
>  case 0x0c: /* fldenv mem */
>  gen_helper_fldenv(cpu_env, s->A0,
>tcg_const_i32(dflag - 1));
> +update_fip = update_fdp = false;
>  break;
>  case 0x0d: /* fldcw mem */
>  tcg_gen_qemu_ld_i32(s->tmp2_i32, s->A0,
>

Re: [PATCH 6/6] python: add entry point for aqmp-tui

On Fri, Jul 2, 2021 at 5:26 PM G S Niteesh Babu 
wrote:

> Add an entry point for aqmp-tui. This will allow it to be run from
> the command line using "aqmp-tui -a localhost:1234"
>
> Signed-off-by: G S Niteesh Babu 
> ---
>  python/setup.cfg | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/python/setup.cfg b/python/setup.cfg
> index 4782fe5241..23e30185f4 100644
> --- a/python/setup.cfg
> +++ b/python/setup.cfg
> @@ -68,6 +68,7 @@ console_scripts =
>  qom-fuse = qemu.qmp.qom_fuse:QOMFuse.entry_point [fuse]
>  qemu-ga-client = qemu.qmp.qemu_ga_client:main
>  qmp-shell = qemu.qmp.qmp_shell:main
> +aqmp-tui = qemu.aqmp.aqmp_tui:main
>

I was going to suggest that you could use [tui] at the end here to protect
the script from being run when we don't have the optional dependency group
installed, but even with it, I get a pretty nasty error:

Traceback (most recent call last):
  File "/home/jsnow/src/qemu/python/.pyvenv/bin/aqmp-tui", line 33, in

sys.exit(load_entry_point('qemu==0.6.1.0a1', 'console_scripts',
'aqmp-tui')())
  File "/home/jsnow/src/qemu/python/.pyvenv/bin/aqmp-tui", line 25, in
importlib_load_entry_point
return next(matches).load()
  File "/usr/lib64/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib64/python3.9/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 855, in exec_module
  File "", line 228, in
_call_with_frames_removed
  File
"/home/jsnow/src/qemu/python/.pyvenv/lib64/python3.9/site-packages/qemu/aqmp/aqmp_tui.py",
line 14, in 
from pygments import lexers
ModuleNotFoundError: No module named 'pygments'

It looks like this feature isn't working for me ... I'm not sure I know why.

In theory it should work:
https://setuptools.readthedocs.io/en/latest/userguide/entry_point.html#dependency-management

We might have to make our own custom entry point script that guards this a
little bit better if we can't solve this mystery. The goal is either to:

(1) Do not install an aqmp-tui script at all if we don't select the
optional TUI group, or
(2) Have the script error out early with a nice error message explaining
what optional dependencies it requires.


>
>  [flake8]
>  extend-ignore = E722  # Prefer pylint's bare-except checks to flake8's
> --
> 2.17.1
>
>

Re: [PATCH 2/6] python: Add dependencies for AQMP TUI