ing a potential source of confusion; and as it's cheap to add let's
just do so.
Signed-off-by: Thomas Lamprecht
---
docs/interop/qemu-ga.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/interop/qemu-ga.rst b/docs/interop/qemu-ga.rst
index 72fb75a6f5..dd4245ece8 100644
--- a
On 28/10/2022 09:11, Fiona Ebner wrote:
> Am 27.10.22 um 14:17 schrieb Daniel P. Berrangé:
>> On Thu, Oct 27, 2022 at 12:14:43PM +0200, Fiona Ebner wrote:
>>> +warn_report("not removing PID file on exit: cannot resolve PID
>>> file"
>>> +" path: %s: %s", pid_fil
On 11.11.21 12:32, Igor Mammedov wrote:
> On Thu, 11 Nov 2021 03:34:37 -0500
> "Michael S. Tsirkin" wrote:
>
>> On Wed, Nov 10, 2021 at 04:11:40PM -0500, Igor Mammedov wrote:
>>> From: Julia Suvorova
>>>
>>> The changes are the result of
>>> 'hw/i386/acpi-build: Deny control on PCIe Nati
On 08.04.21 14:49, Markus Armbruster wrote:
> Kevin Wolf writes:
>> Am 08.04.2021 um 11:21 hat Markus Armbruster geschrieben:
>>> Should this go into 6.0?
>>
>> This is something that the responsible maintainer needs to decide.
>
> Yes, and that's me. I'm soliciting opinions.
>
>> If it helps y
On 23.03.21 15:55, Vitaly Cheptsov wrote:
>> 23 марта 2021 г., в 17:48, Michael S. Tsirkin написал(а):
>>
>> The issue is with people who installed a VM using 5.1 qemu,
>> migrated to 5.2, booted there and set a config on a device
>> e.g. IP on a NIC.
>> They now have a 5.1 machine type but changi
On 23.03.21 12:53, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
Just saw this patch by accident and as we also use the alabaster theme
for the Proxmox Backup project I wanted to share some insights from our
usage, as I checked that theme out closely a few months ago and did som
t; Cc: qemu-devel@nongnu.org
> Reported-by: Thomas Lamprecht
> Suggested-by: Michael S. Tsirkin
> Signed-off-by: Vitaly Cheptsov
Thanks for sending this! Works as advertised and can be cleanly cherry-picked
on top of the v5.2.0 tag.
Tested-by: Thomas Lamprecht
On 01.03.21 15:20, Igor Mammedov wrote:
> On Mon, 1 Mar 2021 08:45:53 +0100
> Thomas Lamprecht wrote:
>> On 01.03.21 08:20, Michael S. Tsirkin wrote:
>>> There are various testing efforts the reason this got undetected is
>>> because it does not affect linux guests,
On 01.03.21 08:20, Michael S. Tsirkin wrote:
> On Mon, Mar 01, 2021 at 08:12:35AM +0100, Thomas Lamprecht wrote:
>> On 28.02.21 21:43, Michael S. Tsirkin wrote:
>>> Sure. The way to do that is to tie old behaviour to old machine
>>> versions. We'll need it in
On 28.02.21 21:43, Michael S. Tsirkin wrote:
> Sure. The way to do that is to tie old behaviour to old machine
> versions. We'll need it in stable too ...
Yeah, using machine types is how its meant to be with solving migration
breakage, sure.
But that means we have to permanently pin the VM, and a
Hi Vitaly,
On 28.02.21 10:11, vit9696 wrote:
> For us this breaks the ability to control the boot options between the
> operating system and the OVMF. It happens because the operating system builds
> the DPs based on ACPI (in fact the only source available to it), while OVMF
> uses another sour
On 30.07.20 17:58, Michael S. Tsirkin wrote:
> macOS uses ACPI UIDs to build the DevicePath for NVRAM boot options,
> while OVMF firmware gets them via an internal channel through QEMU.
> Due to a bug in QEMU ACPI currently UEFI firmware and ACPI have
> different values, and this makes the underlyi
On 5/12/20 4:43 PM, Kevin Wolf wrote:
> Stefan (Reiter), after looking a bit closer at this, I think there is no
> bug in QEMU, but the bug is in your coroutine code that calls block
> layer functions without moving into the right AioContext first. I've
> written this series anyway as it potentiall
On 5/12/20 4:43 PM, Kevin Wolf wrote:
> Coroutine functions that are entered through bdrv_run_co() are already
> safe to call from synchronous code in a different AioContext because
> bdrv_coroutine_enter() will schedule them in the context of the node.
>
> However, the coroutine fastpath still re
On 4/2/20 7:10 PM, Kevin Wolf wrote:
> Am 02.04.2020 um 18:47 hat Kevin Wolf geschrieben:
>> So I think this is the bug: Calling blk_wait_while_drained() from
>> anywhere between blk_inc_in_flight() and blk_dec_in_flight() is wrong
>> because it will deadlock the drain operation.
>>
>> blk_aio_read
Hi,
On 06/02/2017 01:42 PM, Marc-André Lureau wrote:
Hi
On Thu, Jun 1, 2017 at 5:08 PM Thomas Lamprecht
wrote:
glib depends on libpcre which was not shipped with the MSI, thus
starting of the qemu-ga.exe failed with the respective error message.
Tell WIXL to ship this library with the MSI
glib depends on libpcre which was not shipped with the MSI, thus
starting of the qemu-ga.exe failed with the respective error message.
Tell WIXL to ship this library with the MSI to avoid this problem.
Signed-off-by: Thomas Lamprecht
CC: Stefan Weil
CC: Michael Roth
---
I haven't done
I can partly confirm this, see (and parents):
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04048.html
It sounds just a little strange to me, so I'll recheck to be double sure
every configure option is the same on my Arch Linux and Debian machine.
--
You received this bug notification
On 05/23/2016 11:39 PM, Thomas Lamprecht wrote:
> Hi,
>
> sorry for the delay.
>
> On 20.05.2016 12:06, Gerd Hoffmann wrote:
>>Hi,
>>
>>> ./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom
>>> W7SP1_PROFESSIONAL.iso -m 1024 -smp 2 -enable-kvm -cp
Hi,
sorry for the delay.
On 20.05.2016 12:06, Gerd Hoffmann wrote:
Hi,
./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom
W7SP1_PROFESSIONAL.iso -m 1024 -smp 2 -enable-kvm -cpu host -drive
if=pflash,format=raw,unit=0,readonly,file=OVMF_CODE-pure-efi.fd -drive
if=pflash,format=raw,unit=1,fi
Hi,
On 05/17/2016 12:50 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> This way we can allow guests update sr[] registers as they want, without
>>> allowing them disrupt vbe video modes that way.
>> Just documenting my test with the patch here:
>>
>> This fixes the issue with QEMU 2.5.1.1 but only if I'm
with this patch but
with OVMF still not.
best regards,
Thomas
>
> Reported-by: Thomas Lamprecht
> Signed-off-by: Gerd Hoffmann
> ---
> hw/display/vga.c | 50 --
> hw/display/vga_int.h | 1 +
> 2 files changed, 29 in
On 15.05.2016 11:28, Stefan Weil wrote:
> Am 15.05.2016 um 01:13 schrieb Thomas Lamprecht:
>> Hi all,
>>
>> I recently ran into Problems when trying to install some Windows VMs
>> this was after an update to QEMU 2.5.1.1, the VM shows Windows loading
>> fil
Public bug reported:
Hi,
As already posted on the QEMU devel list [1] I stumbled upon a problem
with QEMU in version 2.5.1.1 and 2.6.0.
the VM shows Windows loading
files for the installation, then the "Starting Windows" screen appears
here it hangs and never continues.
Changing the "-vga" opti
Hi all,
I recently ran into Problems when trying to install some Windows VMs
this was after an update to QEMU 2.5.1.1, the VM shows Windows loading
files for the installation, then the "Starting Windows" screen appears
here it hangs and never continues.
Changing the "-vga" option to cirrus solves
hi,
this message would probably be better suited on the qemu-discuss list
not the devel.
comments inline.
On 13.04.2016 09:43, Gilar Dwitresna wrote:
> hi,
> I have done make implementation of qemu-kvm instalation for live
> migration on ubuntu with sharing storage (NFS) configuration.
> the qe
On 08/17/2015 08:58 PM, Eduardo Habkost wrote:
On Thu, Aug 13, 2015 at 11:30:57AM -0400, Richard Smith wrote:
On 08/09/2015 09:48 PM, Ed Swierk wrote:
References to coreboot commits: * Original commit adding code reading
register offsets 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x56, 0x57 to
Int
27 matches
Mail list logo
