[Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static
chroot env. attached (120M tar). I hope you can reproduce with this chroot. Instructions to reproduce - extract, chroot - su - abuild - cd /home/abuild/rpmbuild/BUILD/cmake-2.8.5/armv7l-tizen-linux-gnueabi/ - Bootstrap.cmk/cmake .. -CBootstrap.cmk/InitialCacheFlags.cmake '-GUnix Makefiles' -DCMAKE_BOOTSTRAP=1 ** Attachment added: "Tizen 2.4 chroot" https://bugs.launchpad.net/qemu/+bug/955379/+attachment/4701930/+files/root.tar.gz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/955379 Title: cmake hangs with qemu-arm-static Status in QEMU: Fix Committed Status in Linaro QEMU: Confirmed Status in qemu-linaro package in Ubuntu: Confirmed Bug description: I'm using git commit 3e7ecd976b06f... configured with --target-list =arm-linux-user --static in a chroot environment to compile some things. I ran into this problem with both pcl and opencv-2.3.1. cmake consistently freezes at some point during its execution, though in a different spot each time, usually during a step when it's searching for some libraries. For instance, pcl most commonly stops after: [snip] -- Boost version: 1.46.1 -- Found the following Boost libraries: -- system -- filesystem -- thread -- date_time -- checking for module 'eigen3' -- found eigen3, version 3.0.1 which is perplexing because it freezes after finding what it wants, not during the search. When it does get past that point, it does so almost immediately but freezes somewhere else. I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic with an Intel i5. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions
[Qemu-devel] [Bug 1603636] [NEW] Guest has not initialized the display yet on ubuntu 16.10 PPC
Public bug reported: Hi tested with all kind of configure, with all kind of machine types but i have the same issue ... on lastest quemo 2.6 "Guest has not initialized the display yet" note with lastest git repository the situation become worst because on i386-softmmu i have the message but qemu exit alone because looklike there is not a bios this is gdb of i386-softmmu (gdb) run Starting program: /home/amigaone/src/qemu/i386-softmmu/qemu-system-i386 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". [New Thread 0xf7f78b70 (LWP 25074)] [New Thread 0xf770bb70 (LWP 25075)] [New Thread 0xf6dfdb70 (LWP 25076)] [New Thread 0xf65fdb70 (LWP 25077)] [New Thread 0xf3337b70 (LWP 25078)] [New Thread 0xe4146b70 (LWP 25087)] qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a This usually means one of the following happened: (1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end (3) Your guest kernel has a bug and crashed by jumping off into nowhere This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. Execution cannot continue; stopping here. [Thread 0xe4146b70 (LWP 25087) exited] [Thread 0xf65fdb70 (LWP 25077) exited] [Thread 0xf6dfdb70 (LWP 25076) exited] [Thread 0xf770bb70 (LWP 25075) exited] [Thread 0xf7f78b70 (LWP 25074) exited] [Thread 0xf7f7c000 (LWP 25070) exited] [Inferior 1 (process 25070) exited with code 01] this is my ldd ldd ./qemu-system-i386 linux-vdso32.so.1 => (0x0010) libvirglrenderer.so.0 => /usr/local/lib/libvirglrenderer.so.0 (0x0ff8a000) libepoxy.so.0 => /usr/lib/powerpc-linux-gnu/libepoxy.so.0 (0x0fe86000) libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x0fe55000) libX11.so.6 => /usr/lib/powerpc-linux-gnu/libX11.so.6 (0x0fcf2000) libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0fcb1000) libcurl-gnutls.so.4 => /usr/lib/powerpc-linux-gnu/libcurl-gnutls.so.4 (0x0fc1) libssh2.so.1 => /usr/lib/powerpc-linux-gnu/libssh2.so.1 (0x0fbbf000) libbz2.so.1.0 => /lib/powerpc-linux-gnu/libbz2.so.1.0 (0x0fb7e000) libpixman-1.so.0 => /usr/lib/powerpc-linux-gnu/libpixman-1.so.0 (0x0fadd000) libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0faac000) libnuma.so.1 => /usr/lib/powerpc-linux-gnu/libnuma.so.1 (0x0fa79000) libncurses.so.5 => /lib/powerpc-linux-gnu/libncurses.so.5 (0x0fa28000) libtinfo.so.5 => /lib/powerpc-linux-gnu/libtinfo.so.5 (0x0f9d7000) libuuid.so.1 => /lib/powerpc-linux-gnu/libuuid.so.1 (0x0f9a6000) libpng16.so.16 => /usr/lib/powerpc-linux-gnu/libpng16.so.16 (0x0f945000) libjpeg.so.8 => /usr/lib/powerpc-linux-gnu/libjpeg.so.8 (0x0f8d4000) libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x0f77d000) libnettle.so.6 => /usr/lib/powerpc-linux-gnu/libnettle.so.6 (0x0f71c000) libgnutls.so.30 => /usr/lib/powerpc-linux-gnu/libgnutls.so.30 (0x0f5ca000) libgtk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgtk-x11-2.0.so.0 (0x0f0e6000) libgdk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk-x11-2.0.so.0 (0x0f005000) libcairo.so.2 => /usr/lib/powerpc-linux-gnu/libcairo.so.2 (0x0eec3000) libgdk_pixbuf-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x0ee72000) libgobject-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgobject-2.0.so.0 (0x0edf1000) libglib-2.0.so.0 => /lib/powerpc-linux-gnu/libglib-2.0.so.0 (0x0eca) libsnappy.so.1 => /usr/lib/powerpc-linux-gnu/libsnappy.so.1 (0x0ec6f000) libusb-1.0.so.0 => /lib/powerpc-linux-gnu/libusb-1.0.so.0 (0x0ec2e000) librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ebfd000) libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0eb0c000) libgcc_s.so.1 => /lib/powerpc-linux-gnu/libgcc_s.so.1 (0x0eacb000) libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0ea88000) libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0e8d4000) libdrm.so.2 => /usr/lib/powerpc-linux-gnu/libdrm.so.2 (0x0e8a3000) libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0e872000) libexpat.so.1 => /lib/powerpc-linux-gnu/libexpat.so.1 (0x0e821000) libxcb.so.1 => /usr/lib/powerpc-linux-gnu/libxcb.so.1 (0x0e7e) libidn.so.11 => /lib/powerpc-linux-gnu/libidn.so.11 (0x0e77f000) librtmp.so.1 => /usr/lib/powerpc-linux-
Re: [Qemu-devel] [PATCH V4] block/iscsi: allow caching of the allocation map
On 30/06/2016 13:07, Peter Lieven wrote:
> +static void
> +iscsi_allocmap_update(IscsiLun *iscsilun, int64_t sector_num,
> + int nb_sectors, bool allocated, bool valid)
> {
> int64_t cluster_num, nb_clusters;
> -if (iscsilun->allocationmap == NULL) {
> +
> +if (iscsilun->allocmap == NULL) {
> return;
> }
> cluster_num = DIV_ROUND_UP(sector_num, iscsilun->cluster_sectors);
> nb_clusters = (sector_num + nb_sectors) / iscsilun->cluster_sectors
>- cluster_num;
> -if (nb_clusters > 0) {
> -bitmap_clear(iscsilun->allocationmap, cluster_num, nb_clusters);
> +if (allocated) {
> +bitmap_set(iscsilun->allocmap,
> + sector_num / iscsilun->cluster_sectors,
> + DIV_ROUND_UP(nb_sectors, iscsilun->cluster_sectors));
> +} else if (nb_clusters > 0) {
> +bitmap_clear(iscsilun->allocmap, cluster_num, nb_clusters);
I'm sorry for the delay in review, but this is still wrong.
Suppose cluster_sectors is 2, sector_num = 1, nb_sectors = 6:
0--.--2--.--4--.--6--.--8
|_|
Here in the "mark unallocated" case you want to set 2..6, i.e.
cluster_num=2, nb_clusters=2. This is right.
0--.--2--.--4--.--6--.--8
xxx|___|xxx (x = shrunk)
In the "mark allocated" case, instead, you want to set 0..8, i.e.
cluster_num=0, nb_clusters=4.
0--.--2--.--4--.--6--.--8
<--|_|--> (<--> = expanded)
Instead you are setting nb_clusters=3, so that 6..8 is not marked
allocated and reading 6..7 will return zeroes:
0--.--2--.--4--.--6--.--8
<--|__|!!! (! = wrong)
Instead you need to use
DIV_ROUND_UP(sector_num + nb_sectors, ...)
- sector_num / iscsilun->cluster_sectors
which does the rounding correctly.
In addition, there is some code duplication so put these computations in
two variables.
Thanks!
Paolo
> +}
> +
> +if (iscsilun->allocmap_valid == NULL) {
> +return;
> +}
> +if (valid) {
> +if (nb_clusters > 0) {
> +bitmap_set(iscsilun->allocmap_valid, cluster_num, nb_clusters);
> +}
> +} else {
> +bitmap_clear(iscsilun->allocmap_valid,
> + sector_num / iscsilun->cluster_sectors,
> + DIV_ROUND_UP(nb_sectors, iscsilun->cluster_sectors));
> +}
Re: [Qemu-devel] [PATCH v4 00/12] Reduce lock contention on TCG hot-path
On 15/07/2016 19:58, Sergey Fedorov wrote:
> From: Sergey Fedorov
>
> Hi,
>
> This is a respin of this series [1].
>
> Here I used a modified version of Paolo's patch to docuement memory
> ordering assumptions for certain QHT operations.
>
> The last patch is a suggestion for renaming tb_find_physicall().
>
> This series can be fetch from the public git repository:
>
> https://github.com/sergefdrv/qemu.git lockless-tb-lookup-v4
>
> [1] http://thread.gmane.org/gmane.comp.emulators.qemu/426341
Queued all for 2.7, thanks.
Paolo
> Kind regards,
> Sergey
>
> Summary of changes in v4:
> - Modified version of Paolo's patch is used to document memory ordering
>assumptions for certain QHT operations
> - Intermediate compilation errors fixed
> - Atomic access to TB CPU state
> - tb_find_physical() renamed
> Summary of changes in v3:
> - QHT memory ordering assumptions documented
> - 'tb_jmp_cache' reset in tb_flush() made atomic
> - explicit memory barriers removed around 'tb_jmp_cache' access
> - safe access to 'tb_flushed' out of 'tb_lock' prepared
> - TBs marked with invalid CPU state early on invalidation
> - Alex's tb_find_{fast,slow}() roll-up related patches dropped
> - bouncing of tb_lock between tb_gen_code() and tb_add_jump() avoided
>with local variable 'have_tb_lock'
> - tb_find_{fast,slow}() merged
>
> Alex Bennée (2):
> tcg: set up tb->page_addr before insertion
> tcg: cpu-exec: remove tb_lock from the hot-path
>
> Paolo Bonzini (1):
> util/qht: Document memory ordering assumptions
>
> Sergey Fedorov (9):
> tcg: Pass last_tb by value to tb_find_fast()
> tcg: Prepare safe tb_jmp_cache lookup out of tb_lock
> tcg: Prepare safe access to tb_flushed out of tb_lock
> target-i386: Remove redundant HF_SOFTMMU_MASK
> tcg: Introduce tb_mark_invalid() and tb_is_invalid()
> tcg: Prepare TB invalidation for lockless TB lookup
> tcg: Avoid bouncing tb_lock between tb_gen_code() and tb_add_jump()
> tcg: Merge tb_find_slow() and tb_find_fast()
> tcg: rename tb_find_physical()
>
> cpu-exec.c | 117
> +--
> include/exec/exec-all.h | 16 +++
> include/qemu/qht.h | 5 ++
> target-alpha/cpu.h | 14 ++
> target-arm/cpu.h | 14 ++
> target-cris/cpu.h| 14 ++
> target-i386/cpu.c| 3 --
> target-i386/cpu.h| 20 ++--
> target-i386/translate.c | 12 ++---
> target-lm32/cpu.h| 14 ++
> target-m68k/cpu.h| 14 ++
> target-microblaze/cpu.h | 14 ++
> target-mips/cpu.h| 14 ++
> target-moxie/cpu.h | 14 ++
> target-openrisc/cpu.h| 14 ++
> target-ppc/cpu.h | 14 ++
> target-s390x/cpu.h | 14 ++
> target-sh4/cpu.h | 14 ++
> target-sparc/cpu.h | 14 ++
> target-sparc/translate.c | 1 +
> target-tilegx/cpu.h | 14 ++
> target-tricore/cpu.h | 14 ++
> target-unicore32/cpu.h | 14 ++
> target-xtensa/cpu.h | 14 ++
> translate-all.c | 29 ++--
> util/qht.c | 7 ++-
> 26 files changed, 352 insertions(+), 96 deletions(-)
>
Re: [Qemu-devel] QOM: best way for parents to pass information to children? (was Re: [PATCH RFC 07/16] qom/cpu: make nr-cores, nr-threads real properties)
On Fri, Jul 15, 2016 at 06:33:53PM -0300, Eduardo Habkost wrote:
> On Fri, Jul 15, 2016 at 08:38:35PM +0200, Igor Mammedov wrote:
> > On Fri, 15 Jul 2016 14:43:53 -0300
> > Eduardo Habkost wrote:
> > > On Fri, Jul 15, 2016 at 06:30:41PM +0200, Andreas Färber wrote:
> > > > Am 15.07.2016 um 18:10 schrieb Eduardo Habkost:
> > > > > On Fri, Jul 15, 2016 at 11:11:38AM +0200, Igor Mammedov wrote:
> > > > >> On Fri, 15 Jul 2016 08:35:30 +0200
> > > > >> Andrew Jones wrote:
> > > > >>> On Thu, Jul 14, 2016 at 05:07:43PM -0300, Eduardo Habkost wrote:
> > > >
> > > > First of all, sorry for the horrible delay in replying to this
> > > > thread.
> > > >
> > > > On Wed, Jun 15, 2016 at 10:56:20AM +1000, David Gibson wrote:
> > > > > On Tue, Jun 14, 2016 at 08:19:49AM +0200, Andrew Jones
> > > > > wrote:
> > > > >> On Tue, Jun 14, 2016 at 12:12:16PM +1000, David Gibson
> > > > >> wrote:
> > > > >>> On Sun, Jun 12, 2016 at 03:48:10PM +0200, Andrew Jones
> > > > >>> wrote:
> > > > > [...]
> > > > >> +static Property cpu_common_properties[] = {
> > > > >> +DEFINE_PROP_INT32("nr-cores", CPUState, nr_cores,
> > > > >> 1),
> > > > >> +DEFINE_PROP_INT32("nr-threads", CPUState,
> > > > >> nr_threads, 1),
> > > > >> +DEFINE_PROP_END_OF_LIST()
> > > > >> +};
> > > > >
> > > > > Are you aware of the current CPU hotplug discussion that
> > > > > is going on?
> > > >
> > > > I'm aware of it going on, but haven't been following it.
> > > >
> > > > > I'm not very involved there, but I think some of these
> > > > > reworks also move "nr_threads" into the CPU state
> > > > > already, e.g. see:
> > > >
> > > > nr_threads (and nr_cores) are already state in CPUState.
> > > > This patch just exposes that state via properties.
> > > >
> > > > >
> > > > > https://github.com/dgibson/qemu/commit/9d07719784ecbeebea71
> > > > >
> > > > > ... so you might want to check these patches first to see
> > > > > whether you can base your rework on them?
> > > >
> > > > Every cpu, and thus every machine, uses CPUState for its
> > > > cpus. I'm not sure every machine will want to use that new
> > > > abstract core class though. If they did, then we could
> > > > indeed use nr_threads from there instead (and remove it
> > > > from CPUState), but we'd still need nr_cores from the
> > > > abstract cpu package class (CPUState).
> > > > >>>
> > > > >>> Hmm. Since the CPUState object represents just a single
> > > > >>> thread, it seems weird to me that it would have nr_threads
> > > > >>> and nr_cores information.
> > > >
> > > > Agreed it is weird, and I think we should try to move it away
> > > > from CPUState, not make it part of the TYPE_CPU interface.
> > > > nr_threads belongs to the actual container of the Thread
> > > > objects, and nr_cores in the actual container of the Core
> > > > objects.
> > > >
> > > > The problem is how to implement that in a non-intrusive way
> > > > that would require changing the object hierarchy of all
> > > > architectures.
> > > >
> > > >
> > > > >>>
> > > > >>> Exposing those as properties makes that much worse, because
> > > > >>> it's now ABI, rather than internal detail we can clean up
> > > > >>> at some future time.
> > > > >>
> > > > >> CPUState is supposed to be "State of one CPU core or
> > > > >> thread", which justifies having nr_threads state, as it may
> > > > >> be describing a core.
> > > > >
> > > > > Um.. does it ever actually represent a (multithread) core in
> > > > > practice? It would need to have duplicated register state for
> > > > > every thread were that the case.
> > > >
> > > > AFAIK, CPUState is still always thread state. Or has this
> > > > changed in some architectures, already?
> > > >
> > > > >
> > > > >> I guess there's no justification for having nr_cores in
> > > > >> there though. I agree adding the Core class is a good idea,
> > > > >> assuming it will get used by all machines, and CPUState then
> > > > >> gets changed to a Thread class. The question then, though,
> > > > >> is do we also create a Socket class that contains nr_cores?
> > > > >
> > > > > That was roughly our intention with the way the cross
> > > > > platform hotplug stuff is evolving. But the intention was
> > > > > that the Socket objects would only need to be constructed for
> > > > > machine types where it makes sense. So for example on the
> > > > > paravirt pseries platform, we'll only have Core objects,
> > > > > because the socket distinction is
[Qemu-devel] [Bug 1603693] Re: Disks in mptsas1068 scsi controller not seen by linux
** Attachment added: "The test script from the bug description"
https://bugs.launchpad.net/qemu/+bug/1603693/+attachment/4702121/+files/test-mptsas1068.sh
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1603693
Title:
Disks in mptsas1068 scsi controller not seen by linux
Status in QEMU:
New
Bug description:
When using the mptsas1068 scsi controller, linux detects the
controller itself but not the drives attached to it. Freebsd works.
Using a different controller with linux works. VMware with linux
works.
qemu 2.6.50 (v2.6.0-1925-g6b92bbf)
seabios rel-1.9.0-139-gae3f78f (master branch, required for mptsas1068
support)
Test script, loosely based off what libvirt runs and the libvirt tests
that Paolo Bonzini wrote [1]
#
iso=archlinux-2016.07.01-dual.iso
#iso=FreeBSD-10.3-RELEASE-amd64-bootonly.iso
device=mptsas1068
#device=lsi
img=empty.img
qemu-img create -f qcow2 $img 1G
/usr/bin/qemu-system-x86_64 \
-enable-kvm \
-m 1024 \
-boot menu=on \
-device $device,id=scsi0,bus=pci.0,addr=0x9 \
-drive file=$img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
\
-drive file=$iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1
#
The ISOs can be downloaded from [2] and [3].
After booting linux, do "lsblk". /dev/sda should exist.
After booting freebsd, do "geom disk list". A da0 / "QEMU QEMU
HARDDISK" should be mentioned.
With device=mptsas1068 this fails in linux.
With device=lsi line it works in both.
With VMWare and a linux VM (opensuse 10.1, kernel 2.6.18) which only
loads modules for mptsas1068, this works.
I also reproduced this with the debian 8.5 netinstall image, but it
insists in making you pick a driver from a list of modules when it
fails to mount it, instead of dropping to a shell.
Arch linux dmesg output snippet (full output attached as arch-linux-
dmesg.txt):
#
root@archiso ~ # dmesg | grep -i -e mpt -e scsi -e ioc0
[0.00] Linux version 4.6.3-1-ARCH (builduser@tobias) (gcc version
6.1.1 20160602 (GCC) ) #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016
[0.00] Normal empty
[0.00] Preemptible hierarchical RCU implementation.
[1.879616] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 249)
[1.951581] SCSI subsystem initialized
[1.957113] Fusion MPT base driver 3.04.20
[1.957618] Fusion MPT SAS Host driver 3.04.20
[2.281773] scsi host0: ata_piix
[2.285372] scsi host1: ata_piix
[2.305803] mptbase: ioc0: Initiating bringup
[2.363555] ioc0: LSISAS1068 A0: Capabilities={Initiator}
[2.444390] scsi 0:0:1:0: CD-ROMQEMU QEMU DVD-ROM 2.5+
PQ: 0 ANSI: 5
[2.500572] scsi host2: ioc0: LSISAS1068 A0, FwRev=01329200h, Ports=8,
MaxQ=128, IRQ=11
[2.507024] sr 0:0:1:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[2.507274] sr 0:0:1:0: Attached scsi CD-ROM sr0
#
The controller itself is detected, the disk isn't.
An early version of this patch [4] said that it was only tested with
FreeBSD:
>Tested with FreeBSD for now. The previous version (before the
>configuration page rewrite) worked with RHEL and Windows guests as well.
>
>TODO: write qtest for (at least) config pages, test Linux and Windows.
[1]:
https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=fc922eb2080a3fa7b24bc8a8b0aabfd394480143
[2]: https://www.archlinux.org/download
[3]: https://www.freebsd.org/where.html
[4]: https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06475.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1603693/+subscriptions
[Qemu-devel] [Bug 1603693] [NEW] Disks in mptsas1068 scsi controller not seen by linux
Public bug reported:
When using the mptsas1068 scsi controller, linux detects the controller
itself but not the drives attached to it. Freebsd works. Using a
different controller with linux works. VMware with linux works.
qemu 2.6.50 (v2.6.0-1925-g6b92bbf)
seabios rel-1.9.0-139-gae3f78f (master branch, required for mptsas1068 support)
Test script, loosely based off what libvirt runs and the libvirt tests
that Paolo Bonzini wrote [1]
#
iso=archlinux-2016.07.01-dual.iso
#iso=FreeBSD-10.3-RELEASE-amd64-bootonly.iso
device=mptsas1068
#device=lsi
img=empty.img
qemu-img create -f qcow2 $img 1G
/usr/bin/qemu-system-x86_64 \
-enable-kvm \
-m 1024 \
-boot menu=on \
-device $device,id=scsi0,bus=pci.0,addr=0x9 \
-drive file=$img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
\
-drive file=$iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1
#
The ISOs can be downloaded from [2] and [3].
After booting linux, do "lsblk". /dev/sda should exist.
After booting freebsd, do "geom disk list". A da0 / "QEMU QEMU HARDDISK"
should be mentioned.
With device=mptsas1068 this fails in linux.
With device=lsi line it works in both.
With VMWare and a linux VM (opensuse 10.1, kernel 2.6.18) which only
loads modules for mptsas1068, this works.
I also reproduced this with the debian 8.5 netinstall image, but it
insists in making you pick a driver from a list of modules when it fails
to mount it, instead of dropping to a shell.
Arch linux dmesg output snippet (full output attached as arch-linux-
dmesg.txt):
#
root@archiso ~ # dmesg | grep -i -e mpt -e scsi -e ioc0
[0.00] Linux version 4.6.3-1-ARCH (builduser@tobias) (gcc version 6.1.1
20160602 (GCC) ) #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016
[0.00] Normal empty
[0.00] Preemptible hierarchical RCU implementation.
[1.879616] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
249)
[1.951581] SCSI subsystem initialized
[1.957113] Fusion MPT base driver 3.04.20
[1.957618] Fusion MPT SAS Host driver 3.04.20
[2.281773] scsi host0: ata_piix
[2.285372] scsi host1: ata_piix
[2.305803] mptbase: ioc0: Initiating bringup
[2.363555] ioc0: LSISAS1068 A0: Capabilities={Initiator}
[2.444390] scsi 0:0:1:0: CD-ROMQEMU QEMU DVD-ROM 2.5+
PQ: 0 ANSI: 5
[2.500572] scsi host2: ioc0: LSISAS1068 A0, FwRev=01329200h, Ports=8,
MaxQ=128, IRQ=11
[2.507024] sr 0:0:1:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[2.507274] sr 0:0:1:0: Attached scsi CD-ROM sr0
#
The controller itself is detected, the disk isn't.
An early version of this patch [4] said that it was only tested with
FreeBSD:
>Tested with FreeBSD for now. The previous version (before the
>configuration page rewrite) worked with RHEL and Windows guests as well.
>
>TODO: write qtest for (at least) config pages, test Linux and Windows.
[1]:
https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=fc922eb2080a3fa7b24bc8a8b0aabfd394480143
[2]: https://www.archlinux.org/download
[3]: https://www.freebsd.org/where.html
[4]: https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06475.html
** Affects: qemu
Importance: Undecided
Status: New
** Attachment added: "Full dmesg output inside arch linux iso"
https://bugs.launchpad.net/bugs/1603693/+attachment/4702120/+files/arch-linux-dmesg.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1603693
Title:
Disks in mptsas1068 scsi controller not seen by linux
Status in QEMU:
New
Bug description:
When using the mptsas1068 scsi controller, linux detects the
controller itself but not the drives attached to it. Freebsd works.
Using a different controller with linux works. VMware with linux
works.
qemu 2.6.50 (v2.6.0-1925-g6b92bbf)
seabios rel-1.9.0-139-gae3f78f (master branch, required for mptsas1068
support)
Test script, loosely based off what libvirt runs and the libvirt tests
that Paolo Bonzini wrote [1]
#
iso=archlinux-2016.07.01-dual.iso
#iso=FreeBSD-10.3-RELEASE-amd64-bootonly.iso
device=mptsas1068
#device=lsi
img=empty.img
qemu-img create -f qcow2 $img 1G
/usr/bin/qemu-system-x86_64 \
-enable-kvm \
-m 1024 \
-boot menu=on \
-device $device,id=scsi0,bus=pci.0,addr=0x9 \
-drive file=$img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
\
-drive file=$iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1
#
The ISOs can be dow
[Qemu-devel] OUT_ASM on two different systems
Hi all ! I ran a program with qemu in user mode emulation and generated trace for generated host instructions using (-d OUT_ASM) on two different linux systems.I expected that the addresses in two trace files can be different. But the total number of lines in two files is different as well. I mean the generated host instructions in two files are different (I have not yet looked into details of those differenes). Qemu and program's binary are exactly same on both systems. I wonder if someone can help me in explaining this ? Thanks for your time !
[Qemu-devel] [PATCH 1/1] Reorganize help output of '-display' option
The '-display' help information is not very correct. This patch sort
it a little.
Also, in its help information, reveals what implicit display option
will be chosen if no definition.
P.S.
Hi Markus,
Sorry for late of sending out this patch. Really busy recently, and it
also took me some time to understand the framework help message generation.
Signed-off-by: Robert Ho
---
qemu-options.hx | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 17f15ad..69cf668 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -930,10 +930,26 @@ ETEXI
DEF("display", HAS_ARG, QEMU_OPTION_display,
"-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]\n"
-"[,window_close=on|off]|curses|none|\n"
-"gtk[,grab_on_hover=on|off]|\n"
-"vnc=[,]\n"
-"select display type\n", QEMU_ARCH_ALL)
+"[,window_close=on|off][,gl=on|off]|curses|none|\n"
+"-display gtk[,grab_on_hover=on|off][,gl=on|off]|\n"
+"-display vnc=[,]\n"
+"-display curses\n"
+"-display none"
+"select display type\n"
+"If no -display option or its sugars (sd, curses, vnc, etc) defined,"
+" qemu will implicitly use\n"
+#if defined(CONFIG_GTK)
+"\t\"-dispaly gtk\"\n"
+#elif defined(CONFIG_SDL)
+"\t\"-display sdl\"\n"
+#elif defined(CONFIG_COCOA)
+"\t\"-display cocoa\"\n"
+#elif defined(CONFIG_VNC)
+"\t\"-vnc localhost:0,to=99,id=default\"\n"
+#else
+"\t\"-display none\"\n"
+#endif
+, QEMU_ARCH_ALL)
STEXI
@item -display @var{type}
@findex -display
@@ -980,7 +996,8 @@ the console and monitor.
ETEXI
DEF("curses", 0, QEMU_OPTION_curses,
-"-curses use a curses/ncurses interface instead of SDL\n",
+"-curses use a curses/ncurses interface instead of SDL; "
+"is sugar for -display curses\n",
QEMU_ARCH_ALL)
STEXI
@item -curses
@@ -1030,7 +1047,7 @@ Disable SDL window close capability.
ETEXI
DEF("sdl", 0, QEMU_OPTION_sdl,
-"-sdlenable SDL\n", QEMU_ARCH_ALL)
+"-sdlenable SDL; is sugar for -display sdl\n", QEMU_ARCH_ALL)
STEXI
@item -sdl
@findex -sdl
@@ -1227,7 +1244,8 @@ Set the initial graphical resolution and depth (PPC,
SPARC only).
ETEXI
DEF("vnc", HAS_ARG, QEMU_OPTION_vnc ,
-"-vnc displaystart a VNC server on display\n", QEMU_ARCH_ALL)
+"-vnc displaystart a VNC server on display; is sugar for"
+" -display vnc=display\n", QEMU_ARCH_ALL)
STEXI
@item -vnc @var{display}[,@var{option}[,@var{option}[,...]]]
@findex -vnc
--
1.8.3.1
