similar to: RE: Re: [PATCH 2/2] Virtual frame buffer: user space backend

On Wed, Mar 04, 2020 at 03:48:34PM +0100, Markus Armbruster wrote: > I understand libguestfs comes with integration tests. You might be > interested in something I'm developing for QEMU 5.0 to permit "testing > the future". I'd like to ensure it is actually useful before I > continue. Let me know what you think. > > = Motivation = > > When layers

Hello, I''m coding a 2D map editor for a small game engine and I''m running into blitting problems. The bigger my map is, the longer it takes to blit a tile on it. sometimes, when I try to draw a tile to fast, it even fails completely at blitting and I have to close and reopen the program for it to work again. I have attached the main drawing methods to this post. How it works:

New /sys/hypervisor/uuid, containing this domain''s UUID. Stripping off /vm/ from the value of vm to get the UUID isn''t exactly nice. The alternative is to add a XENVER_get_uuid code to HYPERVISOR_xen_version(), but I''m not sure that''s worth it. Signed-off-by: Markus Armbruster <armbru@redhat.com> diff -r ddba92a5cba9 drivers/xen/core/xen_sysfs.c ---

Peter Maydell <peter.maydell@linaro.org> writes: > On Mon, 14 Sep 2020 at 09:55, Markus Armbruster <armbru@redhat.com> wrote: >> >> New option -compat lets you configure what to do when deprecated >> interfaces get used. This is intended for testing users of the >> management interfaces. It is experimental. >> >> -compat

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1306311631 -3600 # Node ID 6b1fe0cba8a2f0bcc1274c8e777da5b6c198b45d # Parent 8258c5a0ba35de937597e2c516bc88f8ebe1be35 libxl: use preferred syntax for network device creation with upstream qemu Markus Armbruster points out in <m3r582pzc1.fsf@blackfin.pond.sub.org> on qemu-devel that this is the prefered syntax

When enabling interrupts fails, the interrupt enable bit remains set in i8042_ctr. Later writes of i8042_ctr to the hardware could accidentally retry enabling interrupts. Clear the bit on failure. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> --- Some time ago Steven Rostedt and I went over this changeset: commit

When enabling interrupts fails, the interrupt enable bit remains set in i8042_ctr. Later writes of i8042_ctr to the hardware could accidentally retry enabling interrupts. Clear the bit on failure. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> --- Some time ago Steven Rostedt and I went over this changeset: commit

We need to detach the blkdev from the BlockDriverState before calling bdrv_delete. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> CC: Markus Armbruster <armbru@redhat.com> --- hw/xen_disk.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/xen_disk.c b/hw/xen_disk.c index 68fa36a..bf06fc1 100644 --- a/hw/xen_disk.c +++ b/hw/xen_disk.c

Frontends are expected to write their protocol ABI to xenstore. Since the protocol ABI defaults to the backend's native ABI, things work fine without that as long as the frontend's native ABI is identical to the backend's native ABI. This is not the case for xen-blkfront running 32-on-64, because its ABI differs between 32 and 64 bit, and thus needs this fix. Based on

Frontends are expected to write their protocol ABI to xenstore. Since the protocol ABI defaults to the backend's native ABI, things work fine without that as long as the frontend's native ABI is identical to the backend's native ABI. This is not the case for xen-blkfront running 32-on-64, because its ABI differs between 32 and 64 bit, and thus needs this fix. Based on

On Thu, 12 Jun 2014 08:48:04 +0200 Markus Armbruster <armbru at redhat.com> wrote: > Vincent JARDIN <vincent.jardin at 6wind.com> writes: > > > On 10/06/2014 18:48, Henning Schild wrote:> Hi, > >> In a first prototype i implemented a ivshmem[2] device for the > >> hypervisor. That way we can share memory between virtual machines. > >> Ivshmem

On Mon, 14 Sep 2020 at 09:55, Markus Armbruster <armbru@redhat.com> wrote: > > New option -compat lets you configure what to do when deprecated > interfaces get used. This is intended for testing users of the > management interfaces. It is experimental. > > -compat deprecated-input=<in-policy> configures what to do when > deprecated input is received. Available

Hi On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster <armbru@redhat.com> wrote: > > This series extends QMP introspection to cover deprecation. > Additionally, new option -compat lets you configure what to do when > deprecated interfaces get used. This is intended for testing users of > the management interfaces. It is experimental. > > -compat

On 8/20/20 2:47 PM, Topper, Craig wrote: > > I think I’m still missing something here. The configuration is per > tile. The multiply instructions take a MxK tile and multiply it by a > KxN tile and accumulate into an MxN tile. So the configuration needs > to know how many of each size of tile it needs to avoid a spill. > Wouldn’t the register allocator then need to know which

Hi, I have seen a lot of unused xen-vncfb. Can they be kill manually ? Does "domid" run sequentially ? Will it be safe for me to execute "kill -9 12614 11905 10581 11037 11688" below ? Kindly advice. Thanks !! ================================================================= [root@machine xen]# ps -ef | grep -i dbn0 root 10581 1 0 10:02 ? 00:00:00

Without console= arguments on the kernel command line, the first console to register becomes enabled and the preferred console (the one behind /dev/console). This is tty (assuming CONFIG_VT_CONSOLE is enabled, which it commonly is). This is okay as long tty is a useful console. But unless we have the PV framebuffer, and it is enabled for this domain, tty0 in domU is merely a dummy. In that

Without console= arguments on the kernel command line, the first console to register becomes enabled and the preferred console (the one behind /dev/console). This is tty (assuming CONFIG_VT_CONSOLE is enabled, which it commonly is). This is okay as long tty is a useful console. But unless we have the PV framebuffer, and it is enabled for this domain, tty0 in domU is merely a dummy. In that

Without console= arguments on the kernel command line, the first console to register becomes enabled and the preferred console (the one behind /dev/console). This is tty (assuming CONFIG_VT_CONSOLE is enabled, which it commonly is). This is okay as long tty is a useful console. But unless we have the PV framebuffer, and it is enabled for this domain, tty0 in domU is merely a dummy. In that

Hi Hal, The proposal is attractive to me, but there is something I still can't figure out. Let's take below MIR as an example. We assume we have 256 register classes (vtile1x1, vtile1x2, ..., tile16x16). 1. After instruction selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as

> When the tile shape is unknown at compile time, how do you plan to do the register allocation of the tiles? My question is: do you do the allocation for this case in the same way as you would if you knew the size was 16x16 (i.e., conservatively assume the largest size)? I think what will happen is that the registers are allocated based on a number of runtime values that are assumed to be