Re: [Qemu-devel] [RFC PATCH v4 2/5] ramlist mutex
On 08/17/2011 02:28 AM, Paolo Bonzini wrote:
On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
@@ -3001,8 +3016,10 @@ void qemu_ram_free_from_ptr(ram_addr_t addr)
QLIST_FOREACH(block,&ram_list.blocks, next) {
if (addr == block->offset) {
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_REMOVE(block, next_mru);
+qemu_mutex_unlock_ramlist();
qemu_free(block);
return;
}
@@ -3015,8 +3032,10 @@ void qemu_ram_free(ram_addr_t addr)
QLIST_FOREACH(block,&ram_list.blocks, next) {
if (addr == block->offset) {
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_REMOVE(block, next_mru);
+qemu_mutex_unlock_ramlist();
if (block->flags& RAM_PREALLOC_MASK) {
;
} else if (mem_path) {
You must protect the whole QLIST_FOREACH. Otherwise looks good.
Or, is it okay to convert all the ramblock list traversals in exec.c
(under iothread) to mru traversals, and probably it makes sense as the
original list was also maintained in the mru order, whereas the sequence
of blocks doesn't matter for the migration code. This way we don't have
to acquire the mutex for block list traversals.
- Umesh
Re: [Qemu-devel] [PATCH] pci: add standard bridge device
At 08/18/2011 11:15 PM, Avi Kivity Write:
> On 08/17/2011 08:22 PM, Wen Congyang wrote:
>> At 08/17/2011 04:37 PM, Wen Congyang Write:
>> > At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
>> >> This adds support for a standard pci to pci bridge,
>> >> enabling support for more than 32 PCI devices in the system.
>> >> To use, specify the device id as a 'bus' option.
>> >> Example:
>> >> -device pci-bridge,id=bridge1 \
>> >> -netdev user,id=u \
>> >> -device ne2k_pci,id=net2,bus=bridge1,netdev=u
>> >>
>> >> TODO: device hotplug support.
>> >
>> > I try this patch, and found that when I use pci bridge, qemu will
>> core dump.
>> >
>> > Here is my command line:
>> > /usr/local2/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm -m 512
>> -name vm1 -drive
>> file=/var/lib/libvirt/images/vm1.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writethrough
>> -device
>> ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -vnc
>> 0.0.0.0:1 -device pci-bridge,id=bridge1,bus=pci.0,addr=0x08.0x0
>> -netdev user,id=u -device ne2k_pci,id=net2,bus=bridge1,netdev=u
>> >
>> > Here is the backtrace:
>> > Core was generated by `/usr/local2/bin/qemu-system-x86_64 -M
>> pc-0.14 -enable-kvm -m 512 -name vm1 -dri'.
>> > Program terminated with signal 11, Segmentation fault.
>> > #0 0x00438e34 in memory_region_add_subregion_common
>> (mr=0x0, offset=49152, subregion=0x1de5d58) at
>> /home/wency/source/qemu/memory.c:1152
>> > 1152QTAILQ_FOREACH(other,&mr->subregions, subregions_link) {
>> > Missing separate debuginfos, use: debuginfo-install
>> SDL-1.2.14-2.el6.x86_64 celt051-0.5.1.3-0.el6.x86_64
>> cyrus-sasl-gssapi-2.1.23-8.el6.x86_64
>> cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-md5-2.1.23-8.el6.x86_64
>> cyrus-sasl-plain-2.1.23-8.el6.x86_64 db4-4.7.25-16.el6.x86_64
>> glib2-2.22.5-6.el6.x86_64 glibc-2.12-1.25.el6.x86_64
>> keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6.x86_64
>> libX11-1.3-2.el6.x86_64 libXau-1.0.5-1.el6.x86_64
>> libaio-0.3.107-10.el6.x86_64 libattr-2.4.44-4.el6.x86_64
>> libcom_err-1.41.12-7.el6.x86_64 libcurl-7.19.7-26.el6.x86_64
>> libgcrypt-1.4.5-5.el6.x86_64 libgpg-error-1.7-3.el6.x86_64
>> libidn-1.18-2.el6.x86_64 libjpeg-6b-46.el6.x86_64
>> libpng-1.2.44-1.el6.x86_64 libselinux-2.0.94-5.el6.x86_64
>> libssh2-1.2.2-7.el6.x86_64 libtasn1-2.3-3.el6.x86_64
>> libuuid-2.17.2-12.el6.x86_64 libxcb-1.5-1.el6.x86_64
>> ncurses-libs-5.7-3.20090208.el6.x86_64 nspr-4.8.7-1.el6.x86_64
>> nss-3.12.9-9.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64
>> nss-util-3.12.9-1.el6.x86_64 openld
>>
>> ap
>> > -2.4.23-15.el6.x86_64 openssl-1.0.0-10.el6.x86_64
>> pixman-0.18.4-1.el6_0.1.x86_64 spice-server-0.8.0-1.el6.x86_64
>> zlib-1.2.3-25.el6.x86_64
>> > (gdb) bt
>> > #0 0x00438e34 in memory_region_add_subregion_common
>> (mr=0x0, offset=49152, subregion=0x1de5d58) at
>> /home/wency/source/qemu/memory.c:1152
>> > #1 0x00439090 in memory_region_add_subregion_overlap
>> (mr=0x0, offset=49152, subregion=0x1de5d58, priority=1) at
>> /home/wency/source/qemu/memory.c:1194
>> > #2 0x005c55fe in pci_update_mappings (d=0x1de5900) at
>> /home/wency/source/qemu/hw/pci.c:1063
>> > #3 0x005c5982 in pci_default_write_config (d=0x1de5900,
>> addr=4, val=0, l=2) at /home/wency/source/qemu/hw/pci.c:1121
>> > #4 0x005cbfbf in pci_host_config_write_common
>> (pci_dev=0x1de5900, addr=4, limit=256, val=1, len=2) at
>> /home/wency/source/qemu/hw/pci_host.c:54
>> > #5 0x005cc0d1 in pci_data_write (s=0x1da2b90,
>> addr=2147549188, val=1, len=2) at
>> /home/wency/source/qemu/hw/pci_host.c:75
>> > #6 0x005cc2b1 in pci_host_data_write (handler=0x1da2b60,
>> addr=3324, val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:125
>> > #7 0x0042c884 in ioport_simple_writew (opaque=0x1da2b60,
>> addr=3324, value=1) at /home/wency/source/qemu/rwhandler.c:50
>> > #8 0x00499e85 in ioport_write (index=1, address=3324,
>> data=1) at ioport.c:81
>> > #9 0x0049a8e1 in cpu_outw (addr=3324, val=1) at ioport.c:280
>> > #10 0x00433c5d in kvm_handle_io (port=3324,
>> data=0x7f0b30f86000, direction=1, size=2, count=1) at
>> /home/wency/source/qemu/kvm-all.c:837
>> > #11 0x004341c8 in kvm_cpu_exec (env=0x1b7fc70) at
>> /home/wency/source/qemu/kvm-all.c:976
>> > #12 0x0040da99 in cpu_exec_all () at
>> /home/wency/source/qemu/cpus.c:1102
>> > #13 0x005b60c4 in main_loop () at
>> /home/wency/source/qemu/vl.c:1392
>> > #14 0x005baa49 in main (argc=20, argv=0x7a6b5a38,
>> envp=0x7a6b5ae0) at /home/wency/source/qemu/vl.c:3356
>> >
>> > If I do not attach any device on bus bridge1, qemu can work nice.
>> >
>> > Thanks
>> > Wen Congyang
>> >
>>
>> The following patch can fix this problem, but I'm not sure whether it
>> is right.
>
> It's correct but insufficient, the filtering code (pci_bridge_filter)
> needs to be updated to use the memory API.
I rea
Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On 18 August 2011 18:48, Avi Kivity wrote:
> +static GMemVTable gmemvtable = {
> + .malloc = qemu_malloc,
> + .realloc = qemu_realloc,
> + .free = qemu_free,
> +};
> +
> +/**
> + * qemu_malloc_init: initialize memory management
> + */
> +void qemu_malloc_init(void)
> +{
> + g_mem_set_vtable(&gmemvtable);
> +}
Does this mean you can now safely allocate with g_malloc
and free with qemu_free, or is mixing the two APIs like that
still a no-no ?
(I'm thinking about a situation where you might use a glib utility
function that returned g_malloc'd memory and want to pass that back
to your caller without having to either copy to qemu_malloc'd memory
or require your caller to care about the distinction.)
-- PMM
Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On Thu, Aug 18, 2011 at 6:48 PM, Avi Kivity wrote: > This makes the tracing infrastructure available to users of g_new(). > > Signed-off-by: Avi Kivity > --- > qemu-common.h | 1 + > qemu-malloc.c | 15 +++ > vl.c | 1 + > 3 files changed, 17 insertions(+), 0 deletions(-) Seems useful :) Stefan
Re: [Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files
On Wed, Aug 17, 2011 at 8:05 PM, Steve Si <826...@bugs.launchpad.net> wrote: > I downloaded source and ran configure under MinGW but got > Python not found. Use --python=/path/to/python > How to fix pls? $ ./configure --disable-guest-agent $ make Stefan
Re: [Qemu-devel] Multi-threaded user program support?
On 19 August 2011 03:59, 陳韋任 wrote: >> More generally and not x86-specific, there are problems with >> the multithreaded user-mode support which I suspect exist because >> nobody has ever sat down and worked out a coherent design for it, >> including what might need to be thread-local and what locking >> is required. So the result is that it mostly works but if you > > You mean some QEMU data structures need to be thread-local or lock > protected in order to emulate guest multi-threaded program correctly? Approximately, yes (the third option being "redesign the data structure so it can be sensibly protected"). See https://bugs.launchpad.net/qemu/+bug/668799 for discussion of one example. None of this is impossibly difficult; it just requires that somebody sits down and actually works through the problems and fixes them. -- PMM
Re: [Qemu-devel] Multi-threaded user program support?
> More generally and not x86-specific, there are problems with > the multithreaded user-mode support which I suspect exist because > nobody has ever sat down and worked out a coherent design for it, > including what might need to be thread-local and what locking > is required. So the result is that it mostly works but if you You mean some QEMU data structures need to be thread-local or lock protected in order to emulate guest multi-threaded program correctly? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH] Fix gcc-4.6 compiler error
On Thu, Aug 18, 2011 at 12:28 PM, Peter Maydell wrote: > On 18 August 2011 05:16, Zhi Yong Wu wrote: >> I have also met this problem on fedora 15 today. Currently i disable >> werror option to build successfully. How to completely this problem >> regardless of gcc>=4.6? > > Hmm, this should have been fixed by commit 257a73755. Can you > tell us which git revision you are trying to build and quote > the complete error message from gcc, please? Sorry, my branch is a bit old. After rebasing it to latest version, the fix has checked in and this issue has been resolved. thanks. > > thanks > -- PMM > -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH, braille] Add dots keypresses support to the baum braille device
Oops, sorry, the previous patch had a debugging leftover, here it is
again.
Add dots keypresses support to the baum braille device.
Signed-off-by: Samuel Thibault
diff --git a/hw/baum.c b/hw/baum.c
index 21326ae..0b29498 100644
--- a/hw/baum.c
+++ b/hw/baum.c
@@ -1,7 +1,7 @@
/*
* QEMU Baum Braille Device
*
- * Copyright (c) 2008, 2011 Samuel Thibault
+ * Copyright (c) 2008, 2010-2011 Samuel Thibault
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
deal
@@ -101,8 +101,11 @@ typedef struct {
} BaumDriverState;
/* Let's assume NABCC by default */
-static const uint8_t nabcc_translation[256] = {
-[0] = ' ',
+enum way {
+DOTS2ASCII,
+ASCII2DOTS
+};
+static const uint8_t nabcc_translation[2][256] = {
#ifndef BRLAPI_DOTS
#define BRLAPI_DOTS(d1,d2,d3,d4,d5,d6,d7,d8) \
((d1?BRLAPI_DOT1:0)|\
@@ -114,105 +117,109 @@ static const uint8_t nabcc_translation[256] = {
(d7?BRLAPI_DOT7:0)|\
(d8?BRLAPI_DOT8:0))
#endif
-[BRLAPI_DOTS(1,0,0,0,0,0,0,0)] = 'a',
-[BRLAPI_DOTS(1,1,0,0,0,0,0,0)] = 'b',
-[BRLAPI_DOTS(1,0,0,1,0,0,0,0)] = 'c',
-[BRLAPI_DOTS(1,0,0,1,1,0,0,0)] = 'd',
-[BRLAPI_DOTS(1,0,0,0,1,0,0,0)] = 'e',
-[BRLAPI_DOTS(1,1,0,1,0,0,0,0)] = 'f',
-[BRLAPI_DOTS(1,1,0,1,1,0,0,0)] = 'g',
-[BRLAPI_DOTS(1,1,0,0,1,0,0,0)] = 'h',
-[BRLAPI_DOTS(0,1,0,1,0,0,0,0)] = 'i',
-[BRLAPI_DOTS(0,1,0,1,1,0,0,0)] = 'j',
-[BRLAPI_DOTS(1,0,1,0,0,0,0,0)] = 'k',
-[BRLAPI_DOTS(1,1,1,0,0,0,0,0)] = 'l',
-[BRLAPI_DOTS(1,0,1,1,0,0,0,0)] = 'm',
-[BRLAPI_DOTS(1,0,1,1,1,0,0,0)] = 'n',
-[BRLAPI_DOTS(1,0,1,0,1,0,0,0)] = 'o',
-[BRLAPI_DOTS(1,1,1,1,0,0,0,0)] = 'p',
-[BRLAPI_DOTS(1,1,1,1,1,0,0,0)] = 'q',
-[BRLAPI_DOTS(1,1,1,0,1,0,0,0)] = 'r',
-[BRLAPI_DOTS(0,1,1,1,0,0,0,0)] = 's',
-[BRLAPI_DOTS(0,1,1,1,1,0,0,0)] = 't',
-[BRLAPI_DOTS(1,0,1,0,0,1,0,0)] = 'u',
-[BRLAPI_DOTS(1,1,1,0,0,1,0,0)] = 'v',
-[BRLAPI_DOTS(0,1,0,1,1,1,0,0)] = 'w',
-[BRLAPI_DOTS(1,0,1,1,0,1,0,0)] = 'x',
-[BRLAPI_DOTS(1,0,1,1,1,1,0,0)] = 'y',
-[BRLAPI_DOTS(1,0,1,0,1,1,0,0)] = 'z',
-
-[BRLAPI_DOTS(1,0,0,0,0,0,1,0)] = 'A',
-[BRLAPI_DOTS(1,1,0,0,0,0,1,0)] = 'B',
-[BRLAPI_DOTS(1,0,0,1,0,0,1,0)] = 'C',
-[BRLAPI_DOTS(1,0,0,1,1,0,1,0)] = 'D',
-[BRLAPI_DOTS(1,0,0,0,1,0,1,0)] = 'E',
-[BRLAPI_DOTS(1,1,0,1,0,0,1,0)] = 'F',
-[BRLAPI_DOTS(1,1,0,1,1,0,1,0)] = 'G',
-[BRLAPI_DOTS(1,1,0,0,1,0,1,0)] = 'H',
-[BRLAPI_DOTS(0,1,0,1,0,0,1,0)] = 'I',
-[BRLAPI_DOTS(0,1,0,1,1,0,1,0)] = 'J',
-[BRLAPI_DOTS(1,0,1,0,0,0,1,0)] = 'K',
-[BRLAPI_DOTS(1,1,1,0,0,0,1,0)] = 'L',
-[BRLAPI_DOTS(1,0,1,1,0,0,1,0)] = 'M',
-[BRLAPI_DOTS(1,0,1,1,1,0,1,0)] = 'N',
-[BRLAPI_DOTS(1,0,1,0,1,0,1,0)] = 'O',
-[BRLAPI_DOTS(1,1,1,1,0,0,1,0)] = 'P',
-[BRLAPI_DOTS(1,1,1,1,1,0,1,0)] = 'Q',
-[BRLAPI_DOTS(1,1,1,0,1,0,1,0)] = 'R',
-[BRLAPI_DOTS(0,1,1,1,0,0,1,0)] = 'S',
-[BRLAPI_DOTS(0,1,1,1,1,0,1,0)] = 'T',
-[BRLAPI_DOTS(1,0,1,0,0,1,1,0)] = 'U',
-[BRLAPI_DOTS(1,1,1,0,0,1,1,0)] = 'V',
-[BRLAPI_DOTS(0,1,0,1,1,1,1,0)] = 'W',
-[BRLAPI_DOTS(1,0,1,1,0,1,1,0)] = 'X',
-[BRLAPI_DOTS(1,0,1,1,1,1,1,0)] = 'Y',
-[BRLAPI_DOTS(1,0,1,0,1,1,1,0)] = 'Z',
-
-[BRLAPI_DOTS(0,0,1,0,1,1,0,0)] = '0',
-[BRLAPI_DOTS(0,1,0,0,0,0,0,0)] = '1',
-[BRLAPI_DOTS(0,1,1,0,0,0,0,0)] = '2',
-[BRLAPI_DOTS(0,1,0,0,1,0,0,0)] = '3',
-[BRLAPI_DOTS(0,1,0,0,1,1,0,0)] = '4',
-[BRLAPI_DOTS(0,1,0,0,0,1,0,0)] = '5',
-[BRLAPI_DOTS(0,1,1,0,1,0,0,0)] = '6',
-[BRLAPI_DOTS(0,1,1,0,1,1,0,0)] = '7',
-[BRLAPI_DOTS(0,1,1,0,0,1,0,0)] = '8',
-[BRLAPI_DOTS(0,0,1,0,1,0,0,0)] = '9',
-
-[BRLAPI_DOTS(0,0,0,1,0,1,0,0)] = '.',
-[BRLAPI_DOTS(0,0,1,1,0,1,0,0)] = '+',
-[BRLAPI_DOTS(0,0,1,0,0,1,0,0)] = '-',
-[BRLAPI_DOTS(1,0,0,0,0,1,0,0)] = '*',
-[BRLAPI_DOTS(0,0,1,1,0,0,0,0)] = '/',
-[BRLAPI_DOTS(1,1,1,0,1,1,0,0)] = '(',
-[BRLAPI_DOTS(0,1,1,1,1,1,0,0)] = ')',
-
-[BRLAPI_DOTS(1,1,1,1,0,1,0,0)] = '&',
-[BRLAPI_DOTS(0,0,1,1,1,1,0,0)] = '#',
-
-[BRLAPI_DOTS(0,0,0,0,0,1,0,0)] = ',',
-[BRLAPI_DOTS(0,0,0,0,1,1,0,0)] = ';',
-[BRLAPI_DOTS(1,0,0,0,1,1,0,0)] = ':',
-[BRLAPI_DOTS(0,1,1,1,0,1,0,0)] = '!',
-[BRLAPI_DOTS(1,0,0,1,1,1,0,0)] = '?',
-[BRLAPI_DOTS(0,0,0,0,1,0,0,0)] = '"',
-[BRLAPI_DOTS(0,0,1,0,0,0,0,0)] ='\'',
-[BRLAPI_DOTS(0,0,0,1,0,0,0,0)] = '`',
-[BRLAPI_DOTS(0,0,0,1,1,0,1,0)] = '^',
-[BRLAPI_DOTS(0,0,0,1,1,0,0,0)] = '~',
-[BRLAPI_DOTS(0,1,0,1,0,1,1,0)] = '[',
-[BRLAPI_DOTS(1,1,0,1,1,1,1,0)] = ']',
-[BRLAPI_DOTS(0,1,0,1,0,1,0,0)] = '{',
-[BRLAPI_DOTS(1,1,0,1,1,1,0,0)] = '}',
-[BRLAPI_DOTS(1,1,1,1,1,1,0,0)] = '=',
-[BRLAPI_DOTS(1,1,0,0,0,1,0,0)] = '<',
-[BRLAPI_DOTS(0,0,1,1,1,0,0,0)] = '>',
-[BRLAPI_DOTS(1,1,0,1,0,1,0,0)] = '$',
-[BRLAPI_DOTS(1,0,0,1,0,1,0,0)] = '%',
-[BRLAPI_DOTS(0,0,0,1,0,0,1,0)] = '@',
-
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi, El 18/08/2011, a las 21:51, Laurent Vivier escribió: > Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : >> Hi Laurent, >> >> El 18/08/2011, a las 20:57, Laurent Vivier escribió: >> >>> Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, >>> >>> Hi Natalia, >>> El 18/08/2011, a las 15:02, Laurent Vivier escribió: > > > > Le 18 août 2011 à 13:12, "François Revol" a écrit : > >> Le -10/01/-28163 20:59, Laurent Vivier a écrit : >>> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a > écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: > These patches greatly expand Motorola 68k emulation within > qemu, and are what I used as a basis for my > Google Summer of Code project to add NeXT hardware support to > QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be > reasonably reviewed and applied. >>> >>> And I'm not sure this series of patches is ready for inclusion > in qemu >>> mainline as it should break existing m68k emulation... >>> >>> Bryce, you should only post your patches, refering to the > repository on >>> which they apply, i.e. > git://gitorious.org/qemu-m68k/qemu-m68k.git , >>> master branch. >>> >> >> Btw, are you planning on merging it back someday? >> > > > Yes... when it will work correctly. > > > I have at least, to rework 680x0 FPU part (80bit fpu) to not break > the existing one (64bit fpu). > I have to check modified instructions don't break existing m68k > emulation. Maybe Bryce can help you >>> >>> I don't know if he is courageous enough to review and push 111 >>> patches ;-) >> >> He worked on emulating an abandoned, strange, difficult to get, and >> undocumented hardware, using your 111 patches, and finished it before the >> wholy more experienced MESS team. > > The next-cube emulation is really working ? Yes, it is, absolutely. >> He is! xD > > There is no problem for me, he can do... > > Currently, I'm trying to port some parts of BasiliskII into Qemu to > be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? >>> >>> Because I'm lazy and dumb: the work is already done, I like cut'n'paste. >> >> Yeah, you said it! >> The work is already done, we have all the hardware emulation that Basilisk >> substitutes for hacks. > > I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no > video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p The MMU is your part I won't discuss on it. But porting BasiliskII will not make qemu have an m68k-system, but a macos7-wrapper. And that's the problem with Basilisk, that's why you cannot partition a disk, try MachTen, don't even think on A/UX. If you insist, please name it "basilisk2" and let Bryce (he wants to in the future) do the real machines (-M quadra, -M centris, -M IIcx) > You know, nights are not long enough... Move to North Pole, I've heard nights are six month long there ^^ >> We only lack the 68k cpu (oh! your patches!!!) and the glue :p > > this part is not working well as well ... gcc cannot compile linux > kernel, some demos fail in gtk-demo, ... I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p >> Please don't port Basilisk on top of TCG, I beg to you in the name of some >> god of your own choice :( > > I believe only in Santa Claus, and it's not Christmas. > >> (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no >> ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a >> Match!) > > Regards, > Laurent >
[Qemu-devel] [PATCH, braille] Add dots keypresses support to the baum braille device
Add dots keypresses support to the baum braille device.
Signed-off-by: Samuel Thibault
diff --git a/hw/baum.c b/hw/baum.c
index 21326ae..131348c 100644
--- a/hw/baum.c
+++ b/hw/baum.c
@@ -1,7 +1,7 @@
/*
* QEMU Baum Braille Device
*
- * Copyright (c) 2008, 2011 Samuel Thibault
+ * Copyright (c) 2008, 2010-2011 Samuel Thibault
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
deal
@@ -101,8 +101,11 @@ typedef struct {
} BaumDriverState;
/* Let's assume NABCC by default */
-static const uint8_t nabcc_translation[256] = {
-[0] = ' ',
+enum way {
+DOTS2ASCII,
+ASCII2DOTS
+};
+static const uint8_t nabcc_translation[2][256] = {
#ifndef BRLAPI_DOTS
#define BRLAPI_DOTS(d1,d2,d3,d4,d5,d6,d7,d8) \
((d1?BRLAPI_DOT1:0)|\
@@ -114,105 +117,109 @@ static const uint8_t nabcc_translation[256] = {
(d7?BRLAPI_DOT7:0)|\
(d8?BRLAPI_DOT8:0))
#endif
-[BRLAPI_DOTS(1,0,0,0,0,0,0,0)] = 'a',
-[BRLAPI_DOTS(1,1,0,0,0,0,0,0)] = 'b',
-[BRLAPI_DOTS(1,0,0,1,0,0,0,0)] = 'c',
-[BRLAPI_DOTS(1,0,0,1,1,0,0,0)] = 'd',
-[BRLAPI_DOTS(1,0,0,0,1,0,0,0)] = 'e',
-[BRLAPI_DOTS(1,1,0,1,0,0,0,0)] = 'f',
-[BRLAPI_DOTS(1,1,0,1,1,0,0,0)] = 'g',
-[BRLAPI_DOTS(1,1,0,0,1,0,0,0)] = 'h',
-[BRLAPI_DOTS(0,1,0,1,0,0,0,0)] = 'i',
-[BRLAPI_DOTS(0,1,0,1,1,0,0,0)] = 'j',
-[BRLAPI_DOTS(1,0,1,0,0,0,0,0)] = 'k',
-[BRLAPI_DOTS(1,1,1,0,0,0,0,0)] = 'l',
-[BRLAPI_DOTS(1,0,1,1,0,0,0,0)] = 'm',
-[BRLAPI_DOTS(1,0,1,1,1,0,0,0)] = 'n',
-[BRLAPI_DOTS(1,0,1,0,1,0,0,0)] = 'o',
-[BRLAPI_DOTS(1,1,1,1,0,0,0,0)] = 'p',
-[BRLAPI_DOTS(1,1,1,1,1,0,0,0)] = 'q',
-[BRLAPI_DOTS(1,1,1,0,1,0,0,0)] = 'r',
-[BRLAPI_DOTS(0,1,1,1,0,0,0,0)] = 's',
-[BRLAPI_DOTS(0,1,1,1,1,0,0,0)] = 't',
-[BRLAPI_DOTS(1,0,1,0,0,1,0,0)] = 'u',
-[BRLAPI_DOTS(1,1,1,0,0,1,0,0)] = 'v',
-[BRLAPI_DOTS(0,1,0,1,1,1,0,0)] = 'w',
-[BRLAPI_DOTS(1,0,1,1,0,1,0,0)] = 'x',
-[BRLAPI_DOTS(1,0,1,1,1,1,0,0)] = 'y',
-[BRLAPI_DOTS(1,0,1,0,1,1,0,0)] = 'z',
-
-[BRLAPI_DOTS(1,0,0,0,0,0,1,0)] = 'A',
-[BRLAPI_DOTS(1,1,0,0,0,0,1,0)] = 'B',
-[BRLAPI_DOTS(1,0,0,1,0,0,1,0)] = 'C',
-[BRLAPI_DOTS(1,0,0,1,1,0,1,0)] = 'D',
-[BRLAPI_DOTS(1,0,0,0,1,0,1,0)] = 'E',
-[BRLAPI_DOTS(1,1,0,1,0,0,1,0)] = 'F',
-[BRLAPI_DOTS(1,1,0,1,1,0,1,0)] = 'G',
-[BRLAPI_DOTS(1,1,0,0,1,0,1,0)] = 'H',
-[BRLAPI_DOTS(0,1,0,1,0,0,1,0)] = 'I',
-[BRLAPI_DOTS(0,1,0,1,1,0,1,0)] = 'J',
-[BRLAPI_DOTS(1,0,1,0,0,0,1,0)] = 'K',
-[BRLAPI_DOTS(1,1,1,0,0,0,1,0)] = 'L',
-[BRLAPI_DOTS(1,0,1,1,0,0,1,0)] = 'M',
-[BRLAPI_DOTS(1,0,1,1,1,0,1,0)] = 'N',
-[BRLAPI_DOTS(1,0,1,0,1,0,1,0)] = 'O',
-[BRLAPI_DOTS(1,1,1,1,0,0,1,0)] = 'P',
-[BRLAPI_DOTS(1,1,1,1,1,0,1,0)] = 'Q',
-[BRLAPI_DOTS(1,1,1,0,1,0,1,0)] = 'R',
-[BRLAPI_DOTS(0,1,1,1,0,0,1,0)] = 'S',
-[BRLAPI_DOTS(0,1,1,1,1,0,1,0)] = 'T',
-[BRLAPI_DOTS(1,0,1,0,0,1,1,0)] = 'U',
-[BRLAPI_DOTS(1,1,1,0,0,1,1,0)] = 'V',
-[BRLAPI_DOTS(0,1,0,1,1,1,1,0)] = 'W',
-[BRLAPI_DOTS(1,0,1,1,0,1,1,0)] = 'X',
-[BRLAPI_DOTS(1,0,1,1,1,1,1,0)] = 'Y',
-[BRLAPI_DOTS(1,0,1,0,1,1,1,0)] = 'Z',
-
-[BRLAPI_DOTS(0,0,1,0,1,1,0,0)] = '0',
-[BRLAPI_DOTS(0,1,0,0,0,0,0,0)] = '1',
-[BRLAPI_DOTS(0,1,1,0,0,0,0,0)] = '2',
-[BRLAPI_DOTS(0,1,0,0,1,0,0,0)] = '3',
-[BRLAPI_DOTS(0,1,0,0,1,1,0,0)] = '4',
-[BRLAPI_DOTS(0,1,0,0,0,1,0,0)] = '5',
-[BRLAPI_DOTS(0,1,1,0,1,0,0,0)] = '6',
-[BRLAPI_DOTS(0,1,1,0,1,1,0,0)] = '7',
-[BRLAPI_DOTS(0,1,1,0,0,1,0,0)] = '8',
-[BRLAPI_DOTS(0,0,1,0,1,0,0,0)] = '9',
-
-[BRLAPI_DOTS(0,0,0,1,0,1,0,0)] = '.',
-[BRLAPI_DOTS(0,0,1,1,0,1,0,0)] = '+',
-[BRLAPI_DOTS(0,0,1,0,0,1,0,0)] = '-',
-[BRLAPI_DOTS(1,0,0,0,0,1,0,0)] = '*',
-[BRLAPI_DOTS(0,0,1,1,0,0,0,0)] = '/',
-[BRLAPI_DOTS(1,1,1,0,1,1,0,0)] = '(',
-[BRLAPI_DOTS(0,1,1,1,1,1,0,0)] = ')',
-
-[BRLAPI_DOTS(1,1,1,1,0,1,0,0)] = '&',
-[BRLAPI_DOTS(0,0,1,1,1,1,0,0)] = '#',
-
-[BRLAPI_DOTS(0,0,0,0,0,1,0,0)] = ',',
-[BRLAPI_DOTS(0,0,0,0,1,1,0,0)] = ';',
-[BRLAPI_DOTS(1,0,0,0,1,1,0,0)] = ':',
-[BRLAPI_DOTS(0,1,1,1,0,1,0,0)] = '!',
-[BRLAPI_DOTS(1,0,0,1,1,1,0,0)] = '?',
-[BRLAPI_DOTS(0,0,0,0,1,0,0,0)] = '"',
-[BRLAPI_DOTS(0,0,1,0,0,0,0,0)] ='\'',
-[BRLAPI_DOTS(0,0,0,1,0,0,0,0)] = '`',
-[BRLAPI_DOTS(0,0,0,1,1,0,1,0)] = '^',
-[BRLAPI_DOTS(0,0,0,1,1,0,0,0)] = '~',
-[BRLAPI_DOTS(0,1,0,1,0,1,1,0)] = '[',
-[BRLAPI_DOTS(1,1,0,1,1,1,1,0)] = ']',
-[BRLAPI_DOTS(0,1,0,1,0,1,0,0)] = '{',
-[BRLAPI_DOTS(1,1,0,1,1,1,0,0)] = '}',
-[BRLAPI_DOTS(1,1,1,1,1,1,0,0)] = '=',
-[BRLAPI_DOTS(1,1,0,0,0,1,0,0)] = '<',
-[BRLAPI_DOTS(0,0,1,1,1,0,0,0)] = '>',
-[BRLAPI_DOTS(1,1,0,1,0,1,0,0)] = '$',
-[BRLAPI_DOTS(1,0,0,1,0,1,0,0)] = '%',
-[BRLAPI_DOTS(0,0,0,1,0,0,1,0)] = '@',
-[BRLAPI_DOTS(1,1,0,0,1,1,0,0)] = '|',
-[BRLAPI_DOTS(1,1,0,0,1,1,1,0)] ='
[Qemu-devel] ahmed
Je suis le fils de l'ancien ministre de la Guinée (Mariame Sy Diallo) mais je vis actuellement en Angleterre, j'ai trouvé votre adresse à la chambre de commerce ici à Londres, j'ai besoin de votre aide pour investir au Maroc ou Algérie ou en Tunisie. Si vous êtes intéressé à ma demandes'il vous plaît contactez-moi sur mon adresse e-mail (ahmeddiall...@gmail.com) ou sur mon numéro, (+447031869448). Merci de votre bonne compréhension Ahmed. Pour plus de détails. Je veux en savoir plus sur vous Votre nom ... Votre ville actuelle... Votre profession ... ... ... ... .. V
Re: [Qemu-devel] [PATCH] block/curl: Handle failed reads gracefully.
Am 15.08.2011 11:00, schrieb Nicholas Thomas: > Current behaviour if a read fails is for the acb to not get finished. > This causes an infinite loop in bdrv_read_em (block.c). The read failure > never gets reported to the guest and if the error condition clears, the > process never recovers. > > With this patch, when curl reports a failure we finish the acb as a > failure. This results in the guest receiving an I/O error (rather than > the read hanging indefinitely) and if the error condition subsequently > clears, retries work as expected. > > The simplest test is to put an ISO on a web server you have control over > and open it with qemu-io. Then move the ISO out of the way and attempt > to read some data - you should see behaviour matching the above. > > Signed-off-by: Nick Thomas Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH v2 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode
On 2011-08-17 16:48, Avi Kivity wrote: > On 08/17/2011 04:38 PM, Avi Kivity wrote: >> >> The mmio code has >> >> s->plane_updated |= mask; /* only used to detect font >> change */ >> >> aren't we losing it? we could easily recover it via dirty logging. >> Yes, I forgot to forward-port plane_updated = 0xf from v1 of the patch. > > We can't really recover it. I don't see yet why we should not if we simply enforce a full update. Can you elaborate? > So I think we need to restrict the > optimization to graphic mode. > > Is grub using text mode or graphic mode? > > If it's using text mode, it may be faster to compare the font plane to a > snapshot from the last redraw than to take an exit. I wasn't optimizing for text mode here, it's just a side effect if it happens to benefit from it as well. I could exclude it, but only if really needed. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : > Hi Laurent, > > El 18/08/2011, a las 20:57, Laurent Vivier escribió: > > > Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : > >> Hi Laurent, > > > > Hi Natalia, > > > >> El 18/08/2011, a las 15:02, Laurent Vivier escribió: > >> > >>> > >>> > >>> > >>> Le 18 août 2011 à 13:12, "François Revol" a écrit : > >>> > Le -10/01/-28163 20:59, Laurent Vivier a écrit : > > Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a > >>> écrit : > >> On 08/17/2011 03:46 PM, Bryce Lanham wrote: > >>> These patches greatly expand Motorola 68k emulation within > >>> qemu, and are what I used as a basis for my > >>> Google Summer of Code project to add NeXT hardware support to > >>> QEMU. > >> > >> Please don't crap flood the list with a series of 100 patches. > >> > >> Split things into logical chunks such that a series can be > >>> reasonably > >> reviewed and applied. > > > > And I'm not sure this series of patches is ready for inclusion > >>> in qemu > > mainline as it should break existing m68k emulation... > > > > Bryce, you should only post your patches, refering to the > >>> repository on > > which they apply, i.e. > >>> git://gitorious.org/qemu-m68k/qemu-m68k.git , > > master branch. > > > > Btw, are you planning on merging it back someday? > > >>> > >>> > >>> Yes... when it will work correctly. > >>> > >>> > >>> I have at least, to rework 680x0 FPU part (80bit fpu) to not break > >>> the existing one (64bit fpu). > >>> I have to check modified instructions don't break existing m68k > >>> emulation. > >> > >> > >> Maybe Bryce can help you > > > > I don't know if he is courageous enough to review and push 111 > > patches ;-) > > He worked on emulating an abandoned, strange, difficult to get, and > undocumented hardware, using your 111 patches, and finished it before the > wholy more experienced MESS team. The next-cube emulation is really working ? > He is! xD There is no problem for me, he can do... > >>> Currently, I'm trying to port some parts of BasiliskII into Qemu to > >>> be able to boot MacOS 7.6. > >> > >> > >> Why are you planning to port a hack instead of making a full machine > >> emulation? > > > > Because I'm lazy and dumb: the work is already done, I like cut'n'paste. > > Yeah, you said it! > The work is already done, we have all the hardware emulation that Basilisk > substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. You know, nights are not long enough... > We only lack the 68k cpu (oh! your patches!!!) and the glue :p this part is not working well as well ... gcc cannot compile linux kernel, some demos fail in gtk-demo, ... > Please don't port Basilisk on top of TCG, I beg to you in the name of some > god of your own choice :( I believe only in Santa Claus, and it's not Christmas. > (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no > ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a > Match!) Regards, Laurent
[Qemu-devel] [PATCH v2 3/4] ppc: booke206: use MAV=2.0 TSIZE definition, fix 4G pages
This definition is backward compatible with MAV=1.0 as long as
the guest does not set reserved bits in MAS1/MAS4.
Also, fix the shift in booke206_tlb_to_page_size -- it's the base
that should be able to hold a 4G page size, not the shift count.
Signed-off-by: Scott Wood
---
v2 (was 2/3 in v1): no change
hw/ppce500_mpc8544ds.c |2 +-
target-ppc/cpu.h |4 ++--
target-ppc/helper.c|5 +++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/ppce500_mpc8544ds.c b/hw/ppce500_mpc8544ds.c
index 3626e26..1aed612 100644
--- a/hw/ppce500_mpc8544ds.c
+++ b/hw/ppce500_mpc8544ds.c
@@ -187,7 +187,7 @@ out:
/* Create -kernel TLB entries for BookE, linearly spanning 256MB. */
static inline target_phys_addr_t booke206_page_size_to_tlb(uint64_t size)
{
-return (ffs(size >> 10) - 1) >> 1;
+return ffs(size >> 10) - 1;
}
static void mmubooke_create_initial_mapping(CPUState *env,
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 0e38d4f..06d78ca 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -652,8 +652,8 @@ enum {
#define MAS0_ATSEL_TLB 0
#define MAS0_ATSEL_LRATMAS0_ATSEL
-#define MAS1_TSIZE_SHIFT 8
-#define MAS1_TSIZE_MASK(0xf << MAS1_TSIZE_SHIFT)
+#define MAS1_TSIZE_SHIFT 7
+#define MAS1_TSIZE_MASK(0x1f << MAS1_TSIZE_SHIFT)
#define MAS1_TS_SHIFT 12
#define MAS1_TS(1 << MAS1_TS_SHIFT)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 789e6aa..d9a3855 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1293,7 +1293,7 @@ target_phys_addr_t booke206_tlb_to_page_size(CPUState
*env, ppcmas_tlb_t *tlb)
{
uint32_t tlbncfg;
int tlbn = booke206_tlbm_to_tlbn(env, tlb);
-target_phys_addr_t tlbm_size;
+int tlbm_size;
tlbncfg = env->spr[SPR_BOOKE_TLB0CFG + tlbn];
@@ -1301,9 +1301,10 @@ target_phys_addr_t booke206_tlb_to_page_size(CPUState
*env, ppcmas_tlb_t *tlb)
tlbm_size = (tlb->mas1 & MAS1_TSIZE_MASK) >> MAS1_TSIZE_SHIFT;
} else {
tlbm_size = (tlbncfg & TLBnCFG_MINSIZE) >> TLBnCFG_MINSIZE_SHIFT;
+tlbm_size <<= 1;
}
-return (1 << (tlbm_size << 1)) << 10;
+return 1024ULL << tlbm_size;
}
/* TLB check function for MAS based SoftTLBs */
--
1.7.6
[Qemu-devel] [PATCH v2 4/4] ppc: booke206: add "info tlb" support
Signed-off-by: Scott Wood
---
v2 (was 3/3 in v1): no change
hmp-commands.hx |2 +-
monitor.c |5 ++-
target-ppc/cpu.h|2 +
target-ppc/helper.c | 88 +++
4 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0ccfb28..589c1ef 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1306,7 +1306,7 @@ show i8259 (PIC) state
@item info pci
show emulated PCI device info
@item info tlb
-show virtual to physical memory mappings (i386, SH4 and SPARC only)
+show virtual to physical memory mappings (i386, SH4, SPARC, and PPC only)
@item info mem
show the active virtual memory mappings (i386 only)
@item info jit
diff --git a/monitor.c b/monitor.c
index 1b8ba2c..a59aefd 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2442,7 +2442,7 @@ static void tlb_info(Monitor *mon)
#endif
-#if defined(TARGET_SPARC)
+#if defined(TARGET_SPARC) || defined(TARGET_PPC)
static void tlb_info(Monitor *mon)
{
CPUState *env1 = mon_get_cpu();
@@ -2935,7 +2935,8 @@ static const mon_cmd_t info_cmds[] = {
.user_print = do_pci_info_print,
.mhandler.info_new = do_pci_info,
},
-#if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC)
+#if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC) || \
+defined(TARGET_PPC)
{
.name = "tlb",
.args_type = "",
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 06d78ca..dd5e021 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -2030,4 +2030,6 @@ static inline void cpu_pc_from_tb(CPUState *env,
TranslationBlock *tb)
env->nip = tb->pc;
}
+void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env);
+
#endif /* !defined (__CPU_PPC_H__) */
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index d9a3855..1c77ed7 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1466,6 +1466,94 @@ found_tlb:
return ret;
}
+static const char *book3e_tsize_to_str[32] = {
+"1K", "2K", "4K", "8K", "16K", "32K", "64K", "128K", "256K", "512K",
+"1M", "2M", "4M", "8M", "16M", "32M", "64M", "128M", "256M", "512M",
+"1G", "2G", "4G", "8G", "16G", "32G", "64G", "128G", "256G", "512G",
+"1T", "2T"
+};
+
+static void mmubooke206_dump_one_tlb(FILE *f, fprintf_function cpu_fprintf,
+ CPUState *env, int tlbn, int offset,
+ int tlbsize)
+{
+ppcmas_tlb_t *entry;
+int i;
+
+cpu_fprintf(f, "\nTLB%d:\n", tlbn);
+cpu_fprintf(f, "Effective Physical Size TID TS SRWX
URWX WIMGE U0123\n");
+
+entry = &env->tlb.tlbm[offset];
+for (i = 0; i < tlbsize; i++, entry++) {
+target_phys_addr_t ea, pa, size;
+int tsize;
+
+if (!(entry->mas1 & MAS1_VALID)) {
+continue;
+}
+
+tsize = (entry->mas1 & MAS1_TSIZE_MASK) >> MAS1_TSIZE_SHIFT;
+size = 1024ULL << tsize;
+ea = entry->mas2 & ~(size - 1);
+pa = entry->mas7_3 & ~(size - 1);
+
+cpu_fprintf(f, "0x%016" PRIx64 " 0x%016" PRIx64 " %4s %-5u %1u
S%c%c%c U%c%c%c %c%c%c%c%c U%c%c%c%c\n",
+(uint64_t)ea, (uint64_t)pa,
+book3e_tsize_to_str[tsize],
+(entry->mas1 & MAS1_TID_MASK) >> MAS1_TID_SHIFT,
+(entry->mas1 & MAS1_TS) >> MAS1_TS_SHIFT,
+entry->mas7_3 & MAS3_SR ? 'R' : '-',
+entry->mas7_3 & MAS3_SW ? 'W' : '-',
+entry->mas7_3 & MAS3_SX ? 'X' : '-',
+entry->mas7_3 & MAS3_UR ? 'R' : '-',
+entry->mas7_3 & MAS3_UW ? 'W' : '-',
+entry->mas7_3 & MAS3_UX ? 'X' : '-',
+entry->mas2 & MAS2_W ? 'W' : '-',
+entry->mas2 & MAS2_I ? 'I' : '-',
+entry->mas2 & MAS2_M ? 'M' : '-',
+entry->mas2 & MAS2_G ? 'G' : '-',
+entry->mas2 & MAS2_E ? 'E' : '-',
+entry->mas7_3 & MAS3_U0 ? '0' : '-',
+entry->mas7_3 & MAS3_U1 ? '1' : '-',
+entry->mas7_3 & MAS3_U2 ? '2' : '-',
+entry->mas7_3 & MAS3_U3 ? '3' : '-');
+}
+}
+
+static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
+ CPUState *env)
+{
+int offset = 0;
+int i;
+
+if (kvm_enabled() && !env->kvm_sw_tlb) {
+cpu_fprintf(f, "Cannot access KVM TLB\n");
+return;
+}
+
+for (i = 0; i < BOOKE206_MAX_TLBN; i++) {
+int size = booke206_tlb_size(env, i);
+
+if (size == 0) {
+continue;
+}
+
+mmubooke206_dump_one_tlb(f, cpu_fprintf, env, i, offset, size);
+offset += size;
+}
+}
+
+void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
+{
+switch (env->mmu_model) {
+case POWERPC_M
[Qemu-devel] [PATCH v2 2/4] kvm: ppc: booke206: use MMU API
Share the TLB array with KVM. This allows us to set the initial TLB
both on initial boot and reset, is useful for debugging, and could
eventually be used to support migration.
Signed-off-by: Scott Wood
---
v2 (was 1/3 in v1):
updated for kernel API change, removed kernel header ifdefs,
minor changes as requested
hw/ppce500_mpc8544ds.c |2 +
target-ppc/cpu.h |2 +
target-ppc/kvm.c | 87
3 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/hw/ppce500_mpc8544ds.c b/hw/ppce500_mpc8544ds.c
index b739ce2..3626e26 100644
--- a/hw/ppce500_mpc8544ds.c
+++ b/hw/ppce500_mpc8544ds.c
@@ -202,6 +202,8 @@ static void mmubooke_create_initial_mapping(CPUState *env,
tlb->mas2 = va & TARGET_PAGE_MASK;
tlb->mas7_3 = pa & TARGET_PAGE_MASK;
tlb->mas7_3 |= MAS3_UR | MAS3_UW | MAS3_UX | MAS3_SR | MAS3_SW | MAS3_SX;
+
+env->tlb_dirty = true;
}
static void mpc8544ds_cpu_reset(void *opaque)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 024eb6f..0e38d4f 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -919,6 +919,8 @@ struct CPUPPCState {
ppc_tlb_t tlb; /* TLB is optional. Allocate them only if needed*/
/* 403 dedicated access protection registers */
target_ulong pb[4];
+bool tlb_dirty; /* Set to non-zero when modifying TLB */
+bool kvm_sw_tlb; /* non-zero if KVM SW TLB API is active*/
#endif
/* Other registers */
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 21f35af7..1e1e5db 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -105,6 +105,54 @@ static int kvm_arch_sync_sregs(CPUState *cenv)
return kvm_vcpu_ioctl(cenv, KVM_SET_SREGS, &sregs);
}
+/* Set up a shared TLB array with KVM */
+static int kvm_booke206_tlb_init(CPUState *env)
+{
+struct kvm_book3e_206_tlb_params params = {};
+struct kvm_config_tlb cfg = {};
+struct kvm_enable_cap encap = {};
+size_t array_len;
+unsigned int entries = 0;
+int ret, i;
+
+if (!kvm_enabled() ||
+!kvm_check_extension(env->kvm_state, KVM_CAP_SW_TLB)) {
+return 0;
+}
+
+assert(ARRAY_SIZE(params.tlb_sizes) == BOOKE206_MAX_TLBN);
+
+for (i = 0; i < BOOKE206_MAX_TLBN; i++) {
+params.tlb_sizes[i] = booke206_tlb_size(env, i);
+params.tlb_ways[i] = booke206_tlb_ways(env, i);
+entries += params.tlb_sizes[i];
+}
+
+assert(entries == env->nb_tlb);
+assert(sizeof(struct kvm_book3e_206_tlb_entry) == sizeof(ppcmas_tlb_t));
+
+array_len = sizeof(ppcmas_tlb_t) * entries;
+env->tlb_dirty = true;
+
+cfg.array = (uintptr_t)env->tlb.tlbm;
+cfg.array_len = sizeof(ppcmas_tlb_t) * entries;
+cfg.params = (uintptr_t)¶ms;
+cfg.mmu_type = KVM_MMU_FSL_BOOKE_NOHV;
+
+encap.cap = KVM_CAP_SW_TLB;
+encap.args[0] = (uintptr_t)&cfg;
+
+ret = kvm_vcpu_ioctl(env, KVM_ENABLE_CAP, &encap);
+if (ret < 0) {
+fprintf(stderr, "%s: couldn't enable KVM_CAP_SW_TLB: %s\n",
+__func__, strerror(-ret));
+return ret;
+}
+
+env->kvm_sw_tlb = true;
+return 0;
+}
+
int kvm_arch_init_vcpu(CPUState *cenv)
{
int ret;
@@ -116,6 +164,15 @@ int kvm_arch_init_vcpu(CPUState *cenv)
idle_timer = qemu_new_timer_ns(vm_clock, kvm_kick_env, cenv);
+/* Some targets support access to KVM's guest TLB. */
+switch (cenv->mmu_model) {
+case POWERPC_MMU_BOOKE206:
+ret = kvm_booke206_tlb_init(cenv);
+break;
+default:
+break;
+}
+
return ret;
}
@@ -123,6 +180,31 @@ void kvm_arch_reset_vcpu(CPUState *env)
{
}
+static void kvm_sw_tlb_put(CPUState *env)
+{
+struct kvm_dirty_tlb dirty_tlb;
+unsigned char *bitmap;
+int ret;
+
+if (!env->kvm_sw_tlb) {
+return;
+}
+
+bitmap = qemu_malloc((env->nb_tlb + 7) / 8);
+memset(bitmap, 0xFF, (env->nb_tlb + 7) / 8);
+
+dirty_tlb.bitmap = (uintptr_t)bitmap;
+dirty_tlb.num_dirty = env->nb_tlb;
+
+ret = kvm_vcpu_ioctl(env, KVM_DIRTY_TLB, &dirty_tlb);
+if (ret) {
+fprintf(stderr, "%s: KVM_DIRTY_TLB: %s\n",
+__func__, strerror(-ret));
+}
+
+qemu_free(bitmap);
+}
+
int kvm_arch_put_registers(CPUState *env, int level)
{
struct kvm_regs regs;
@@ -160,6 +242,11 @@ int kvm_arch_put_registers(CPUState *env, int level)
if (ret < 0)
return ret;
+if (env->tlb_dirty) {
+kvm_sw_tlb_put(env);
+env->tlb_dirty = false;
+}
+
return ret;
}
--
1.7.6
[Qemu-devel] [PATCH v2 1/4] kvm: update linux-headers
Needed for PPC MMU API support.
Signed-off-by: Scott Wood
---
v2: new to v2
linux-headers/asm-powerpc/kvm.h | 54 -
linux-headers/asm-x86/kvm_para.h | 14 ++
linux-headers/linux/kvm.h| 41 +++-
linux-headers/linux/kvm_para.h |1 +
4 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index 777d307..874f23d 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -22,6 +22,10 @@
#include
+/* Select powerpc specific features in */
+#define __KVM_HAVE_SPAPR_TCE
+#define __KVM_HAVE_PPC_SMT
+
struct kvm_regs {
__u64 pc;
__u64 cr;
@@ -166,8 +170,8 @@ struct kvm_sregs {
} ppc64;
struct {
__u32 sr[16];
- __u64 ibat[8];
- __u64 dbat[8];
+ __u64 ibat[8];
+ __u64 dbat[8];
} ppc32;
} s;
struct {
@@ -272,4 +276,50 @@ struct kvm_guest_debug_arch {
#define KVM_INTERRUPT_UNSET-2U
#define KVM_INTERRUPT_SET_LEVEL-3U
+/* for KVM_CAP_SPAPR_TCE */
+struct kvm_create_spapr_tce {
+ __u64 liobn;
+ __u32 window_size;
+};
+
+/* for KVM_ALLOCATE_RMA */
+struct kvm_allocate_rma {
+ __u64 rma_size;
+};
+
+struct kvm_book3e_206_tlb_entry {
+ __u32 mas8;
+ __u32 mas1;
+ __u64 mas2;
+ __u64 mas7_3;
+};
+
+struct kvm_book3e_206_tlb_params {
+ /*
+* For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
+*
+* - The number of ways of TLB0 must be a power of two between 2 and
+* 16.
+* - TLB1 must be fully associative.
+* - The size of TLB0 must be a multiple of the number of ways, and
+* the number of sets must be a power of two.
+* - The size of TLB1 may not exceed 64 entries.
+* - TLB0 supports 4 KiB pages.
+* - The page sizes supported by TLB1 are as indicated by
+* TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
+* as returned by KVM_GET_SREGS.
+* - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
+* and tlb_ways[] must be zero.
+*
+* tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
+*
+* KVM will adjust TLBnCFG based on the sizes configured here,
+* though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
+* set to zero.
+*/
+ __u32 tlb_sizes[4];
+ __u32 tlb_ways[4];
+ __u32 reserved[8];
+};
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index 834d71e..f2ac46a 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -21,6 +21,7 @@
*/
#define KVM_FEATURE_CLOCKSOURCE23
#define KVM_FEATURE_ASYNC_PF 4
+#define KVM_FEATURE_STEAL_TIME 5
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
@@ -30,10 +31,23 @@
#define MSR_KVM_WALL_CLOCK 0x11
#define MSR_KVM_SYSTEM_TIME 0x12
+#define KVM_MSR_ENABLED 1
/* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
#define MSR_KVM_WALL_CLOCK_NEW 0x4b564d00
#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
+#define MSR_KVM_STEAL_TIME 0x4b564d03
+
+struct kvm_steal_time {
+ __u64 steal;
+ __u32 version;
+ __u32 flags;
+ __u32 pad[12];
+};
+
+#define KVM_STEAL_ALIGNMENT_BITS 5
+#define KVM_STEAL_VALID_BITS ((-1ULL << (KVM_STEAL_ALIGNMENT_BITS + 1)))
+#define KVM_STEAL_RESERVED_MASK (((1 << KVM_STEAL_ALIGNMENT_BITS) - 1 ) << 1)
#define KVM_MAX_MMU_OP_BATCH 32
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index fc63b73..7d8a7f6 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -161,6 +161,7 @@ struct kvm_pit_config {
#define KVM_EXIT_NMI 16
#define KVM_EXIT_INTERNAL_ERROR 17
#define KVM_EXIT_OSI 18
+#define KVM_EXIT_PAPR_HCALL 19
/* For KVM_EXIT_INTERNAL_ERROR */
#define KVM_INTERNAL_ERROR_EMULATION 1
@@ -264,6 +265,11 @@ struct kvm_run {
struct {
__u64 gprs[32];
} osi;
+ struct {
+ __u64 nr;
+ __u64 ret;
+ __u64 args[9];
+ } papr_hcall;
/* Fix the size of the union. */
char padding[256];
};
@@ -457,7 +463,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_VAPIC 6
#define KVM_CAP_EXT_CPUID 7
#define KVM_CAP_CLOCKSOURCE 8
-#define KVM_CAP_NR_VCPUS 9
[Qemu-devel] [PATCH v2 0/4] ppc: booke206: KVM MMU API and info tlb
For this functionality to work with KVM, this kernel patch is required: http://www.spinics.net/lists/kvm-ppc/msg03053.html Scott Wood (4): kvm: update linux-headers kvm: ppc: booke206: use MMU API ppc: booke206: use MAV=2.0 TSIZE definition, fix 4G pages ppc: booke206: add "info tlb" support hmp-commands.hx |2 +- hw/ppce500_mpc8544ds.c |4 +- linux-headers/asm-powerpc/kvm.h | 54 +- linux-headers/asm-x86/kvm_para.h | 14 ++ linux-headers/linux/kvm.h| 41 +--- linux-headers/linux/kvm_para.h |1 + monitor.c|5 +- target-ppc/cpu.h |8 +++- target-ppc/helper.c | 93 +- target-ppc/kvm.c | 87 +++ 10 files changed, 291 insertions(+), 18 deletions(-) -- 1.7.6
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: > Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : >> Hi Laurent, > > Hi Natalia, > >> El 18/08/2011, a las 15:02, Laurent Vivier escribió: >> >>> >>> >>> >>> Le 18 août 2011 à 13:12, "François Revol" a écrit : >>> Le -10/01/-28163 20:59, Laurent Vivier a écrit : > Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a >>> écrit : >> On 08/17/2011 03:46 PM, Bryce Lanham wrote: >>> These patches greatly expand Motorola 68k emulation within >>> qemu, and are what I used as a basis for my >>> Google Summer of Code project to add NeXT hardware support to >>> QEMU. >> >> Please don't crap flood the list with a series of 100 patches. >> >> Split things into logical chunks such that a series can be >>> reasonably >> reviewed and applied. > > And I'm not sure this series of patches is ready for inclusion >>> in qemu > mainline as it should break existing m68k emulation... > > Bryce, you should only post your patches, refering to the >>> repository on > which they apply, i.e. >>> git://gitorious.org/qemu-m68k/qemu-m68k.git , > master branch. > Btw, are you planning on merging it back someday? >>> >>> >>> Yes... when it will work correctly. >>> >>> >>> I have at least, to rework 680x0 FPU part (80bit fpu) to not break >>> the existing one (64bit fpu). >>> I have to check modified instructions don't break existing m68k >>> emulation. >> >> >> Maybe Bryce can help you > > I don't know if he is courageous enough to review and push 111 > patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. He is! xD >>> Currently, I'm trying to port some parts of BasiliskII into Qemu to >>> be able to boot MacOS 7.6. >> >> >> Why are you planning to port a hack instead of making a full machine >> emulation? > > Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. We only lack the 68k cpu (oh! your patches!!!) and the glue :p Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!)
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : > Hi Laurent, Hi Natalia, > El 18/08/2011, a las 15:02, Laurent Vivier escribió: > > > > > > > > > Le 18 août 2011 à 13:12, "François Revol" a écrit : > > > > > Le -10/01/-28163 20:59, Laurent Vivier a écrit : > > > > Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a > > écrit : > > > >> On 08/17/2011 03:46 PM, Bryce Lanham wrote: > > > >>> These patches greatly expand Motorola 68k emulation within > > qemu, and are what I used as a basis for my > > > >>> Google Summer of Code project to add NeXT hardware support to > > QEMU. > > > >> > > > >> Please don't crap flood the list with a series of 100 patches. > > > >> > > > >> Split things into logical chunks such that a series can be > > reasonably > > > >> reviewed and applied. > > > > > > > > And I'm not sure this series of patches is ready for inclusion > > in qemu > > > > mainline as it should break existing m68k emulation... > > > > > > > > Bryce, you should only post your patches, refering to the > > repository on > > > > which they apply, i.e. > > git://gitorious.org/qemu-m68k/qemu-m68k.git , > > > > master branch. > > > > > > > > > > Btw, are you planning on merging it back someday? > > > > > > > > > Yes... when it will work correctly. > > > > > > I have at least, to rework 680x0 FPU part (80bit fpu) to not break > > the existing one (64bit fpu). > > I have to check modified instructions don't break existing m68k > > emulation. > > > Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) > > Currently, I'm trying to port some parts of BasiliskII into Qemu to > > be able to boot MacOS 7.6. > > > Why are you planning to port a hack instead of making a full machine > emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi Laurent, El 18/08/2011, a las 15:02, Laurent Vivier escribió: > > > Le 18 août 2011 à 13:12, "François Revol" a écrit : > > > Le -10/01/-28163 20:59, Laurent Vivier a écrit : > > > Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : > > >> On 08/17/2011 03:46 PM, Bryce Lanham wrote: > > >>> These patches greatly expand Motorola 68k emulation within qemu, and > > >>> are what I used as a basis for my > > >>> Google Summer of Code project to add NeXT hardware support to QEMU. > > >> > > >> Please don't crap flood the list with a series of 100 patches. > > >> > > >> Split things into logical chunks such that a series can be reasonably > > >> reviewed and applied. > > > > > > And I'm not sure this series of patches is ready for inclusion in qemu > > > mainline as it should break existing m68k emulation... > > > > > > Bryce, you should only post your patches, refering to the repository on > > > which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , > > > master branch. > > > > > > > Btw, are you planning on merging it back someday? > > > > Yes... when it will work correctly. > > I have at least, to rework 680x0 FPU part (80bit fpu) to not break the > existing one (64bit fpu). > I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you > Currently, I'm trying to port some parts of BasiliskII into Qemu to be able > to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? > Regards, > Laurent
[Qemu-devel] [Bug 567376] Re: qemu-img fails to convert image
0.15.0 under win7 64-bit seems to work OK. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/567376 Title: qemu-img fails to convert image Status in QEMU: Incomplete Bug description: On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 built locally, when I run the following commands, a dialog is displayed indicating that "qemu-img.exe has encountered a problem and needs to close". qemu-img create foo.img 1G qemu-img convert -O qcow2 foo.img bar.img To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/567376/+subscriptions
[Qemu-devel] [Bug 567380] Re: qemu-img fails to create images >= 4G
Confirmed under Win 7 64-bit. Also does same thing on v10.6, v11.1, v12.1 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/567380 Title: qemu-img fails to create images >= 4G Status in QEMU: Incomplete Bug description: On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created. qemu-img create foo.img 4G To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/567380/+subscriptions
[Qemu-devel] VMState assertion for USB devices on multiple buses
I've been experimenting with multiple USB2 buses, and device physical port addressing. It seems if you have 2 devices of the same type on the same port, but in different buses, you get a bogus VMState assertion failure # qemu-system-x86_64 \ -nodefconfig -nodefaults \ -vnc 127.0.0.1:0 -vga cirrus -monitor stdio \ -device ich9-usb-ehci1,addr=1d.7,multifunction=on,id=ehci0 \ -device ich9-usb-uhci1,addr=1d.0,multifunction=on,id=uhci0-1,masterbus=ehci0.0,firstport=0 \ -device ich9-usb-uhci2,addr=1d.1,multifunction=on,id=uhci0-2,masterbus=ehci0.0,firstport=2 \ -device ich9-usb-uhci3,addr=1d.2,multifunction=on,id=uhci0-3,masterbus=ehci0.0,firstport=4 \ -device usb-tablet,bus=ehci0.0,port=1,id=t1 \ -device ich9-usb-ehci1,addr=1c.7,multifunction=on,id=ehci1 \ -device ich9-usb-uhci1,addr=1c.0,multifunction=on,id=uhci1-1,masterbus=ehci1.0,firstport=0 \ -device ich9-usb-uhci2,addr=1c.1,multifunction=on,id=uhci1-2,masterbus=ehci1.0,firstport=2 \ -device ich9-usb-uhci3,addr=1c.2,multifunction=on,id=uhci1-3,masterbus=ehci1.0,firstport=4 \ -device usb-tablet,bus=ehci1.0,port=1,id=t2 *** EHCI support is under development *** *** EHCI support is under development *** qemu-system-x86_64: savevm.c:1260: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. Aborted If I have a CCID on one bus, and tablet on the other it works # qemu-system-x86_64 \ -nodefconfig -nodefaults \ -vnc 127.0.0.1:0 -vga cirrus -monitor stdio \ -device ich9-usb-ehci1,addr=1d.7,multifunction=on,id=ehci0 \ -device ich9-usb-uhci1,addr=1d.0,multifunction=on,id=uhci0-1,masterbus=ehci0.0,firstport=0 \ -device ich9-usb-uhci2,addr=1d.1,multifunction=on,id=uhci0-2,masterbus=ehci0.0,firstport=2 \ -device ich9-usb-uhci3,addr=1d.2,multifunction=on,id=uhci0-3,masterbus=ehci0.0,firstport=4 \ -device usb-tablet,bus=ehci0.0,port=1,id=t1 \ -device ich9-usb-ehci1,addr=1c.7,multifunction=on,id=ehci1 \ -device ich9-usb-uhci1,addr=1c.0,multifunction=on,id=uhci1-1,masterbus=ehci1.0,firstport=0 \ -device ich9-usb-uhci2,addr=1c.1,multifunction=on,id=uhci1-2,masterbus=ehci1.0,firstport=2 \ -device ich9-usb-uhci3,addr=1c.2,multifunction=on,id=uhci1-3,masterbus=ehci1.0,firstport=4 \ -device usb-ccid,bus=ehci1.0,port=1,id=t2 But if I have 2 CCID devices, then I see failure again # qemu-system-x86_64 \ -nodefconfig -nodefaults \ -vnc 127.0.0.1:0 -vga cirrus -monitor stdio \ -device ich9-usb-ehci1,addr=1d.7,multifunction=on,id=ehci0 \ -device ich9-usb-uhci1,addr=1d.0,multifunction=on,id=uhci0-1,masterbus=ehci0.0,firstport=0 \ -device ich9-usb-uhci2,addr=1d.1,multifunction=on,id=uhci0-2,masterbus=ehci0.0,firstport=2 \ -device ich9-usb-uhci3,addr=1d.2,multifunction=on,id=uhci0-3,masterbus=ehci0.0,firstport=4 \ -device usb-ccid,bus=ehci0.0,port=1,id=t1 \ -device ich9-usb-ehci1,addr=1c.7,multifunction=on,id=ehci1 \ -device ich9-usb-uhci1,addr=1c.0,multifunction=on,id=uhci1-1,masterbus=ehci1.0,firstport=0 \ -device ich9-usb-uhci2,addr=1c.1,multifunction=on,id=uhci1-2,masterbus=ehci1.0,firstport=2 \ -device ich9-usb-uhci3,addr=1c.2,multifunction=on,id=uhci1-3,masterbus=ehci1.0,firstport=4 \ -device usb-ccid,bus=ehci1.0,port=1,id=t2 *** EHCI support is under development *** *** EHCI support is under development *** qemu-system-x86_64: savevm.c:1260: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. Aborted AFAICT, the problem is that the 'se->idstr' field in the SaveStateEntry struct is not getting a unique enough value. Both the USB devices get idstr named "1/usb-ccid", which IIUC is a combination of the device type and the port number. IMHO, it needs to have the USB bus name in there too eg. in this example it should have been ehci0.0/1/usb-ccid ehci1.0/1/usb-ccid Regrads, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
This makes the tracing infrastructure available to users of g_new().
Signed-off-by: Avi Kivity
---
qemu-common.h |1 +
qemu-malloc.c | 15 +++
vl.c |1 +
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/qemu-common.h b/qemu-common.h
index 74d5c4b..fbe2de0 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -180,6 +180,7 @@ const char *path(const char *pathname);
#define qemu_isascii(c)isascii((unsigned char)(c))
#define qemu_toascii(c)toascii((unsigned char)(c))
+void qemu_malloc_init(void);
void *qemu_oom_check(void *ptr);
void *qemu_malloc(size_t size);
void *qemu_realloc(void *ptr, size_t size);
diff --git a/qemu-malloc.c b/qemu-malloc.c
index b9b3851..8b0c1ec 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -24,6 +24,21 @@
#include "qemu-common.h"
#include "trace.h"
#include
+#include
+
+static GMemVTable gmemvtable = {
+.malloc = qemu_malloc,
+.realloc = qemu_realloc,
+.free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+g_mem_set_vtable(&gmemvtable);
+}
void qemu_free(void *ptr)
{
diff --git a/vl.c b/vl.c
index c714127..7c4f8da 100644
--- a/vl.c
+++ b/vl.c
@@ -2106,6 +2106,7 @@ int main(int argc, char **argv, char **envp)
atexit(qemu_run_exit_notifiers);
error_set_progname(argv[0]);
+qemu_malloc_init();
init_clocks();
--
1.7.6
Re: [Qemu-devel] [PATCH 04/14] gus: Convert to isa_register_old_portio_list.
On Tue, 16 Aug 2011, Richard Henderson wrote: > Signed-off-by: Richard Henderson > Cc: malc This patchset breaks both gus and sb16 for me. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Serial port on virtual machines
On Thu, Aug 18, 2011 at 22:00, bala suru wrote: > Hi, > > I'm running VM on kvm-qemu hyper visor . I need to access the serail port on > the VM , > I tried the sample code to read/write com port but I get port error when > ever I tried write something to the port(dev/ttyS0) . try to read the man page...i think you need to enable serial port first. You might want to use "-serial" option for that case. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
[Qemu-devel] Building qemu.exe on cygwin (0.15.0)
Hi, I need windows binaries for 0.15.0 so I tried to find them but no luck, so I tried to build it myself with cygwin. By following Lassauge's advices on http://lassauge.free.fr/qemu/ I reached the point where make tries to build/link qemu.exe but ld fails. I think reaching this point is a good sign, considering the amount of changes included in the windows patch for 0.13.0 (or 0.15.0 also needs heavy modifying to be builded on cygwin??) The error are related to multeple definition of _sin, _cos and other related math functions in libmsvcrt.a. I found some info about this type of error but it looks like it usually involves heavy-code changing in the libraries. Question: Can someone help me with some advices about changing some library-versions or compilation-settings or maybe changing compiler? === I applied no patches to 0.15.0 and this is the output of the qemu.exe building: == gcc -mno-cygwin -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURC E -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wnested-externs -Wformat-securi ty -Wformat-y2k -Winit-self -Wold-style-definition -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/ralch/qemu/qemu-0.15.0/target-i386 -D NEED_CPU_H -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -O4 -march=i686 -Wl,--nxcompat -Wl,--no-seh -Wl,--dynamicbase -Wl,--warn-common -m32 -g -Wl,-V -o qemu.exe arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o virtio.o virtio-blk.o virtio-balloon.o virtio-net.o virtio-serial-bus.o vhost _net.o rwhandler.o kvm-stub.o xen-stub.o ../cutils.o ../cache-utils.o ../qemu-malloc.o ../qemu-option.o ../module.o ../async.o ../nbd.o ../block.o ../aio.o ../a es.o ../qemu-config.o ../qemu-progress.o ../qemu-sockets.o ../block/raw.o ../block/cow.o ../block/qcow.o ../block/vdi.o ../block/vmdk.o ../block/cloop.o ../bloc k/dmg.o ../block/bochs.o ../block/vpc.o ../block/vvfat.o ../block/qcow2.o ../block/qcow2-refcount.o ../block/qcow2-cluster.o ../block/qcow2-snapshot.o ../block/ qcow2-cache.o ../block/qed.o ../block/qed-gencb.o ../block/qed-l2-cache.o ../block/qed-table.o ../block/qed-cluster.o ../block/qed-check.o ../block/parallels.o ../block/nbd.o ../block/blkdebug.o ../block/sheepdog.o ../block/blkverify.o ../block/raw-win32.o ../blockdev.o ../net.o ../net/queue.o ../net/checksum.o ../net/ util.o ../net/socket.o ../net/dump.o ../net/tap-win32.o ../net/slirp.o ../qint.o ../qstring.o ../qdict.o ../qlist.o ../qfloat.o ../qbool.o ../qjson.o ../json-le xer.o ../json-streamer.o ../json-parser.o ../qerror.o ../error.o ../readline.o ../console.o ../cursor.o ../qemu-error.o ../osdep.o ../oslib-win32.o ../qemu-thre ad-win32.o ../os-win32.o ../tcg-runtime.o ../host-utils.o ../irq.o ../ioport.o ../input.o ../i2c.o ../smbus.o ../smbus_eeprom.o ../eeprom93xx.o ../scsi-disk.o . ./cdrom.o ../scsi-generic.o ../scsi-bus.o ../usb.o ../usb-hub.o ../usb-stub.o ../usb-hid.o ../usb-msd.o ../usb-wacom.o ../usb-serial.o ../usb-net.o ../usb-bus.o ../usb-desc.o ../bt.o ../bt-host.o ../bt-vhci.o ../bt-l2cap.o ../bt-sdp.o ../bt-hci.o ../bt-hid.o ../usb-bt.o ../bt-hci-csr.o ../buffered_file.o ../migration.o ../migration-tcp.o ../qemu-char.o ../savevm.o ../msmouse.o ../ps2.o ../qdev.o ../qdev-properties.o ../block-migration.o ../iohandler.o ../pflib.o ../bitmap.o . ./bitops.o ../version.o ../audio/audio.o ../audio/noaudio.o ../audio/wavaudio.o ../audio/mixeng.o ../audio/sdlaudio.o ../audio/dsoundaudio.o ../audio/audio_win_ int.o ../audio/wavcapture.o ../ui/keymaps.o ../ui/sdl.o ../ui/sdl_zoom.o ../ui/x_keymap.o ../ui/vnc.o ../ui/d3des.o ../ui/vnc-enc-zlib.o ../ui/vnc-enc-hextile.o ../ui/vnc-enc-tight.o ../ui/vnc-palette.o ../ui/vnc-enc-zrle.o ../ui/vnc-jobs-sync.o ../iov.o ../acl.o ../notify.o ../event_notifier.o ../qemu-timer.o ../qemu- timer-common.o ../slirp/cksum.o ../slirp/if.o ../slirp/ip_icmp.o ../slirp/ip_input.o ../slirp/ip_output.o ../slirp/slirp.o ../slirp/mbuf.o ../slirp/misc.o ../sl irp/sbuf.o ../slirp/socket.o ../slirp/tcp_input.o ../slirp/tcp_output.o ../slirp/tcp_subr.o ../slirp/tcp_timer.o ../slirp/udp.o ../slirp/bootp.o ../slirp/tftp.o ../libdis/i386-dis.o exec.o translate-all.o cpu-exec.o translate.o tcg/tcg.o fpu/softfloat.o op_helper.o helper.o cpuid.o disas.o ../libhw64/vl.o ../libhw64/lo ader.o ../libhw64/virtio-console.o ../libhw64/virtio-pci.o ../libhw64/fw_cfg.o ../libhw64/pci.o ../libhw64/pci_bridge.o ../libhw64/msix.o ../libhw64/msi.o ../li bhw64/pci_host.o ../libhw64/pcie_host.o ../libhw64/ioh3420.o ../libhw64/xio3130_upstream.o ../libhw64/xio3130_downstream.o ../libhw64/watchdog.o ../libhw64/seri al.o ../libhw64/parallel.o ../libhw64/i8254.o ../libhw64/pcspk.o ../libhw64/pckbd.o ../libhw64/usb-uhci.o ../libhw64/usb-ohc
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/17/2011 06:30 PM, Bryce Lanham wrote: Ugh, I'm sorry about that. This is why I should test before using unfamiliar tools. Someone suggested using git format-patch/git send-email instead of a big patch. That's definitely preferred actually, but you should look at breaking this into multiple logical/self-contained series for easier review/testing. Apologies, Bryce Lanham On Wed, Aug 17, 2011 at 5:35 PM, Anthony Liguori wrote: On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add "byte", "word" and memory shift m68k: add "byte", "word" and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove to m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of "const void *" with "const uint8_t *" m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low m68k: add bkpt instruction m68k: correctly convert floatx80<->long double m68k: use expl() to compute exp_FP0() m68k: use ex
Re: [Qemu-devel] [PATCH] pci: add standard bridge device
On 08/17/2011 08:22 PM, Wen Congyang wrote:
At 08/17/2011 04:37 PM, Wen Congyang Write:
> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
>> This adds support for a standard pci to pci bridge,
>> enabling support for more than 32 PCI devices in the system.
>> To use, specify the device id as a 'bus' option.
>> Example:
>>-device pci-bridge,id=bridge1 \
>>-netdev user,id=u \
>>-device ne2k_pci,id=net2,bus=bridge1,netdev=u
>>
>> TODO: device hotplug support.
>
> I try this patch, and found that when I use pci bridge, qemu will core dump.
>
> Here is my command line:
> /usr/local2/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm -m 512 -name vm1
-drive
file=/var/lib/libvirt/images/vm1.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writethrough
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-vnc 0.0.0.0:1 -device pci-bridge,id=bridge1,bus=pci.0,addr=0x08.0x0 -netdev
user,id=u -device ne2k_pci,id=net2,bus=bridge1,netdev=u
>
> Here is the backtrace:
> Core was generated by `/usr/local2/bin/qemu-system-x86_64 -M pc-0.14
-enable-kvm -m 512 -name vm1 -dri'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00438e34 in memory_region_add_subregion_common (mr=0x0,
offset=49152, subregion=0x1de5d58) at /home/wency/source/qemu/memory.c:1152
> 1152 QTAILQ_FOREACH(other,&mr->subregions, subregions_link) {
> Missing separate debuginfos, use: debuginfo-install SDL-1.2.14-2.el6.x86_64
celt051-0.5.1.3-0.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64
cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-md5-2.1.23-8.el6.x86_64
cyrus-sasl-plain-2.1.23-8.el6.x86_64 db4-4.7.25-16.el6.x86_64
glib2-2.22.5-6.el6.x86_64 glibc-2.12-1.25.el6.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6.x86_64 libX11-1.3-2.el6.x86_64
libXau-1.0.5-1.el6.x86_64 libaio-0.3.107-10.el6.x86_64 libattr-2.4.44-4.el6.x86_64
libcom_err-1.41.12-7.el6.x86_64 libcurl-7.19.7-26.el6.x86_64
libgcrypt-1.4.5-5.el6.x86_64 libgpg-error-1.7-3.el6.x86_64
libidn-1.18-2.el6.x86_64 libjpeg-6b-46.el6.x86_64 libpng-1.2.44-1.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libssh2-1.2.2-7.el6.x86_64
libtasn1-2.3-3.el6.x86_64 libuuid-2.17.2-12.el6.x86_64 libxcb-1.5-1.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 nspr-4.8.7-1.el6.x86_64
nss-3.12.9-9.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64
nss-util-3.12.9-1.el6.x86_64 openld
ap
> -2.4.23-15.el6.x86_64 openssl-1.0.0-10.el6.x86_64
pixman-0.18.4-1.el6_0.1.x86_64 spice-server-0.8.0-1.el6.x86_64
zlib-1.2.3-25.el6.x86_64
> (gdb) bt
> #0 0x00438e34 in memory_region_add_subregion_common (mr=0x0,
offset=49152, subregion=0x1de5d58) at /home/wency/source/qemu/memory.c:1152
> #1 0x00439090 in memory_region_add_subregion_overlap (mr=0x0,
offset=49152, subregion=0x1de5d58, priority=1) at
/home/wency/source/qemu/memory.c:1194
> #2 0x005c55fe in pci_update_mappings (d=0x1de5900) at
/home/wency/source/qemu/hw/pci.c:1063
> #3 0x005c5982 in pci_default_write_config (d=0x1de5900, addr=4,
val=0, l=2) at /home/wency/source/qemu/hw/pci.c:1121
> #4 0x005cbfbf in pci_host_config_write_common (pci_dev=0x1de5900,
addr=4, limit=256, val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:54
> #5 0x005cc0d1 in pci_data_write (s=0x1da2b90, addr=2147549188,
val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:75
> #6 0x005cc2b1 in pci_host_data_write (handler=0x1da2b60, addr=3324,
val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:125
> #7 0x0042c884 in ioport_simple_writew (opaque=0x1da2b60, addr=3324,
value=1) at /home/wency/source/qemu/rwhandler.c:50
> #8 0x00499e85 in ioport_write (index=1, address=3324, data=1) at
ioport.c:81
> #9 0x0049a8e1 in cpu_outw (addr=3324, val=1) at ioport.c:280
> #10 0x00433c5d in kvm_handle_io (port=3324, data=0x7f0b30f86000,
direction=1, size=2, count=1) at /home/wency/source/qemu/kvm-all.c:837
> #11 0x004341c8 in kvm_cpu_exec (env=0x1b7fc70) at
/home/wency/source/qemu/kvm-all.c:976
> #12 0x0040da99 in cpu_exec_all () at
/home/wency/source/qemu/cpus.c:1102
> #13 0x005b60c4 in main_loop () at /home/wency/source/qemu/vl.c:1392
> #14 0x005baa49 in main (argc=20, argv=0x7a6b5a38,
envp=0x7a6b5ae0) at /home/wency/source/qemu/vl.c:3356
>
> If I do not attach any device on bus bridge1, qemu can work nice.
>
> Thanks
> Wen Congyang
>
The following patch can fix this problem, but I'm not sure whether it is right.
It's correct but insufficient, the filtering code (pci_bridge_filter)
needs to be updated to use the memory API.
Basically it gets simpler and correcter.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
[Qemu-devel] Serial port on virtual machines
Hi, I'm running VM on kvm-qemu hyper visor . I need to access the serail port on the VM , I tried the sample code to read/write com port but I get port error when ever I tried write something to the port(dev/ttyS0) . the same code work fine on the normal OS .. is it the same way as normal OS for accessing the serial port in vms ..?
Re: [Qemu-devel] [PATCH] qemu-img: print error codes when convert fails
On Wed, Aug 17, 2011 at 08:40:57PM +0200, Kevin Wolf wrote: > Am 17.08.2011 18:41, schrieb Stefan Hajnoczi: > > Signed-off-by: Stefan Hajnoczi > > Thanks, applied to the block branch. > > (But is it really helpful to include sector numbers in the error > message? Especially since we're not reading/writing single sectors) The intention is that it would show suspicious sectors numbers, e.g. ~2 GB or ~4 GB. In the best case it saves a round-trip on a bug report. In the worst case the sector number is a distraction :). Stefan
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 18 août 2011 à 13:12, "François Revol" a écrit : > Le -10/01/-28163 20:59, Laurent Vivier a écrit : > > Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : > >> On 08/17/2011 03:46 PM, Bryce Lanham wrote: > >>> These patches greatly expand Motorola 68k emulation within qemu, and are > >>> what I used as a basis for my > >>> Google Summer of Code project to add NeXT hardware support to QEMU. > >> > >> Please don't crap flood the list with a series of 100 patches. > >> > >> Split things into logical chunks such that a series can be reasonably > >> reviewed and applied. > > > > And I'm not sure this series of patches is ready for inclusion in qemu > > mainline as it should break existing m68k emulation... > > > > Bryce, you should only post your patches, refering to the repository on > > which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , > > master branch. > > > > Btw, are you planning on merging it back someday? > Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Regards, Laurent
Re: [Qemu-devel] USB port NULL pointer causes segv
Hi Gerd, thanks a lot. I just had a look on usb-linux.c where the "port" could be identified. for those that must use /proc/bus/usb it would be possible to allow the following: read in the "Port=" and check if it is on bus level 1, then you can identify at least your real root hardware port - hubs won't work, but for most users this would help at least for basic use cases. And: My system has the /sys/bus/usb structure, but NO udev enabled! That means the /dev/bus/usb structure is missing! Running the existing usb-linux.c code, I can never use USB, because /sys/... is selected but /dev/... is used which is not checked for existance! This causes delayed problems when you want to start using usb host devices. I moved the /proc/bus/usb checking in front of the /sys/ checking and it worked for me - maybe not useful for all but then the checkings for /sys/bus/usb should be extended on the /dev/bus/usb existance check. Additionally I have bigger problems with CD and DVD usb drives, they get detected and routed to the guest, but the "claimend" message comes up on the qemu monitor every 10-15 seconds and sometimes the linux usb driver resets the port - that causes a very slow detection in the guest and I never got it finished and I was not able to access the data on the CD. Most USB keys work, but some also had a similar issue. Everything tested with qemu-kvm-0.15.0 Best regards, Erik
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? François.
Re: [Qemu-devel] The reason behind block linking constraint?
>> If we link a TB with another TB from the different page, then the >> second TB may disappear when the memory mapping changes and the >> subsequent direct jump from the first TB will crash qemu. > > Perhaps the guest OS swap the second TB out of the guest memory, > is it what you mean? I meant TLB change by e.g. tlb_set_page. If you change single page mapping then all TBs in that page will be gone. This may be the result of e.g. a page swapping, or a task switch. If there's no direct link between TBs then softmmu will be used during the target TB search and softmmu will generate an appropriate guest exception. See cpu_exec -> tb_find_fast -> tb_find_slow -> get_page_addr_code. But if there is a direct link, then softmmu has no chance to do it. -- Thanks. -- Max
Re: [Qemu-devel] The reason behind block linking constraint?
> If we link a TB with another TB from the different page, then the > second TB may disappear when the memory mapping changes and the > subsequent direct jump from the first TB will crash qemu. Perhaps the guest OS swap the second TB out of the guest memory, is it what you mean? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] The reason behind block linking constraint?
> Hi, all
>
> I am trying to figure out why QEMU put some constraints on block
> linking (chaining). Take x86 as an example, there are two places
> put constraints on block linking, gen_goto_tb and cpu_exec.
>
> - gen_goto_tb (target-i386/translate.c) ---
> /* NOTE: we handle the case where the TB spans two pages here */
> if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) ||
> (pc & TARGET_PAGE_MASK) == ((s->pc - 1) & TARGET_PAGE_MASK)) {
> /* jump to same page: we can use a direct jump */
> tcg_gen_goto_tb(tb_num);
> gen_jmp_im(eip);
> tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
> } else {
> /* jump to another page: currently not optimized */
> gen_jmp_im(eip);
> gen_eob(s);
> }
> ---
>
> --- cpu_exec (cpu-exec.c) -
> /* see if we can patch the calling TB. When the TB
> spans two pages, we cannot safely do a direct
> jump. */
> if (next_tb != 0 && tb->page_addr[1] == -1) {
> tb_add_jump((TranslationBlock *)(next_tb & ~3), next_tb & 3, tb);
> }
> ---
>
> Is it just because we cannot optimize block linking which crosses page
> boundary, or there are some correctness/safety issues should be considered?
If we link a TB with another TB from the different page, then the
second TB may disappear when the memory mapping changes and the
subsequent direct jump from the first TB will crash qemu.
I guess that this usually does not happen in usermode, because the
guest would not modify executable code memory mapping. However I
suppose that this is also possible.
--
Thanks.
-- Max
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : > On 08/17/2011 03:46 PM, Bryce Lanham wrote: > > These patches greatly expand Motorola 68k emulation within qemu, and are > > what I used as a basis for my > > Google Summer of Code project to add NeXT hardware support to QEMU. > > Please don't crap flood the list with a series of 100 patches. > > Split things into logical chunks such that a series can be reasonably > reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Regards, Laurent > Regards, > > Anthony Liguori > > > > > Bryce Lanham > > > > Alexander Paramonov (1): > >linux-user: Signals processing is not thread-safe. > > > > Andreas Schwab (3): > >m68k: add cas > >m68k: define fcntl constants > >m68k: add DBcc instruction. > > > > Laurent Vivier (106): > >linux-user: add qemu-wrapper > >linux-user: define default cpu model in configure instead of > > linux-user/main.c > >linux-user: specify the cpu model during configure > >linux-user,m68k: display default cpu > >linux-user: define new environment variables > >linux-user: define a script to set binfmt using debian flavored tools > >linux-user: define default cpu model in configure instead of > > linux-user/main.c > >m68k: add tcg_gen_debug_insn_start() > >m68k: define m680x0 CPUs and features > >m68k: add missing accessing modes for some instructions. > >m68k: add Motorola 680x0 family common instructions. > >m68k: add Scc instruction with memory operand. > >m68k: add DBcc instruction. > >m68k: modify movem instruction to manage word > >m68k: add 64bit divide. > >m68k: add 32bit and 64bit multiply > >m68k: add word data size for suba/adda > >m68k: add fpu > >m68k: add "byte", "word" and memory shift > >m68k: add "byte", "word" and memory rotate. > >m68k: add bitfield_mem, bitfield_reg > >m68k: add variable offset/width to bitfield_reg/bitfield_mem > >m68k: add cas > >m68k: allow fpu to manage double data type. > >m68k: allow fpu to manage double data type with fmove to > >m68k: add FScc instruction > >m68k: add single data type to gen_ea > >m68k: add linkl instruction > >m68k: Add fmovecr > >m68k: correct typo on f64_to_i32() return type. > >m68k: improve CC_OP_LOGIC > >m68k: correct neg condition code flags computation > >Correct invalid use of "const void *" with "const uint8_t *" > >m68k: add EA support for negx > >m68k: add abcd instruction > >m68k: add sbcd instruction > >mm68k: add nbcd instruction > >m68k: set X flag according size of operand Set X flag correctly > > for addsub, arith_im, addsubq. > >m68k: on 0 bit shift, don't update X flag > >m68k: improve addx instructions Add (byte, word) opsize Add > > memory access > >m68k: improve subx,negx instructions Add (byte, word) opsize > > Add memory access (subx) > >m68k: improve asl/asr evaluate correclty the missing V flag > >m68k: use read_imm1() when it is possible > >m68k: correct shift side effect for roxrl and roxll > >m68k: asl/asr, clear C flag if shift count is 0 > >m68k: lsl/lsr, clear C flag if shift count is 0 > >m68k: correct divs.w and divu.w > >m68k: correct flags with negl > >m68k: for bitfield opcodes, correct operands corruption > >m68k: Correct bfclr in register case. > >m68k-linux-user: add '--enable-emulop' > >m68k: correctly compute divsl > >m68k: correctly compute divul > >m68k: add m68030 definition > >m68k: remove dead code > >m68k: remove useless file m68k-qreg.h > >m68k: FPU rework (draft) > >m68k: some FPU debugging macros > >m68k: more tests > >m68k: correct compute gen_bitfield_cc() > >m68k: add fgetexp > >m68k: add fscale > >m68k: correct addsubq > >m68k: add fetox and flogn > >m68k: initialize FRegs, define pickNaN() > >m68k: correct cmpa comparison datatype > >m68k: add flog10 > >m68k: add cmpm instruction > >m68k: add ftwotox instruction > >m68k: better fpu traces > >m68k: register source operand is always in extended size > >m68k: add facos instruction > >m68k: add ftan instruction > >m68k: add fsin instruction > >m68k: add fcos instruction > >m68k: correct fpcr update > >m68k: add fmod instruction > >m68k: flush flags before negx instruction. > >m68k: correct fmovemx FP registers order. > >m68k: add fatan instruction > >m68k: correct bfins instruction > >m68k: fcmp correctly compares infinity. > >m68k: allows bfins to manage correctly width = 32 > >m68k: add ftentox instruction > >m68k: corr
