Public bug reported:
Firefox hangs once it starts to load pages. I tried to delete
.cache/mozilla/ and .mozilla/ but it doesn't help. But if I mount tmpfs
on to .mozilla (not necessary for .cache/mozilla/), pages loads fine.
I started the vm as root (sudo) with the following command: qemu-system-
Public bug reported:
Emacs (gtk3) exited with bus error and core dumped with -vga qxl. If I
use the builtin modesetting xorg driver, emacs could survive for a short
while sometimes. If I use xf86-video-qxl (git r587.8babd05), it dies
right away with the same error. It seems to corrupt xorg at some
Public bug reported:
qemu shows the following warning with glib2 2.46.0:
[tom@localhost ~]$ qemu-system-x86_64
(process:4222): GLib-WARNING **: gmem.c:482: custom memory allocation
vtable not supported
fwiw process 4222 is qemu-system-x86_64
** Affects: qemu
Importance: Undecided
Public bug reported:
I am not exactly sure if this is a bug, but I don't see why the option
"serial" should be required for -device nvme like the option "drive".
Truth is it seem to accept random string as its value anyway, if that's
the case, couldn't qemu just generate one for it when it's not
s
** Attachment added: "UEFI boot entry of the first NVMe device"
https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650554/+files/03.png
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1576347
Public bug reported:
Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m
4G -net bridge -net nic -full-screen -drive
file=ovmf_x64.bin,format=raw,if=pflash -drive
file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive
file=disks/one.img,if=none,format=qcow2,id=one -dri
You can see from the "SCSI name string" that the working NVMe device is
the second one specified in the command.
** Attachment added: "sg_vpd outputs"
https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650553/+files/02.PNG
--
You received this bug notification because you are a member
** Attachment added: "UEFI boot entry of the second NVMe device"
https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650555/+files/04.png
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/157634
Instead of requiring a serial of arbitrary length/format, I think a
WWN/EUI-64 is more useful/important, not to mention that the WWN/EUI-64
can pretty much always be used as the serial at the same time.
Unlike Linux, Windows consider the WWN/EUI-64 as the "serial":
"C:\Windows\system32>sg_vpd -i
"if=virtio" (which similarly has one controller per drive and has each
controller occupies a pci slot as the nvme emulation) works fine:
qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge
-net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash
-drive file=disks/win
Apparently it works fine in Linux though:
qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge
-net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash
-drive file=Downloads/archlinux-2016.04.01-dual.iso,media=cdrom -drive
file=disks/one.img,if=none,format=qcow2,id=on
I also tested WIndows installation ISOs instead as well.
Windows 10 Enterprise 10586:
qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge
-net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash
-drive file=Downloads/10586.0.151029-1700
.TH2_RELEASE_CLIENTENTERPRISE
** Attachment added: "1.png"
https://bugs.launchpad.net/qemu/+bug/1529449/+attachment/4656269/+files/1.png
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1529449
Title:
serial is required for -de
** Attachment added: "0.png"
https://bugs.launchpad.net/qemu/+bug/1529449/+attachment/4656268/+files/0.png
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1529449
Title:
serial is required for -de
Since both "drive=" and "serial=" expects an arbitrary string (while the
value for "drive=" must be unique since it's the "id=" of a "-drive"),
why not use the same string from "drive=" as the value of "serial=" when
it's not specified explicitly?
Apparently "-device scsi-hd" has already been doin
Strangely, seabios supports booting from usb-uas with usb-ehci:
https://drive.google.com/open?id=0B50PCxfm5KU1dUFTUG9HU0pEcXc
and usb-bot with nec-usb-xhci:
https://drive.google.com/open?id=0B50PCxfm5KU1QnVzdTBIdEFzZW8
but not usb-uas with nec-usb-xhci:
https://drive.google.com/open?id=0B50PCx
On 6 May 2016 at 17:00, Tom Yan wrote:
>
> This makes me wonder if it is just a missing feature of a bug.
>
I meant "or" instead of "of".
Sorry, I forgot to mention that I am using qemu 2.5.1 and seabios 1.9.2.
On 6 May 2016 at 17:04, Tom Yan wrote:
> On 6 May 2016 at 17:00, Tom Yan wrote:
>>
>> This makes me wonder if it is just a missing feature of a bug.
>>
>
> I meant "or" instead of "of".
Public bug reported:
When I attach a "-device usb-uas" to a VM with Windows 10 10586, the
device fail to start with the following error in the guest:
"The device cannot start. (Code 10)
{Operation Failed}
The requested operation was unsuccessful"
If the host controller is nec-usb-xhci, there wi
usb-bot works fine
** Attachment added: "xhci-bot.png"
https://bugs.launchpad.net/qemu/+bug/1579306/+attachment/4657732/+files/xhci-bot.png
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1579306
Also tried to "passthrough" the SCSI layer of an actual UASP drive with
scsi-block. No luck either.
** Attachment added: "xhci-block.png"
https://bugs.launchpad.net/qemu/+bug/1579306/+attachment/4657734/+files/xhci-block.png
--
You received this bug notification because you are a member of q
Also tried to "passthrough" the SCSI layer of an actual UASP drive with
scsi-block. No luck either.
** Attachment added: "xhci-block.png"
https://bugs.launchpad.net/qemu/+bug/1579306/+attachment/4657752/+files/xhci-block.png
--
You received this bug notification because you are a member of q
I am using qemu-2.5.1. Here are the commands I used in the test cases:
qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen
-drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive
file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device
usb-uas -device s
Not sure if it's relevant, but when I try completely passthrough a UASP
device to the VM through usb-host, only the BOT/MSC part is exposed.
This is not the case when I do the same thing to a Linux guest (btw usb-
uas apparently works fine in Linux guest as well).
** Attachment added: "xhci-block.
Not sure if it's relevant, but when I try completely passthrough a UASP
device to the VM through usb-host, only the BOT/MSC part is exposed.
This is not the case when I do the same thing to a Linux guest (btw usb-
uas apparently works fine in Linux guest as well).
** Attachment added: "xhci-host.p
That's what I guessed too. Is there any plan to add it or is it out of
consideration?
On Monday, 9 May 2016, Gerd Hoffmann wrote:
> On Fr, 2016-05-06 at 17:00 +0800, Tom Yan wrote:
> > Strangely, seabios supports booting from usb-uas with usb-ehci:
> >
> > https:
I think they are two separate issues in usb-uas and usb-host
respectively. I probably should not have bring in the usb-host case here
but create another report for it.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launc
The problem still exists with qemu 2.7.0 and Windows 10 RS1. Btw I just
did one more test, that I disable the working nvme controller in Device
Manager to see if it makes the non-working one comes alive, but it does
not, even if I reboot the virtual machine.
For the record, the serial number trans
Public bug reported:
The title pretty much told it all. It occurs in Windows 10 RS1 on qemu
2.7.0. Interestingly, I can scroll in the guest if the mouse is not
grabbed. So using usb-tablet sort of works around it, but if I
explicitly grab the mouse with Ctrl+Alt+G, scrolling will also stop
working
Full commands I used:
qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive
file=test.img,format=raw
qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive
file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device
usb-mouse
qemu-system-x86_64 -enable-kvm -cpu
Not sure if it is relevant, but there's a HID button device cannot get
started in Windows 10 RS1.
** Attachment added: "Capture.PNG"
https://bugs.launchpad.net/qemu/+bug/1649233/+attachment/4790624/+files/Capture.PNG
--
You received this bug notification because you are a member of qemu-
dev
-by: Tom Yan
---
hw/pci-bridge/pcie_root_port.c | 10 +-
hw/pci-bridge/xio3130_downstream.c | 9 +
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
index f1cfe9d14a..2bd2d02ccb 100644
--- a/hw/pci
pcie_chassis_find_slot_with_chassis().
The type of the slot field of PCIESlot is uint16_t, which is also what
all of its users pass to it.
Signed-off-by: Tom Yan
---
hw/pci/pcie_port.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c
index
Keep track of the largested allocated slot number when adding slot.
Signed-off-by: Tom Yan
---
hw/pci/pcie_port.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c
index 40fd80c4da..1e2348250c 100644
--- a/hw/pci
On Wed, 9 Dec 2020 at 21:54, Maxim Levitsky wrote:
>
> From: Tom Yan
>
> We can and should get max transfer length and max segments for all host
> devices / cdroms (on Linux).
>
> Also use MIN_NON_ZERO instead when we clamp max transfer length against
> max segments.
&g
This would allow `cache=` to be respected when `if=virtio` is used
(instead of `-device virtio-blk-pci`). Since `cache=writeback` is
the default, this does not cause a change in the default behavior.
Also, when `config-wce` is true, `cache.writeback` is still overriden.
Signed-off-by: Tom Yan
Public bug reported:
When spice is enabled, qemu does not give the graphical window. It
should not imply -nographic but only -display none.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
More precisely, there should be a way to prevent -vga qxl from being
wired to the graphical window.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1908266
Title:
spice unnecessary forces nographic
The gtk window is not limited for -display but also for compatmonitor /
serial /paralel, but when -spice is used, the gtk window does not show
at all. While you can force the window to show with -display gtk, but
the *side effect* is the vga will be wired/connected to the gtk window
(which seems to
Hi philmd (and others),
So I just noticed your commit of requiring the size of an emulated SD
card to be a power of 2, when I was trying to emulate one for an
actual one (well, it's a microSD, but still), as it errored out.
You claim that the kernel will consider it to be a firmware bug and
"corr
Does the spice protocol / any spice client allow access to compatmonitor
/ serial /paralel?
Spice can be (if not often / mainly) used for remote access like VNC,
but that does not necessarily mean users would want to host "fully-
headless".
--
You received this bug notification because you are a
lid user
> cases. As a compromise, allow any card size, but warn only power of 2
> sizes are supported, still suggesting the user how to increase a
> card with 'qemu-img resize'.
>
> Cc: Tom Yan
> Cc: Warner Losh
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
&g
Thu, 5 Nov 2020 at 01:32, Maxim Levitsky wrote:
>
> From: Tom Yan
>
> We can and should get max transfer length and max segments for all host
> devices / cdroms (on Linux).
>
> Also use MIN_NON_ZERO instead when we clamp max transfer length against
> max segments.
>
Public bug reported:
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
** Description changed:
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 i
sg_get_max_transfer_length() and sg_get_max_segments() have nothing
to do with the sg driver or SG_IO at all. They can be and should be
used on all host devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max_sectors against
max_segments.
Signed-off-by: Tom Yan
---
block
Oops I forgot max_transfer needs to be in bytes (and BLKSECTGET in sg
has always been implemented wrongly). Will send a new version.
On Fri, 4 Sep 2020 at 06:37, Tom Yan wrote:
>
> sg_get_max_transfer_length() and sg_get_max_segments() have nothing
> to do with the sg driver or SG_
We can and should get max transfer length and max segments for all host
devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max transfer length against
max segments.
Signed-off-by: Tom Yan
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
sg devices have different major/minor than their corresponding
block devices. Using sysfs to get max segments never really worked
for them.
Fortunately the sg driver provides an ioctl to get sg_tablesize,
which is apparently equivalent to max segments.
Signed-off-by: Tom Yan
---
block/file
We can and should get max transfer length and max segments for all host
devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max transfer length against
max segments.
Signed-off-by: Tom Yan
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
sg devices have different major/minor than their corresponding
block devices. Using sysfs to get max segments never really worked
for them.
Fortunately the sg driver provides an ioctl to get sg_tablesize,
which is apparently equivalent to max segments.
Signed-off-by: Tom Yan
---
block/file
sg devices have different major/minor than their corresponding
block devices. Using sysfs to get max segments never really worked
for them.
Fortunately the sg driver provides an ioctl to get sg_tablesize,
which is apparently equivalent to max segments.
Signed-off-by: Tom Yan
---
block/file
We can and should get max transfer length and max segments for all host
devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max transfer length against
max segments.
Signed-off-by: Tom Yan
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
We can and should get max transfer length and max segments for all host
devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max transfer length against
max segments.
Signed-off-by: Tom Yan
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
sg devices have different major/minor than their corresponding
block devices. Using sysfs to get max segments never really worked
for them.
Fortunately the sg driver provides an ioctl to get sg_tablesize,
which is apparently equivalent to max segments.
Signed-off-by: Tom Yan
---
block/file
t think we want to "mark" `-device scsi-block` as sg either. It
will probably bring even more unexpected problems, because they are
literally different sets of things behind the scene / in the kernel.
On Fri, 4 Sep 2020 at 10:09, Tom Yan wrote:
>
> sg devices have different major/m
Maybe you want to add some condition for this:
https://github.com/qemu/qemu/blob/v5.1.0/nbd/server.c#L659
Or not clamp it at all.
On Sun, 6 Sep 2020 at 18:58, Tom Yan wrote:
>
> In commit 867eccfed84f96b54f4a432c510a02c2ce03b430, Levitsky appears
> to have assumed that the only "SC
ginal issue, if desired.
On Sun, 6 Sep 2020 at 20:53, Maxim Levitsky wrote:
>
> On Sun, 2020-09-06 at 19:04 +0800, Tom Yan wrote:
> > Maybe you want to add some condition for this:
> > https://github.com/qemu/qemu/blob/v5.1.0/nbd/server.c#L659
> > Or not clamp it at all.
&
https://github.com/qemu/qemu/blob/v5.1.0/block/file-posix.c#L3504
On Mon, 7 Sep 2020 at 03:50, Dmitry Fomichev wrote:
>
>
>
> > -Original Message-
> > From: Qemu-block > bounces+dmitry.fomichev=wdc@nongnu.org> On Behalf Of Maxim
> > Levitsky
> >
59 matches
Mail list logo
