[Qemu-devel] My OS hangup in KVM for some reasons, how can I debug?
Hi, I have an weird OS that I am trying to boot in KVM. however, it just hang in the middle, without a good reason. The same OS boots fine in physical machine, and this OS comes with no source code. There must be a bug somewhere in KVM, so I am wondering how people debug deal with such a case to find and fix bugs in KVM? Same thing like this happened before with some new OSes (such as Windows 8), and somebody always came up with a quick fix, so I am wondering what the magic is here. Thanks so much. Jun
Re: [Qemu-devel] My OS hangup in KVM for some reasons, how can I debug?
On Thu, May 8, 2014 at 4:28 PM, Jun Koi wrote: > Hi, > > I have an weird OS that I am trying to boot in KVM. however, it just hang > in the middle, without a good reason. > > The same OS boots fine in physical machine, and this OS comes with no > source code. > > There must be a bug somewhere in KVM, so I am wondering how people debug > deal with such a case to find and fix bugs in KVM? > > Same thing like this happened before with some new OSes (such as Windows > 8), and somebody always came up with a quick fix, so I am wondering what > the magic is here. > > Any help, please? thanks. Jun
Re: [Qemu-devel] My OS hangup in KVM for some reasons, how can I debug?
On Fri, May 9, 2014 at 11:24 AM, Jun Koi wrote: > > > > On Thu, May 8, 2014 at 4:28 PM, Jun Koi wrote: > >> Hi, >> >> I have an weird OS that I am trying to boot in KVM. however, it just hang >> in the middle, without a good reason. >> >> The same OS boots fine in physical machine, and this OS comes with no >> source code. >> >> There must be a bug somewhere in KVM, so I am wondering how people debug >> deal with such a case to find and fix bugs in KVM? >> >> Same thing like this happened before with some new OSes (such as Windows >> 8), and somebody always came up with a quick fix, so I am wondering what >> the magic is here. >> >> > Any help, please? Thanks, Jun
[Qemu-devel] dump-guest-memory command?
Hi, Anybody please help me on this dump-guest-memory command? How does the virtual memory map to the dumped file? For example, if x86 register RIP points to 0x12345, how does that map to the dump file? Meaning how can I find where this address 0x12345 in the dump? I tried, but couldnt find much documentation on this command. Thank you a lot, Jun
Re: [Qemu-devel] dump-guest-memory command?
On Fri, May 16, 2014 at 3:03 PM, Greg Kurz wrote: > On Fri, 16 May 2014 14:24:16 +0800 > Jun Koi wrote: > > Hi, > > > > Anybody please help me on this dump-guest-memory command? How does the > > virtual memory map to the dumped file? > > > > For example, if x86 register RIP points to 0x12345, how does that map to > > the dump file? Meaning how can I find where this address 0x12345 in the > > dump? > > > > I tried, but couldnt find much documentation on this command. > > > > Thank you a lot, > > Jun > > Hi Jun, > > The dump file is in ELF format and data is written in ELF notes. > Use readelf -a on the file and you'll get something like the > following at the end of the output: > > ... > > Notes at offset 0x01c8 with length 0x0328: > Owner Data size Description > CORE 0x0150 NT_PRSTATUS (prstatus structure) > QEMU 0x01b0 Unknown note type: (0x) > > The registers sit in the NT_PRSTATUS note (hence somewhere offset > 0x01c8 and 0x01c8+0x0150+0x14 (the latter is the ELF note > header size). Be aware that intel is little endian: if RIP is 0x00012345, > you need to look for '45 23 01 00' in the file. > > Thanks so much, but perhaps you misunderstood my question? What I want to know is how to map 0x12345 (virtual address) back to the dump file. For example, if 0x12345 was executing some filesystem code at the time I dumped the VM, then I can locate exactly that code in the dumpfile, thanks to the given RIP address (which is 0x12345 in this example) I hope I explain my idea clear enough this time? Thanks a lot, Jun
Re: [Qemu-devel] dump-guest-memory command?
On Fri, May 16, 2014 at 4:45 PM, Andreas Färber wrote: > Am 16.05.2014 10:40, schrieb Jun Koi: > > What I want > > to know is how to map 0x12345 (virtual address) back to the dump file. > > > > For example, if 0x12345 was executing some filesystem code at the time I > > dumped the VM, then I can locate exactly that code in the dumpfile, > > thanks to the given RIP address (which is 0x12345 in this example) > > > > I hope I explain my idea clear enough this time? > > Using dump-guest-memory sounds more complicated than needed. No, this is important, since i can have a whole image to do offline analysis. > You can > just use the monitor commands for disassembling that address What is this command? I try "help" but cannot find any. Before I remember we had "disas" or something like that, but I cannot find that again in latest Qemu code. > or the > built-in gdb stub (-s). > > Is this true that this only works for pure emulator, not for kvm-enable VM? Thanks, Jun
Re: [Qemu-devel] dump-guest-memory command?
On Fri, May 16, 2014 at 5:51 PM, Greg Kurz wrote: > On Fri, 16 May 2014 16:40:23 +0800 > Jun Koi wrote: > > On Fri, May 16, 2014 at 3:03 PM, Greg Kurz > wrote: > > > > > On Fri, 16 May 2014 14:24:16 +0800 > > > Jun Koi wrote: > > > > Hi, > > > > > > > > Anybody please help me on this dump-guest-memory command? How does > the > > > > virtual memory map to the dumped file? > > > > > > > > For example, if x86 register RIP points to 0x12345, how does that > map to > > > > the dump file? Meaning how can I find where this address 0x12345 in > the > > > > dump? > > > > > > > > I tried, but couldnt find much documentation on this command. > > > > > > > > Thank you a lot, > > > > Jun > > > > > > Hi Jun, > > > > > > The dump file is in ELF format and data is written in ELF notes. > > > Use readelf -a on the file and you'll get something like the > > > following at the end of the output: > > > > > > ... > > > > > > Notes at offset 0x01c8 with length 0x0328: > > > Owner Data size Description > > > CORE 0x0150 NT_PRSTATUS (prstatus > structure) > > > QEMU 0x01b0 Unknown note type: (0x) > > > > > > The registers sit in the NT_PRSTATUS note (hence somewhere offset > > > 0x01c8 and 0x01c8+0x0150+0x14 (the latter is the ELF note > > > header size). Be aware that intel is little endian: if RIP is > 0x00012345, > > > you need to look for '45 23 01 00' in the file. > > > > > > > > Thanks so much, but perhaps you misunderstood my question? What I want to > > know is how to map 0x12345 (virtual address) back to the dump file. > > > > Heh... sorry for that, morning isn't the best time to answer questions I > guess ;) > > > For example, if 0x12345 was executing some filesystem code at the time I > > dumped the VM, then I can locate exactly that code in the dumpfile, > thanks > > to the given RIP address (which is 0x12345 in this example) > > > > I hope I explain my idea clear enough this time? > > > > Yeah. Maybe the crash utility (http://people.redhat.com/anderson) can > help. > > but my VM is not Linux, so is this tool helpful? some questions: - is it true that dump-guest-memory just write down physical memory page, and does not consider the virtual-memory concept? - if above is true, how can i translate virtual address to physical address? (since only after that i can map my virtual address to its position in the dumpfile) thanks! Jun > > -- > Gregory Kurz kurzg...@fr.ibm.com > gk...@linux.vnet.ibm.com > Software Engineer @ IBM/Meiosys http://www.ibm.com > Tel +33 (0)562 165 496 > > "Anarchy is about taking complete responsibility for yourself." > Alan Moore. > >
Re: [Qemu-devel] dump-guest-memory command?
On Fri, May 16, 2014 at 7:30 PM, Laszlo Ersek wrote: > On 05/16/14 11:59, Jun Koi wrote: > > > - is it true that dump-guest-memory just write down physical memory > > page, and does not consider the virtual-memory concept? > > No, it isn't. > > Basically, "dump-guest-memory" supports two modes of operation, "paging > enabled" and "paging disabled". > > Many (most?) people dump for the "crash" utility, which is super smart, > and extra paging info is not needed. For "crash" we just dump the > guest-phys memory ranges the way the guest sees them, and that's it; > "crash" figures out everything from that. > > If you want to use "gdb" rather than "crash", or need the guest-virtual > addresses in the ELF vmcore for some other reason, then you should > invoke "dump-guest-memory" with paging enabled. > > Enter "help dump-guest-memory" at the qemu monitor prompt, and look for > the "-p" option. > so i suppose this works for all kind of OS in guest VM, not only Linux guest? thanks so much, Jun
Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism
On Thu, Jan 19, 2012 at 10:50 AM, Wen Congyang wrote: > Hi, all > > 'virsh dump' can not work when host pci device is used by guest. We have > discussed this issue here: > http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html > > We have determined to introduce a new command dump to dump memory. The core > file's format can be elf. do you pause the guest when the dump happen, or you can somehow let it continue to run? would be wonderful if you can do the latter, since dumping a guest memory can take a lot of time. thanks, Jun
Re: [Qemu-devel] Qemu as a library?
On Tue, Apr 10, 2012 at 8:09 AM, Mikael wrote: > Dear list, > > I understood that earlier on there was a "libqemu" library, using which an > ordinary userspace application could allocate a qemu virtual machine and get > it in a pointer/handle representation, run it as long as it wanted to, and > intercept any activity from or to it in detail. > > This is a *great* feature. > > Does it exist today? In case not, are there plans to introduce it now? > > > I suppose that it's QEMU and not KVM that should be the entry point for an > app for this purpose, as KVM only is a submodule of QEMU, for accelerating > part of its activity, correct? > > > The API functionality I'd want is: > * Open or close machine > * Monitor RAM consumption > * Execute machine for specified number of milliseconds, or until the > machine somehow marks it's sleeping (does Linux and other OS:es signal this > somehow?) > * Ability to feed machine with network and block device input. Callbacks > that receive network output and block device writes/responses from the > machine. I suppose this effectively means to implement an own, custom nic > and block device driver. > > Finally, if any callbacks could lead to that the machine execute procedure > returns (i.e. giving a behavior similar to Unix' select() and read() for > picking up new data on sockets), that would be incredibly good. (If having > several machines, there could be infinite recursion problems if events are > passed to a callback instead of as a return.) > most of these requirements can be done via libvirt, no? thanks, Jun
[Qemu-devel] Fail to share Samba directory with guest
hi, on qemu 1.0.1, i am trying to share a host directory with the Windows guest like below: qemu-system-i386 -enable-kvm -m 1000 -net nic,model=rtl8139 -net user,smb=/tmp img.winxp but in the guest, \\10.0.2.4 doesnt show me any shared directory. i already run Samba on the host (default configuration). did i miss something, or is it a bug?? thanks, Jun
Re: [Qemu-devel] Fail to share Samba directory with guest
On Tue, Feb 28, 2012 at 12:08 AM, Shu Ming wrote: > On 2012-2-27 17:21, Jun Koi wrote: >> >> hi, >> >> on qemu 1.0.1, i am trying to share a host directory with the Windows >> guest like below: >> >> qemu-system-i386 -enable-kvm -m 1000 -net nic,model=rtl8139 -net >> user,smb=/tmp img.winxp >> >> but in the guest, \\10.0.2.4 doesnt show me any shared directory. >> >> i already run Samba on the host (default configuration). >> >> did i miss something, or is it a bug?? > > > So 10.0.2.4 is your host IP with samba server? And what's the network the > guest belongs to? > according to some network schemes used by Qemu, 10.0.2.4 is the IP of the Samba server (DHCP: 10.0.2.2, DNS: 10.0.2.3, Samba: 10.0.2.4) http://en.wikibooks.org/wiki/QEMU/Networking i tried \\10.0.2.2, but dont see any share folder, either. thanks, Jun
Re: [Qemu-devel] Fail to share Samba directory with guest
On Tue, Feb 28, 2012 at 9:43 AM, Jun Koi wrote: > On Tue, Feb 28, 2012 at 12:08 AM, Shu Ming wrote: >> On 2012-2-27 17:21, Jun Koi wrote: >>> >>> hi, >>> >>> on qemu 1.0.1, i am trying to share a host directory with the Windows >>> guest like below: >>> >>> qemu-system-i386 -enable-kvm -m 1000 -net nic,model=rtl8139 -net >>> user,smb=/tmp img.winxp >>> >>> but in the guest, \\10.0.2.4 doesnt show me any shared directory. >>> >>> i already run Samba on the host (default configuration). >>> >>> did i miss something, or is it a bug?? >> >> >> So 10.0.2.4 is your host IP with samba server? And what's the network the >> guest belongs to? >> > > according to some network schemes used by Qemu, 10.0.2.4 is the IP of > the Samba server (DHCP: 10.0.2.2, DNS: 10.0.2.3, Samba: 10.0.2.4) > > http://en.wikibooks.org/wiki/QEMU/Networking > > i tried \\10.0.2.2, but dont see any share folder, either. i tested again, and again, but Samba sharing folder never work for me. meanwhile, my guest can see the folder shared configured in /etc/samba/smb.conf so this is definitely a bug. perhaps the Samba setting in net/slirp.c is wrong? the current configuration is like below. i am not experienced with Samba, so cannot figure out what is wrong. btw, it seems the Qemu unittest ignore this sharing folder testing? thanks, Ju // from net/slirp.c, function slirp_smb() fprintf(f, "[global]\n" "private dir=%s\n" "smb ports=0\n" "socket address=127.0.0.1\n" "pid directory=%s\n" "lock directory=%s\n" "log file=%s/log.smbd\n" "smb passwd file=%s/smbpasswd\n" "security = share\n" "[qemu]\n" "path=%s\n" "read only=no\n" "guest ok=yes\n", s->smb_dir, s->smb_dir, s->smb_dir, s->smb_dir, s->smb_dir, exported_dir );
[Qemu-devel] Windows 8 fails to boot
hi, anybody tested Qemu with the Windows 8 Consumer Preview? i tried the 32-bit ISO file with 1.0.1, with and without -enable-kvm, and Qemu reboots immediately after the first screen. that is no more than 10 seconds into the boot. thanks, Jun
Re: [Qemu-devel] Fail to share Samba directory with guest
On Thu, Mar 1, 2012 at 5:59 PM, Jan Kiszka wrote: > On 2012-03-01 05:21, Jun Koi wrote: >> On Tue, Feb 28, 2012 at 9:43 AM, Jun Koi wrote: >>> On Tue, Feb 28, 2012 at 12:08 AM, Shu Ming >>> wrote: >>>> On 2012-2-27 17:21, Jun Koi wrote: >>>>> >>>>> hi, >>>>> >>>>> on qemu 1.0.1, i am trying to share a host directory with the Windows >>>>> guest like below: >>>>> >>>>> qemu-system-i386 -enable-kvm -m 1000 -net nic,model=rtl8139 -net >>>>> user,smb=/tmp img.winxp >>>>> >>>>> but in the guest, \\10.0.2.4 doesnt show me any shared directory. >>>>> >>>>> i already run Samba on the host (default configuration). >>>>> >>>>> did i miss something, or is it a bug?? >>>> >>>> >>>> So 10.0.2.4 is your host IP with samba server? And what's the network the >>>> guest belongs to? >>>> >>> >>> according to some network schemes used by Qemu, 10.0.2.4 is the IP of >>> the Samba server (DHCP: 10.0.2.2, DNS: 10.0.2.3, Samba: 10.0.2.4) >>> >>> http://en.wikibooks.org/wiki/QEMU/Networking >>> >>> i tried \\10.0.2.2, but dont see any share folder, either. >> >> i tested again, and again, but Samba sharing folder never work for me. >> meanwhile, my guest can see the folder shared configured in >> /etc/samba/smb.conf >> >> so this is definitely a bug. perhaps the Samba setting in net/slirp.c is >> wrong? >> the current configuration is like below. i am not experienced with >> Samba, so cannot figure out what is wrong. >> >> btw, it seems the Qemu unittest ignore this sharing folder testing? >> >> thanks, >> Ju >> >> >> // from net/slirp.c, function slirp_smb() >> fprintf(f, >> "[global]\n" >> "private dir=%s\n" >> "smb ports=0\n" >> "socket address=127.0.0.1\n" >> "pid directory=%s\n" >> "lock directory=%s\n" >> "log file=%s/log.smbd\n" >> "smb passwd file=%s/smbpasswd\n" >> "security = share\n" >> "[qemu]\n" >> "path=%s\n" >> "read only=no\n" >> "guest ok=yes\n", >> s->smb_dir, >> s->smb_dir, >> s->smb_dir, >> s->smb_dir, >> s->smb_dir, >> exported_dir >> ); >> >> > > Works fine here with samba 3.5.7 (from OpenSuse 11.4) and a Linux guest. > What's your samba version? What's your guest? this is samba 3.4.7, on Ubuntu 10.4. and the guest is Windows XP, latest update. > > Also, you said you are running another samba on the host. What changes > if you stop it temporally? another samba? i dont understand. i mean i am running smbd on the host, and that is the only samba i run. if i stop that, how can the guest still see the samba folder? or do you mean that there is internal samba built-in inside Qemu, and Samba on the host must be off? that doesnt seem so, because ./configure always looks for the smbd at compilation process. thanks, Jun
Re: [Qemu-devel] Windows 8 fails to boot
On Thu, Mar 1, 2012 at 6:11 PM, Gleb Natapov wrote: > On Thu, Mar 01, 2012 at 11:08:17AM +0100, Alexander Graf wrote: >> >> On 01.03.2012, at 10:54, Gleb Natapov wrote: >> >> > On Thu, Mar 01, 2012 at 10:46:37AM +0100, Alexander Graf wrote: >> >> >> >> On 01.03.2012, at 09:00, Andreas Färber wrote: >> >> >> >>> Hi, >> >>> >> >>> Am 01.03.2012 05:24, schrieb Jun Koi: >> >>>> anybody tested Qemu with the Windows 8 Consumer Preview? >> >>>> >> >>>> i tried the 32-bit ISO file with 1.0.1, with and without -enable-kvm, >> >>>> and Qemu reboots immediately after the first screen. that is no more >> >>>> than 10 seconds into the boot. >> >>> >> >>> Alex has posted patches that supposedly make AHCI boot work. >> >> >> >> Yes, but TCG mode also failed on me. I only tried the x64 version though. >> >> >> >> >> > Why AHCI is needed? I was able to install it on ide (qemu-kvm -cpu >> > host). >> >> It's not needed, it's just faster. Andreas was trying to say that I did run >> Windows 8, because I had it working with AHCI. :) >> >> > Ah, got it. Well, I confirm that it runs, but installing it was the least > pleasant computer experience I ever had, so why bother? :) > ok, i can confirm that -cpu host work for me. so still we must fix the bug with default cpu option, right? thanks, Jun
Re: [Qemu-devel] Fail to share Samba directory with guest
On Thu, Mar 1, 2012 at 6:21 PM, Jan Kiszka wrote: > > > Jun Koi schrieb: > >>On Thu, Mar 1, 2012 at 5:59 PM, Jan Kiszka wrote: >>> On 2012-03-01 05:21, Jun Koi wrote: >>>> On Tue, Feb 28, 2012 at 9:43 AM, Jun Koi >>wrote: >>>>> On Tue, Feb 28, 2012 at 12:08 AM, Shu Ming >> wrote: >>>>>> On 2012-2-27 17:21, Jun Koi wrote: >>>>>>> >>>>>>> hi, >>>>>>> >>>>>>> on qemu 1.0.1, i am trying to share a host directory with the >>Windows >>>>>>> guest like below: >>>>>>> >>>>>>> qemu-system-i386 -enable-kvm -m 1000 -net nic,model=rtl8139 -net >>>>>>> user,smb=/tmp img.winxp >>>>>>> >>>>>>> but in the guest, \\10.0.2.4 doesnt show me any shared directory. >>>>>>> >>>>>>> i already run Samba on the host (default configuration). >>>>>>> >>>>>>> did i miss something, or is it a bug?? >>>>>> >>>>>> >>>>>> So 10.0.2.4 is your host IP with samba server? And what's the >>network the >>>>>> guest belongs to? >>>>>> >>>>> >>>>> according to some network schemes used by Qemu, 10.0.2.4 is the IP >>of >>>>> the Samba server (DHCP: 10.0.2.2, DNS: 10.0.2.3, Samba: 10.0.2.4) >>>>> >>>>> http://en.wikibooks.org/wiki/QEMU/Networking >>>>> >>>>> i tried \\10.0.2.2, but dont see any share folder, either. >>>> >>>> i tested again, and again, but Samba sharing folder never work for >>me. >>>> meanwhile, my guest can see the folder shared configured in >>/etc/samba/smb.conf >>>> >>>> so this is definitely a bug. perhaps the Samba setting in >>net/slirp.c is wrong? >>>> the current configuration is like below. i am not experienced with >>>> Samba, so cannot figure out what is wrong. >>>> >>>> btw, it seems the Qemu unittest ignore this sharing folder testing? >>>> >>>> thanks, >>>> Ju >>>> >>>> >>>> // from net/slirp.c, function slirp_smb() >>>> fprintf(f, >>>> "[global]\n" >>>> "private dir=%s\n" >>>> "smb ports=0\n" >>>> "socket address=127.0.0.1\n" >>>> "pid directory=%s\n" >>>> "lock directory=%s\n" >>>> "log file=%s/log.smbd\n" >>>> "smb passwd file=%s/smbpasswd\n" >>>> "security = share\n" >>>> "[qemu]\n" >>>> "path=%s\n" >>>> "read only=no\n" >>>> "guest ok=yes\n", >>>> s->smb_dir, >>>> s->smb_dir, >>>> s->smb_dir, >>>> s->smb_dir, >>>> s->smb_dir, >>>> exported_dir >>>> ); >>>> >>>> >>> >>> Works fine here with samba 3.5.7 (from OpenSuse 11.4) and a Linux >>guest. >>> What's your samba version? What's your guest? >> >>this is samba 3.4.7, on Ubuntu 10.4. and the guest is Windows XP, >>latest update. >> >>> >>> Also, you said you are running another samba on the host. What >>changes >>> if you stop it temporally? >> >>another samba? i dont understand. i mean i am running smbd on the >>host, and that is the only samba i run. >>if i stop that, how can the guest still see the samba folder? >> >>or do you mean that there is internal samba built-in inside Qemu, and >>Samba on the host must be off? >>that doesnt seem so, because ./configure always looks for the smbd at >>compilation process. > > Qemu forks off a dedicated smbd, you don't need to worry about it. In theory, > there should be no conflict with a smbd run "normally" on the host as well, I > just like to exclude this possibility. ok, i stopped smbd, but that doesnt help. do we need to have root privilege for this -smb option? because it seems smbd need to access to secrets.tdb file, which is for root only. thanks, Jun
[Qemu-devel] [patch] make trace_thread_create() use its function arg
this patch makes trace_thread_create() to use its function arg to initialize thread. the other choice is to make this a function to use void arg, but i prefer this way. Signed-off-by: Jun Koi diff --git a/trace/simple.c b/trace/simple.c index bbc9930..33ae486 100644 --- a/trace/simple.c +++ b/trace/simple.c @@ -363,7 +363,7 @@ static GThread *trace_thread_create(GThreadFunc fn) sigfillset(&set); pthread_sigmask(SIG_SETMASK, &set, &oldset); #endif -thread = g_thread_create(writeout_thread, NULL, FALSE, NULL); +thread = g_thread_create(fn, NULL, FALSE, NULL); #ifndef _WIN32 pthread_sigmask(SIG_SETMASK, &oldset, NULL); #endif
[Qemu-devel] [patch] correct tracing.txt
this patch corrects the configure's trace option in docs/tracing.txt Signed-off-by: Jun Koi diff --git a/docs/tracing.txt b/docs/tracing.txt index ea29f2c..7b11d15 100644 --- a/docs/tracing.txt +++ b/docs/tracing.txt @@ -9,7 +9,7 @@ for debugging, profiling, and observing execution. 1. Build with the 'simple' trace backend: -./configure --trace-backend=simple +./configure --enable-trace-backend=simple make 2. Create a file with the events you want to trace:
[Qemu-devel] pthread code crash??
hi, i am doing some experiments with Qemu. this is to add a new pthread into Qemu code, like below: ... pthread_t pt; pthread_attr_t thread_attr; pthread_attr_init(&thread_attr); pthread_attr_setdetachstate(&thread_attr, PTHREAD_CREATE_DETACHED); pthread_create(&pt, &thread_attr, my_handler, NULL); .. the problem is that this simple code crashes Qemu 0.14.0 immediately at the pthread_create() function. and strangely, i dont have this problem with Qemu 0.12.4: the exactly same code works flawlessly. any hint on what is the root of the problem, and how to fix that? thanks a lot, Jun
Re: [Qemu-devel] [PATCH 1/2] seabios: Add Local APIC NMI Structure to ACPI MADT
2011/10/28 Kenji Kaneshige : > Avi, Jan, > > Could you comment on these patches? > > Inject-NMI doesn't work on Windows guest without these patches. sorry but i am really curious here: why Windows still works well even if it desnt see the inject-NMI? or there are still invisible side-effects that we are not awere of??? thanks, Jun
[Qemu-devel] [patch] explicitly initialize tcg_cpu_thread
This patch explicitly initializes tcg_cpu_thread to NULL in cpus.c (One code patch in qemu_tcg_init_vcpu() relies on the value of tcg_cpu_thread to create env->thread and so on ) Signed-off-by: Jun Koi diff --git a/cpus.c b/cpus.c index f768683..47feb58 100644 --- a/cpus.c +++ b/cpus.c @@ -606,7 +606,7 @@ static bool iothread_requesting_mutex; static QemuThread io_thread; -static QemuThread *tcg_cpu_thread; +static QemuThread *tcg_cpu_thread = NULL; static QemuCond *tcg_halt_cond; /* cpu creation */
[Qemu-devel] [patch] remove unused function arg in qemu_iohandler_poll() and qemu_iohandler_fill()
This patch removes unused function argument xfds from
qemu_iohandler_poll() and qemu_iohandler_fill()
Signed-off-by: Jun Koi
diff --git a/iohandler.c b/iohandler.c
index 5640d49..9963790 100644
--- a/iohandler.c
+++ b/iohandler.c
@@ -89,7 +89,7 @@ int qemu_set_fd_handler(int fd,
return qemu_set_fd_handler2(fd, NULL, fd_read, fd_write, opaque);
}
-void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set
*writefds, fd_set *xfds)
+void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds)
{
IOHandlerRecord *ioh;
@@ -111,7 +111,7 @@ void qemu_iohandler_fill(int *pnfds, fd_set
*readfds, fd_set *writefds, fd_set *
}
}
-void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set
*xfds, int ret)
+void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, int ret)
{
if (ret > 0) {
IOHandlerRecord *pioh, *ioh;
diff --git a/main-loop.c b/main-loop.c
index 60e9748..7cbb0b0 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -446,7 +446,7 @@ int main_loop_wait(int nonblocking)
#ifdef CONFIG_SLIRP
slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
#endif
-qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
+qemu_iohandler_fill(&nfds, &rfds, &wfds);
glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
if (timeout > 0) {
@@ -460,7 +460,7 @@ int main_loop_wait(int nonblocking)
}
glib_select_poll(&rfds, &wfds, &xfds, (ret < 0));
-qemu_iohandler_poll(&rfds, &wfds, &xfds, ret);
+qemu_iohandler_poll(&rfds, &wfds, ret);
#ifdef CONFIG_SLIRP
slirp_select_poll(&rfds, &wfds, &xfds, (ret < 0));
#endif
diff --git a/main-loop.h b/main-loop.h
index 8a716b1..f753c6a 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -341,8 +341,8 @@ void qemu_mutex_unlock_iothread(void);
/* internal interfaces */
-void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set
*writefds, fd_set *xfds);
-void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set
*xfds, int rc);
+void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds);
+void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, int rc);
void qemu_bh_schedule_idle(QEMUBH *bh);
int qemu_bh_poll(void);
(END)
Re: [Qemu-devel] [patch] explicitly initialize tcg_cpu_thread
On Tue, Nov 1, 2011 at 3:06 PM, Pavel Borzenkov wrote: > On Tue, Nov 1, 2011 at 7:35 AM, Jun Koi wrote: >> This patch explicitly initializes tcg_cpu_thread to NULL in cpus.c >> (One code patch in qemu_tcg_init_vcpu() relies on the value of >> tcg_cpu_thread to create env->thread and so on ) >> >> Signed-off-by: Jun Koi > > You don't need to explicitly initialize objects with static storage > duration. They are initialized to NULL/0 implicitly. > This is guaranteed by the C standard. that is good to know, but i think that is better safe than sorry. what if we compile Qemu with a compiler that doesnt follow the standard? also, i remember that we always initialize static vars? or am i wrong? thanks, Jun >> diff --git a/cpus.c b/cpus.c >> index f768683..47feb58 100644 >> --- a/cpus.c >> +++ b/cpus.c >> @@ -606,7 +606,7 @@ static bool iothread_requesting_mutex; >> >> static QemuThread io_thread; >> >> -static QemuThread *tcg_cpu_thread; >> +static QemuThread *tcg_cpu_thread = NULL; >> static QemuCond *tcg_halt_cond; >> >> /* cpu creation */ >> >> >
[Qemu-devel] [patch] remove dead code, and make cpu_exec_all() static
This patch removes dead code (kvm related) in cpu_exec_all(), and
makes that static (since nobody uses it)
Signed-off-by: Jun Koi
diff --git a/cpus.c b/cpus.c
index f768683..77282a1 100644
--- a/cpus.c
+++ b/cpus.c
@@ -85,6 +85,8 @@ typedef struct TimersState {
TimersState timers_state;
+static bool cpu_exec_all(void);
+
/* Return the virtual CPU time, based on the instruction counter. */
int64_t cpu_get_icount(void)
{
@@ -1016,7 +1018,7 @@ static int tcg_cpu_exec(CPUState *env)
return ret;
}
-bool cpu_exec_all(void)
+static bool cpu_exec_all(void)
{
int r;
@@ -1033,12 +1035,7 @@ bool cpu_exec_all(void)
(env->singlestep_enabled & SSTEP_NOTIMER) == 0);
if (cpu_can_run(env)) {
-if (kvm_enabled()) {
-r = kvm_cpu_exec(env);
-qemu_kvm_eat_signals(env);
-} else {
-r = tcg_cpu_exec(env);
-}
+r = tcg_cpu_exec(env);
if (r == EXCP_DEBUG) {
cpu_handle_guest_debug(env);
break;
diff --git a/cpus.h b/cpus.h
index 3525375..4ea2fe2 100644
--- a/cpus.h
+++ b/cpus.h
@@ -14,7 +14,6 @@ void cpu_synchronize_all_post_init(void);
/* vl.c */
extern int smp_cores;
extern int smp_threads;
-bool cpu_exec_all(void);
void set_numa_modes(void);
void set_cpu_log(const char *optarg);
void set_cpu_log_filename(const char *optarg);
Re: [Qemu-devel] [PATCH] Simplify cpu_exec_all to tcg_exec_all
i have sent a patch, which duplicated the function of this patch.
this one was not approved yet??
thanks,
Jun
On Mon, Sep 26, 2011 at 3:40 PM, Jan Kiszka wrote:
> After the removal of the non-threaded mode cpu_exec_all is now only used
> by TCG. Refactor it accordingly, also dropping its unused return value.
>
> Signed-off-by: Jan Kiszka
> ---
> cpus.c | 14 +-
> cpus.h | 1 -
> 2 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/cpus.c b/cpus.c
> index 8978779..f983033 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -664,6 +664,8 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
> return NULL;
> }
>
> +static void tcg_exec_all(void);
> +
> static void *qemu_tcg_cpu_thread_fn(void *arg)
> {
> CPUState *env = arg;
> @@ -685,7 +687,7 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
> }
>
> while (1) {
> - cpu_exec_all();
> + tcg_exec_all();
> if (use_icount && qemu_next_icount_deadline() <= 0) {
> qemu_notify_event();
> }
> @@ -925,7 +927,7 @@ static int tcg_cpu_exec(CPUState *env)
> return ret;
> }
>
> -bool cpu_exec_all(void)
> +static void tcg_exec_all(void)
> {
> int r;
>
> @@ -942,12 +944,7 @@ bool cpu_exec_all(void)
> (env->singlestep_enabled & SSTEP_NOTIMER) == 0);
>
> if (cpu_can_run(env)) {
> - if (kvm_enabled()) {
> - r = kvm_cpu_exec(env);
> - qemu_kvm_eat_signals(env);
> - } else {
> - r = tcg_cpu_exec(env);
> - }
> + r = tcg_cpu_exec(env);
> if (r == EXCP_DEBUG) {
> cpu_handle_guest_debug(env);
> break;
> @@ -957,7 +954,6 @@ bool cpu_exec_all(void)
> }
> }
> exit_request = 0;
> - return !all_cpu_threads_idle();
> }
>
> void set_numa_modes(void)
> diff --git a/cpus.h b/cpus.h
> index 5885885..bb91684 100644
> --- a/cpus.h
> +++ b/cpus.h
> @@ -15,7 +15,6 @@ void cpu_synchronize_all_post_init(void);
> /* vl.c */
> extern int smp_cores;
> extern int smp_threads;
> -bool cpu_exec_all(void);
> void set_numa_modes(void);
> void set_cpu_log(const char *optarg);
> void set_cpu_log_filename(const char *optarg);
> --
> 1.7.3.4
>
>
[Qemu-devel] cpu_x86() ?
hi, the way cpu_exec() is defined is really confused to me. in cpu-exec.c, we define cpu_exec() function. however, each architecture seems to redefine cpu_exec(), like we have in target-i386/cpu.h #define cpu_exec cpu_x86_exec so which cpu_exec() is executed in case of tcg/x86? also, i cannot find the definition of cpu_x86_exec() anywhere. somebody please help? thanks, Jun
Re: [Qemu-devel] cpu_x86() ?
On Tue, Nov 1, 2011 at 6:58 PM, Max Filippov wrote: >> the way cpu_exec() is defined is really confused to me. >> >> in cpu-exec.c, we define cpu_exec() function. >> >> however, each architecture seems to redefine cpu_exec(), like we have >> in target-i386/cpu.h >> >> #define cpu_exec cpu_x86_exec >> >> so which cpu_exec() is executed in case of tcg/x86? >> >> also, i cannot find the definition of cpu_x86_exec() anywhere. > > cpu_exec definition in cpu-exec.c takes place after #include "cpu.h" > which contains #define cpu_exec whatever. > In case of x86 cpu_x86_exec is actually defined by the cpu-exec.c. > ok, so which means cpu_exec is redefined accordingly to each architecture. why do we need to do this weird thing? as there is no namespace collision it seems between architectures, why dont we just let cpu_exec() be cpu_exec()? is this a trick? i cannot figure out why. thanks, Jun
[Qemu-devel] [patch] add auto-generated files into .gitignore
This patch adds some auto-generated files into .gitignore Signed-off-by: Jun Koi diff --git a/.gitignore b/.gitignore index 6d2acab..62679d8 100644 --- a/.gitignore +++ b/.gitignore @@ -72,3 +72,9 @@ cscope.* tags TAGS *~ +qapi-types.c +qapi-types.h +qapi-visit.c +qapi-visit.h +qmp-commands.h +qmp-marshal.c
Re: [Qemu-devel] [patch] remove unused function arg in qemu_iohandler_poll() and qemu_iohandler_fill()
On Tue, Nov 1, 2011 at 11:05 PM, Anthony Liguori wrote:
> On 11/01/2011 12:11 AM, Jun Koi wrote:
>>
>> This patch removes unused function argument xfds from
>> qemu_iohandler_poll() and qemu_iohandler_fill()
>>
>> Signed-off-by: Jun Koi
>>
>
> Your mailer is munging the patch. Please use git-send-email to avoid this.
>
pls find the patch in attachment.
thanks,
Jun
Signed-off-by: Jun Koi
$ diffstat patch-remove-xfds.diff
iohandler.c |4 ++--
main-loop.c |4 ++--
main-loop.h |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/iohandler.c b/iohandler.c
index 5640d49..9963790 100644
--- a/iohandler.c
+++ b/iohandler.c
@@ -89,7 +89,7 @@ int qemu_set_fd_handler(int fd,
return qemu_set_fd_handler2(fd, NULL, fd_read, fd_write, opaque);
}
-void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds, fd_set *xfds)
+void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds)
{
IOHandlerRecord *ioh;
@@ -111,7 +111,7 @@ void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds, fd_set *
}
}
-void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int ret)
+void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, int ret)
{
if (ret > 0) {
IOHandlerRecord *pioh, *ioh;
diff --git a/main-loop.c b/main-loop.c
index 60e9748..7cbb0b0 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -446,7 +446,7 @@ int main_loop_wait(int nonblocking)
#ifdef CONFIG_SLIRP
slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
#endif
-qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
+qemu_iohandler_fill(&nfds, &rfds, &wfds);
glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
if (timeout > 0) {
@@ -460,7 +460,7 @@ int main_loop_wait(int nonblocking)
}
glib_select_poll(&rfds, &wfds, &xfds, (ret < 0));
-qemu_iohandler_poll(&rfds, &wfds, &xfds, ret);
+qemu_iohandler_poll(&rfds, &wfds, ret);
#ifdef CONFIG_SLIRP
slirp_select_poll(&rfds, &wfds, &xfds, (ret < 0));
#endif
diff --git a/main-loop.h b/main-loop.h
index 8a716b1..f753c6a 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -341,8 +341,8 @@ void qemu_mutex_unlock_iothread(void);
/* internal interfaces */
-void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds, fd_set *xfds);
-void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc);
+void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds);
+void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, int rc);
void qemu_bh_schedule_idle(QEMUBH *bh);
int qemu_bh_poll(void);
Re: [Qemu-devel] [patch] remove unused function arg in qemu_iohandler_poll() and qemu_iohandler_fill()
On Wed, Nov 2, 2011 at 3:40 PM, Paolo Bonzini wrote: > On 11/01/2011 06:11 AM, Jun Koi wrote: >> >> This patch removes unused function argument xfds from >> qemu_iohandler_poll() and qemu_iohandler_fill() > > I don't think the patch us particularly useful; the arguments are designed > to match select. The fact that iohandlers do not support xfds (unlike e.g. > glib and slirp poll/fill) is not important to the _client_ of this code. > do you mean the code looks "more beautiful" if we just leave xfds there? is that a good reason? this causes a little bit on performance, because we have to push an unused argument into the stack every time we call those funcs. while the impact is minimal, do we really need to suffer that for the beauty of code? thanks, J
[Qemu-devel] how to delete a savevm in image?
hi, during the run of my VM, i used "savevm" to save the VM status down. now how can i delete that? i checked qemu-img, and it doesnt seem to have any option to delete the savevm in the VM image. thanks, Jun
[Qemu-devel] Do not compile hw/ for SOFTMMU
Currently hw/ is compiled in for SOFTMMU setup, but actually it is always compiled no matter what. This patch removes the related line in Makefile.objs. Signed-off-by: Jun Koi diff --git a/Makefile.objs b/Makefile.objs index 4a62913..15d75be 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -64,7 +64,6 @@ common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o common-obj-$(CONFIG_SPICE) += spice-qemu-char.o common-obj-y += audio/ -common-obj-y += hw/ common-obj-y += ui/ common-obj-y += bt-host.o bt-vhci.o
[Qemu-devel] Running KVM inside pure Qemu?
Hi, On Qemu 2.0, what commandline options should I use to run KVM (nested VM) inside pure emulator Qemu? Any guideline available onthis would be very helpful. Thanks so much, Jun
Re: [Qemu-devel] Running KVM inside pure Qemu?
On Sat, Apr 26, 2014 at 4:50 PM, Paolo Bonzini wrote: > Il 25/04/2014 20:13, Shehbaz Jaffer ha scritto: > > Hi, >> >> Are you talking about running KVM(hardware virtualization) enabled >> support on top of a Linux host running on only QEMU (software >> virtualization)? I doubt if this is nesting is possible. To be sure, >> you can check for the following flags on your host: >> cat /proc/cpuinfo | grep -e svm -e vmx >> > > You can run AMD KVM inside QEMU. The default CPU model "qemu64" provides > this capability. > oh great! do we suppport EPT, VCMS shadow yet? thanks. Jun > > Paolo > > > If even one of the two flags is enabled on the host, you can use the >> KVM on top of Host running on QEMU using --enable-kvm option. >> >> Otherwise you will get errors like : kvm-disbled while trying to run >> KVM on top of host running on QEMU. >> > > >
Re: [Qemu-devel] Running KVM inside pure Qemu?
On Sun, Apr 27, 2014 at 3:05 PM, Paolo Bonzini wrote: > Il 27/04/2014 04:33, Jun Koi ha scritto: > >> >> >> >> On Sat, Apr 26, 2014 at 4:50 PM, Paolo Bonzini > <mailto:pbonz...@redhat.com>> wrote: >> >> Il 25/04/2014 20:13, Shehbaz Jaffer ha scritto: >> >> Hi, >> >> Are you talking about running KVM(hardware virtualization) enabled >> support on top of a Linux host running on only QEMU (software >> virtualization)? I doubt if this is nesting is possible. To be >> sure, >> you can check for the following flags on your host: >> cat /proc/cpuinfo | grep -e svm -e vmx >> >> >> You can run AMD KVM inside QEMU. The default CPU model "qemu64" >> provides this capability. >> >> >> oh great! do we suppport EPT, VCMS shadow yet? >> > > No nested page tables, and VMCS shadow is only supported by Intel > processors not AMD. > Oh, I always think that without EPT, it would not be possible to have nested VMX. Am I wrong here? Thanks, Jun
[Qemu-devel] where is the definition of cpu_ldub_code() for Softmmu mode?
Hi, I am trying to find the definition of cpu_ldub_code() in Softmmu mode. However, the only thing I can find is like this in include/exec/cpu_ldst.h: #define cpu_ldub_code(env1, p) ldub_raw(p) Unfortunately, this is only for Usermode (CONFIG_USER_ONLY), so still I have no idea where cpu_ldub_code() is defined for Softmmu mode. Perhaps this is hidden after some tricky macros? Thank you, Jun
Re: [Qemu-devel] where is the definition of cpu_ldub_code() for Softmmu mode?
On Mon, May 18, 2015 at 6:20 PM, Peter Maydell wrote: > On 18 May 2015 at 10:55, Jun Koi wrote: > > Hi, > > > > I am trying to find the definition of cpu_ldub_code() in Softmmu mode. > > However, the only thing I can find is like this in > include/exec/cpu_ldst.h: > > > > #define cpu_ldub_code(env1, p) ldub_raw(p) > > Your QEMU tree is out of date -- this macro was removed in > commit 9220fe54c6. > Yes, I am using 2.2.0 version. > > > Unfortunately, this is only for Usermode (CONFIG_USER_ONLY), so > > still I have no idea where cpu_ldub_code() is defined for Softmmu mode. > > In cpu_ldst.h we #define MEMSUFFIX _code and then include > "exec/cpu_ldst_template.h" multiple times to define the > accessor functions for the various widths. (For the usermode > version we include "exec/cpu_ldst_useronly_template.h", for > similar effect.) > > Thank you a lot! Jun
[Qemu-devel] How Qemu timer interrupts code emulation?
Hi, I am wondering how the timer interrupt works in softmmu TCG mode (on X86)? In general, we would have timer & code execution run in parallel, then once in a while, the timer would interrupt the code execution to switch it out to execute the timer interrupt. I looked at the code, but still confused on how the timer inform the code emulation, and how the code emulation get notified on interrupt event. Any pointer, please? (I am looking at X86 code) Thanks so much, Jun
[Qemu-devel] where is crc32() function?
Hi, In target-arm/helper-a64.c, there is a call to crc32(). I searched everywhere in the source, but still cannot find this function anywhere (only crc32c() is available) Any hint where this function is, please? Thanks.
Re: [Qemu-devel] where is crc32() function?
On Fri, May 29, 2015 at 11:43 PM, Peter Maydell wrote: > On 29 May 2015 at 17:41, Jun Koi wrote: > > In target-arm/helper-a64.c, there is a call to crc32(). > > > > I searched everywhere in the source, but still cannot find this function > > anywhere (only crc32c() is available) > > > > Any hint where this function is, please? > > helper-a64.c has the hint you are looking for at the top: > #include /* For crc32 */ > > Thanks a lot, Peter!
[Qemu-devel] Qemu uses C++ ??
Hi, I always thought that Qemu never has C++ code inside, but I am surprise to see this when Aarch64 emulator is linked, as following (excerpt) c++ -I/usr/include/pixman-1 -I/home/me/projects/qemu-2.3.0/dtc/libfdt -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I../linux-headers -I.. -I/home/me/projects/qemu-2.3.0/target-arm -DNEED_CPU_H -I/home/me/projects/qemu-2.3.0/include -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -o qemu-system-aarch64 exec.o translate-all.o cpu-exec.o ... A question: is there any reason to use C++ for linker here? Why does C linker not work? Thanks.
Re: [Qemu-devel] Qemu uses C++ ??
On Sat, May 30, 2015 at 1:09 AM, Peter Maydell wrote: > On 29 May 2015 at 19:01, Jun Koi wrote: > > I always thought that Qemu never has C++ code inside, but I am surprise > to > > see this when Aarch64 emulator is linked, as following (excerpt) > > The AArch64 disassembler is written in C++ (this is a third > party bit of code which we include in QEMU). C++ is optional > as a build dependency, though -- if there's no C++ compiler > available configure will disable the AArch64 disassembler. > Oh, exactly which code is the AArch64 disassembler? I looked at target-arm/*.c, but did not seem to find C++ code there. I must missed it ... Thanks. > > c++ -I/usr/include/pixman-1 -I/home/me/projects/qemu-2.3.0/dtc/libfdt > > -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > > -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings > > -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels > > -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security > > -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration > > -Wold-style-definition -Wtype-limits -fstack-protector-all > > -I../linux-headers -I.. -I/home/me/projects/qemu-2.3.0/target-arm > > -DNEED_CPU_H -I/home/me/projects/qemu-2.3.0/include -O2 -U_FORTIFY_SOURCE > > -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -Wl,--warn-common > > -Wl,-z,relro -Wl,-z,now -pie -m64 -g -o qemu-system-aarch64 exec.o > > translate-all.o cpu-exec.o ... > > > > > > A question: is there any reason to use C++ for linker here? Why does C > > linker not work? > > If we are linking any C++-derived object then we must use the > C++ linker, otherwise the link might fail or not pull in the > right bits of the C++ runtime. (It's harmless to use the C++ > linker for a C-only link.) > > -- PMM >
[Qemu-devel] Nested KVM is weird?
Hi, I managed to run VMWare ESXi hypervisor (type 1) inside KVM. From there, I can install & run nested guest Linux on this ESXi. However, I find this very strange: I put some printk() at the top of function nested_vmx_run(), which should run to handle nested KVM. Below is the definition of nested_vmx_run() in vmx.c /* * nested_vmx_run() handles a nested entry, i.e., a VMLAUNCH or VMRESUME on L1 * for running an L2 nested guest. */ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool launch) What I cannot understand is that this function is never hit, because my printk() never prints out anything to dmesg output. So this means ESXi never uses VMResume/VMLaunch? How is this possible, because it uses VMX for its implementation? I am banging my head into keyboard to figure out why. Any idea, please? Thanks, Jun
Re: [Qemu-devel] Nested KVM is weird?
On Sun, Jun 1, 2014 at 5:59 PM, Muli Ben-Yehuda wrote: > On Sun, Jun 01, 2014 at 05:54:25PM +0700, Jun Koi wrote: > > > So this means ESXi never uses VMResume/VMLaunch? How is this > > possible, because it uses VMX for its implementation? > > ESXi will fall back to binary translation if it decides that it cannot > use VMX for some reason. Look at the L2's log file inside ESXi and you > will likely find some errors related to running nested, MSRs KVM does > not emulate properly, or something else that causes ESXi to use binary > translation for its L2. > now i noticed in dmesg output, there is one message with content: " VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround" (1) do you think this VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL is the reason why ESXi falls back to binary translation? (3) how hard it is to fix this issue, so we have complete support for ESXi? thanks, Jun
[Qemu-devel] Resource leaking in gen_intermediate_code_internal ?
Hello, In function gen_intermediate_code_internal() of target-i386/translate.c, we have this code: cpu_T[0] = tcg_temp_new(); cpu_T[1] = tcg_temp_new(); cpu_A0 = tcg_temp_new(); I cannot see anywhere cpu_T & cpu_A0 are freed, so each time this function is called, it allocates new variables without freeing old variables. So we have resource leaking here? Thanks.
[Qemu-devel] Trace memory access in guest VM?
Hello, I am trying to monitor all the memory accesses inside the guest VM running on Qemu. I know this is heavy, but this is only the first step of my experiments. To do this, I look at the sample trace in "trace-events" and wondering: is it possible to trace all the memory access (read/write) in the guest VM with available "memory_region_ops_read" & "memory_region_ops_write" events? I am looking very close to the docs, but there is no information on these events. If these events are not useful for my task, any suggestions on where to put the trace? Thanks a lot, Jun
[Qemu-devel] Monitoring write to memory
Hello,
I am trying to monitor all the memory writing events inside Qemu by
instrumenting tcg_gen_qemu_st8, tcg_gen_qemu_st16, tcg_gen_qemu_st32,
tcg_gen_qemu_st64,
as followings:
// in tcg-op.h
void helper_checkmem(int64_t data, int64_t address); // this is declared
elsewhere
static inline void tcg_gen_qemu_st8(struct uc_struct *uc, TCGv arg, TCGv
addr, int mem_index)
{
#if TARGET_LONG_BITS == 32
TCGArg args[2] = { GET_TCGV_I32(arg), GET_TCGV_I32(addr) };
#else
TCGArg args[2] = { GET_TCGV_I64(arg), GET_TCGV_I64(addr) };
#endif
tcg_gen_callN(&tcg_ctx, helper_checkmem, dh_retvar_void, 2, args);
tcg_gen_qemu_st_tl(uc, arg, addr, mem_index, MO_UB);
}
However, when I compile, helper_checkmem() is never called at runtime when
memory is accessed.
What is wrong with my code?
Another problem is that: how can I cast i32 to i64? I wanted to do:
TCGArg args[2] = { GET_TCGV_I32(arg), GET_TCGV_I64(addr) };
but in 32bit mode, addr is TCGv, so GET_TCGV_I64(addr) gets error report.
Thank you.
[Qemu-devel] Parameter of helper_le_ld_name ?
Hi, In softmmu_template.h, we have this function: WORD_TYPE helper_le_ld_name(CPUArchState *env, target_ulong addr, int mmu_idx, uintptr_t retaddr) Anybody please explains what is this "retaddr" parameter, and how does that work? Thanks!
[Qemu-devel] How to break cpu_tb_exec()?
Hello, I am looking at how the main thread interrupts TCG thread. Inside cpu-exec.c, in function cpu_tb_exec(), I can see that it executes one TB, and when this is over, it can check for events from other threads (like main thread). This is the reason why TCG thread can be interrupted. Is my understanding correct? If this is true, then what if this TB is running infinitely, and do not return, or it is in a very long loop? In this case, TCG thread cannot be interrupted? Thank you.
Re: [Qemu-devel] How to break cpu_tb_exec()?
On Sat, Jul 4, 2015 at 1:06 AM, Peter Maydell wrote: > On 3 July 2015 at 18:02, Jun Koi wrote: > > I am looking at how the main thread interrupts TCG thread. Inside > > cpu-exec.c, in function cpu_tb_exec(), I can see that it executes one TB, > > and when this is over, it can check for events from other threads (like > main > > thread). This is the reason why TCG thread can be interrupted. > > > > Is my understanding correct? > > > > If this is true, then what if this TB is running infinitely, and do not > > return, or it is in a very long loop? In this case, TCG thread cannot be > > interrupted? > > Every TB starts with a little bit of generated code that checks > the 'tcg_exit_req' flag in the CPUState for the CPU (see the > gen_tb_start() function). If some other part of QEMU wants the > CPU to stop running guest code and return to the top level loop, > it calls cpu_exit() which sets this flag. > But this does not answer my question yet: if we the flag is only enable when TB already enters the "long loop", then nothing can break this TB execution? Thanks.
Re: [Qemu-devel] How to break cpu_tb_exec()?
On Sat, Jul 4, 2015 at 1:12 AM, Peter Maydell wrote: > On 3 July 2015 at 18:10, Jun Koi wrote: > > On Sat, Jul 4, 2015 at 1:06 AM, Peter Maydell > > wrote: > >> On 3 July 2015 at 18:02, Jun Koi wrote: > >> > If this is true, then what if this TB is running infinitely, and do > not > >> > return, or it is in a very long loop? In this case, TCG thread cannot > be > >> > interrupted? > >> > >> Every TB starts with a little bit of generated code that checks > >> the 'tcg_exit_req' flag in the CPUState for the CPU (see the > >> gen_tb_start() function). If some other part of QEMU wants the > >> CPU to stop running guest code and return to the top level loop, > >> it calls cpu_exit() which sets this flag. > > > > > > But this does not answer my question yet: if we the flag is only > > enable when TB already enters the "long loop", then nothing can break > > this TB execution? > > We check the flag for every TB we execute. Therefore in any > loop we must check the flag each time round the loop. So > if another thread sets the flag, we will exit. > > (A TB is always ended by any kind of branch instruction, > so you can't have a loop within a single TB. A tight loop > turns into a TB that ends with "branch back to the start > of this TB", but that will re-execute the flag-check code.) > Oh right, this tight loop is my main concern. It makes sense now. Thanks!!
[Qemu-devel] [patch] replace all strdup() with g_strdup()
This patch replaces all the strdup() with g_strdup() Signed-off-by: Jun Koi $ diffstat strdup.diff cmd.c |4 ++-- envlist.c |6 +++--- exec.c |2 +- hw/isa-bus.c|2 +- hw/pc.c |2 +- hw/pci.c|2 +- hw/qdev.c |2 +- hw/scsi-bus.c |2 +- hw/sun4m.c |6 +++--- hw/sun4u.c |2 +- hw/usb-msd.c|2 +- hw/virtio-blk.c |2 +- ia64-dis.c |2 +- microblaze-dis.c| 18 +- path.c |2 +- readline.c |2 +- test-qmp-commands.c | 12 ++-- 17 files changed, 35 insertions(+), 35 deletions(-) strdup.diff Description: Binary data
Re: [Qemu-devel] where is the definition of cpu_ldub_code() for Softmmu mode?
On Mon, May 18, 2015 at 6:20 PM, Peter Maydell wrote: > On 18 May 2015 at 10:55, Jun Koi wrote: > > Hi, > > > > I am trying to find the definition of cpu_ldub_code() in Softmmu mode. > > However, the only thing I can find is like this in > include/exec/cpu_ldst.h: > > > > #define cpu_ldub_code(env1, p) ldub_raw(p) > > Your QEMU tree is out of date -- this macro was removed in > commit 9220fe54c6. > > > Unfortunately, this is only for Usermode (CONFIG_USER_ONLY), so > > still I have no idea where cpu_ldub_code() is defined for Softmmu mode. > > In cpu_ldst.h we #define MEMSUFFIX _code and then include > "exec/cpu_ldst_template.h" multiple times to define the > accessor functions for the various widths. (For the usermode > version we include "exec/cpu_ldst_useronly_template.h", for > similar effect.) > Looking closer to this code, this leads to the function helper_ldb_cmmu(), but I cannot find where this code is defined. Any hints, please? Thanks.
Re: [Qemu-devel] where is the definition of cpu_ldub_code() for Softmmu mode?
On Fri, Jun 12, 2015 at 3:59 PM, Peter Maydell wrote: > On 12 June 2015 at 08:29, Jun Koi wrote: > > On Mon, May 18, 2015 at 6:20 PM, Peter Maydell > > > wrote: > >> In cpu_ldst.h we #define MEMSUFFIX _code and then include > >> "exec/cpu_ldst_template.h" multiple times to define the > >> accessor functions for the various widths. (For the usermode > >> version we include "exec/cpu_ldst_useronly_template.h", for > >> similar effect.) > > > > > > Looking closer to this code, this leads to the function > helper_ldb_cmmu(), > > but I cannot find where this code is defined. > > manooth$ git grep cmmu > cputlb.c:#define MMUSUFFIX _cmmu > include/exec/cpu_ldst.h:uint8_t helper_ldb_cmmu(CPUArchState *env, > target_ulong addr, int mmu_idx); > include/exec/cpu_ldst.h:uint16_t helper_ldw_cmmu(CPUArchState *env, > target_ulong addr, int mmu_idx); > include/exec/cpu_ldst.h:uint32_t helper_ldl_cmmu(CPUArchState *env, > target_ulong addr, int mmu_idx); > include/exec/cpu_ldst.h:uint64_t helper_ldq_cmmu(CPUArchState *env, > target_ulong addr, int mmu_idx); > include/exec/cpu_ldst_template.h:#define MMUSUFFIX _cmmu > > The first of these is where cputlb.c includes > softmmu_template.h, which is what's defining the > function you're interested in. > > Excellent, thanks!!!
Re: [Qemu-devel] [Bug 581353] Re: qemu doesn't stop execution upon hitting a breakpoint
On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo wrote: > Same thing happens to me, same versions as above.. I must turn to > another app to accomplish my work while awaiting for a bug-fix, the code > is perfectly executed but while gdb hits the breakpoints qemu goes on.. > > -- > qemu doesn't stop execution upon hitting a breakpoint > https://bugs.launchpad.net/bugs/581353 > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. i think this bug has been fixed in 0.12.4. have you tried that?? J
[Qemu-devel] Re: [Bug 581353] Re: qemu doesn't stop execution upon hitting a breakpoint
On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka wrote: > Jun Koi wrote: >> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo >> wrote: >>> Same thing happens to me, same versions as above.. I must turn to >>> another app to accomplish my work while awaiting for a bug-fix, the code >>> is perfectly executed but while gdb hits the breakpoints qemu goes on.. >>> >>> -- >>> qemu doesn't stop execution upon hitting a breakpoint >>> https://bugs.launchpad.net/bugs/581353 >>> You received this bug notification because you are a member of qemu- >>> devel-ml, which is subscribed to QEMU. >> >> i think this bug has been fixed in 0.12.4. have you tried that?? > > Or this is a well-known gdb deficit: if the bootloader operates in > real-mode, you have to set two breakpoints, one at the linear address to > make qemu catch it, and another one at the segment offset to avoid gdb > skipping the exit due to ip != bp-addr. > > gdb is still fairly restricted when it comes to system-level debugging, > specifically as it lacks support for special x86 registers and the > segmented addressing mode. what do you mean by "it lacks support for special x86 registers" ? thanks, J
[Qemu-devel] Re: [Bug 581353] Re: qemu doesn't stop execution upon hitting a breakpoint
On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka wrote: > Jun Koi wrote: >> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka wrote: >>> Jun Koi wrote: >>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo >>>> wrote: >>>>> Same thing happens to me, same versions as above.. I must turn to >>>>> another app to accomplish my work while awaiting for a bug-fix, the code >>>>> is perfectly executed but while gdb hits the breakpoints qemu goes on.. >>>>> >>>>> -- >>>>> qemu doesn't stop execution upon hitting a breakpoint >>>>> https://bugs.launchpad.net/bugs/581353 >>>>> You received this bug notification because you are a member of qemu- >>>>> devel-ml, which is subscribed to QEMU. >>>> i think this bug has been fixed in 0.12.4. have you tried that?? >>> Or this is a well-known gdb deficit: if the bootloader operates in >>> real-mode, you have to set two breakpoints, one at the linear address to >>> make qemu catch it, and another one at the segment offset to avoid gdb >>> skipping the exit due to ip != bp-addr. >>> >>> gdb is still fairly restricted when it comes to system-level debugging, >>> specifically as it lacks support for special x86 registers and the >>> segmented addressing mode. >> >> what do you mean by "it lacks support for special x86 registers" ? > > idtr, gdtr, ldtr, tr, crX - to name the most important ones. do you mean gdb has no command to show the values of these registers? or you mean it doenst have anyway to get notified when these registers are modified? (i dont see how this is useful for debugging, anway) thanks, J
[Qemu-devel] Monitoring memory access
Hi, I want to monitor memory reading access in Qemu. According to function tcg/i386/tcg-target.c::tcg_out_qemu_ld(), all the memory access must call qemu_ld_helpers[] functions, which in turn calls __ldX_mmu functions. These __ldX_mmu() functions are declared in softmmu_template.c, with macro glue(glue(__ld, SUFFIX), MMUSUFFIX). To monitor memory reading access, I simply put my monitored code at the top of the above macro. But apparently I still miss something, because I dont see the memory access I am looking for. Any hint where I am wrong? Perhaps some memory access do not call the qemu_ld_helpers[] functions? Many thanks, Jun
Re: [Qemu-devel] Monitoring memory access
On Fri, Jul 9, 2010 at 7:41 PM, malc wrote: > On Fri, 9 Jul 2010, Jun Koi wrote: > >> Hi, >> >> I want to monitor memory reading access in Qemu. According to function >> tcg/i386/tcg-target.c::tcg_out_qemu_ld(), all the memory access must >> call qemu_ld_helpers[] functions, which in turn calls __ldX_mmu >> functions. >> >> These __ldX_mmu() functions are declared in softmmu_template.c, with >> macro glue(glue(__ld, SUFFIX), MMUSUFFIX). >> >> To monitor memory reading access, I simply put my monitored code at >> the top of the above macro. But apparently I still miss something, >> because I dont see the memory access I am looking for. >> >> Any hint where I am wrong? Perhaps some memory access do not call the >> qemu_ld_helpers[] functions? > > Haven't we been through this already? > http://www.mail-archive.com/qemu-devel@nongnu.org/msg29788.html > Yes, we did, but sorry I am still stuck there. You said that once TLB is setup properly, future memory access would do directly, without going thru helpers any more. Is that correct? But what I see in tcg_out_qemu_ld() is that the below function is always called: tcg_out_calli(s, (tcg_target_long)qemu_ld_helpers[s_bits]); And since qemu_ld_helpers[] points to __ldX_mmu, so that means below macro is always executed: glue(glue(__ld, SUFFIX), MMUSUFFIX). I simply put my monitored code inside this macro. Could you give me some hints where I am wrong? Thanks, J
[Qemu-devel] regs_to_env() ?
Hi, Function regs_to_env() in target-i386/exec.h has a code like below: ... #ifdef reg_EAX env->regs[R_EAX] = EAX #endif ... However, elsewhere we have EAX defined as: #define EAX (env->regs[R_EAX]) This means effectively, we have code like: env->regs[R_EAX] = env->regs[R_EAX]; What is the meaning of this code? That looks pointless to me, but I guess I must be wrong here... Thanks, Jun
Re: [Qemu-devel] regs_to_env() ?
On Fri, Jul 23, 2010 at 7:08 AM, Blue Swirl wrote: > On Thu, Jul 22, 2010 at 2:06 AM, Jun Koi wrote: >> Hi, >> >> Function regs_to_env() in target-i386/exec.h has a code like below: >> >> ... >> #ifdef reg_EAX >> env->regs[R_EAX] = EAX >> #endif >> ... >> >> However, elsewhere we have EAX defined as: >> >> #define EAX (env->regs[R_EAX]) >> >> This means effectively, we have code like: >> >> env->regs[R_EAX] = env->regs[R_EAX]; >> >> What is the meaning of this code? That looks pointless to me, but I >> guess I must be wrong here... > > Yes, those lines don't exist anymore, they were used before TCG. IIRC > EAX was defined to AREG1 etc. > hey, that sounds funny. will you take a patch removing both regs_to_env() and env_to_regs() ? thanks, J
Re: [Qemu-devel] regs_to_env() ?
On Fri, Jul 23, 2010 at 10:43 AM, Jun Koi wrote: > On Fri, Jul 23, 2010 at 7:08 AM, Blue Swirl wrote: >> On Thu, Jul 22, 2010 at 2:06 AM, Jun Koi wrote: >>> Hi, >>> >>> Function regs_to_env() in target-i386/exec.h has a code like below: >>> >>> ... >>> #ifdef reg_EAX >>> env->regs[R_EAX] = EAX >>> #endif >>> ... >>> >>> However, elsewhere we have EAX defined as: >>> >>> #define EAX (env->regs[R_EAX]) >>> >>> This means effectively, we have code like: >>> >>> env->regs[R_EAX] = env->regs[R_EAX]; >>> >>> What is the meaning of this code? That looks pointless to me, but I >>> guess I must be wrong here... >> >> Yes, those lines don't exist anymore, they were used before TCG. IIRC >> EAX was defined to AREG1 etc. >> > > hey, that sounds funny. > > will you take a patch removing both regs_to_env() and env_to_regs() ? oops that was removed in latest code already. (i looked at 0.12.4 code) thanks, J
Re: [Qemu-devel] [PATCH 8/8] Rework debug exception processing for gdb use
On Fri, Jul 23, 2010 at 1:58 PM, TeLeMan wrote:
> On Fri, Jun 25, 2010 at 22:56, Jan Kiszka wrote:
>> Guest debugging is currently broken under CONFIG_IOTHREAD. The reason is
>> inconsistent or even lacking signaling the debug events from the source
>> VCPU to the main loop and the gdbstub.
>>
>> This patch addresses the issue by pushing this signaling into a
>> CPUDebugExcpHandler: cpu_debug_handler is registered as first handler,
>> thus will be executed last after potential breakpoint emulation
>> handlers. It sets informs the gdbstub about the debug event source,
>> requests a debug exit of the main loop and stops the current VCPU. This
>> mechanism works both for TCG and KVM, with and without IO-thread.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> cpus.c | 26 --
>> kvm-all.c | 2 --
>> 2 files changed, 16 insertions(+), 12 deletions(-)
>>
>> diff --git a/cpus.c b/cpus.c
>> index c024421..a607d9a 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -140,6 +140,13 @@ static int any_cpu_has_work(void)
>> return 0;
>> }
>>
>> +static void cpu_debug_handler(CPUState *env)
>> +{
>> + gdb_set_stop_cpu(env);
>> + debug_requested = EXCP_DEBUG;
>> + vm_stop(EXCP_DEBUG);
>> +}
>
> Is debug_requested or vm_stop() redundant?
>
certainly that debug_requested should only take value of 0 or 1.
thanks,
J
[Qemu-devel] [patch] add cscope.* to .gitignore
we have "make cscope", therefore that makes sense to have cscope.* in .gitignore. Signed-off-by: Jun Koi diff --git a/.gitignore b/.gitignore index a32b7c4..ec6f89f 100644 --- a/.gitignore +++ b/.gitignore @@ -53,3 +53,4 @@ pc-bios/optionrom/linuxboot.bin pc-bios/optionrom/multiboot.bin pc-bios/optionrom/multiboot.raw .stgit-* +cscope.*
[Qemu-devel] [patch] remove dead code
this patch removes unused function cpu_restore_state_copy(). Signed-off-by: Jun Koi diff --git a/exec-all.h b/exec-all.h index 58b5575..3a53fe6 100644 --- a/exec-all.h +++ b/exec-all.h @@ -86,9 +86,6 @@ int cpu_gen_code(CPUState *env, struct TranslationBlock *tb, int cpu_restore_state(struct TranslationBlock *tb, CPUState *env, unsigned long searched_pc, void *puc); -int cpu_restore_state_copy(struct TranslationBlock *tb, - CPUState *env, unsigned long searched_pc, - void *puc); void cpu_resume_from_signal(CPUState *env1, void *puc); void cpu_io_recompile(CPUState *env, void *retaddr); TranslationBlock *tb_gen_code(CPUState *env,
Re: [Qemu-devel] memory trace with qemu
On Fri, Jul 23, 2010 at 3:15 PM, Stefan Hajnoczi wrote: > On Fri, Jul 23, 2010 at 4:12 AM, Mulyadi Santosa > wrote: >> Hi... >> >> On Fri, Jul 23, 2010 at 05:30, Eduardo Cruz >> wrote: >>> Hello, I need qemu to keep track of all the memory access made by the guest, >>> including read, write and the instruction fetches. >> >> AFAIK there are lots of experiments on this and has produces working >> patches...at least from the posting of the creator. There is even a >> patch floating to start creating trace framework a while ago. > > Thanks Mulyadi, I think you are referring to the tracing work that > Prerna Saxena and I are doing. Here is the documentation: > > http://repo.or.cz/w/qemu/stefanha.git/blob/tracing:/docs/tracing.txt > > The patches apply to qemu.git. You can define trace events in the > trace-events file and then call them from places in the code. There > is a script to pretty-print the binary trace file that QEMU produces. > what trace events do you support now? thanks, J
[Qemu-devel] Question on save_globals() in TCG
Hi, I am looking at the save_globals() of TCG code, and it seems this function saves regular registers like EAX, ..., EDI back to CPU state. But I am not sure if it also saves value of other registers, like EFlags, Segments, CR*, DR*, ... (?) >From what I saw, it doesnt seem to do so. Is it correct? Thanks, J
[Qemu-devel] [patch] use symbol for DisasContext->is_jmp
This patch replaces constant value assigned for (DisasContext
*)->is_jmp with DISAS_TB_JUMP.
Signed-off-by: Jun Koi
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 2fcc026..9543298 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -2322,7 +2322,7 @@ static inline void gen_jcc(DisasContext *s, int b,
gen_set_label(l1);
gen_goto_tb(s, 1, val);
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
} else {
l1 = gen_new_label();
@@ -2400,11 +2400,11 @@ static void gen_movl_seg_T0(DisasContext *s, int seg_reg, target_ulong cur_eip)
stop as a special handling must be done to disable hardware
interrupts for the next instruction */
if (seg_reg == R_SS || (s->code32 && seg_reg < R_FS))
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
} else {
gen_op_movl_seg_T0_vm(seg_reg);
if (seg_reg == R_SS)
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
}
@@ -2672,7 +2672,7 @@ static void gen_exception(DisasContext *s, int trapno, target_ulong cur_eip)
gen_op_set_cc_op(s->cc_op);
gen_jmp_im(cur_eip);
gen_helper_raise_exception(tcg_const_i32(trapno));
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
/* an interrupt is different from an exception because of the
@@ -2685,7 +2685,7 @@ static void gen_interrupt(DisasContext *s, int intno,
gen_jmp_im(cur_eip);
gen_helper_raise_interrupt(tcg_const_i32(intno),
tcg_const_i32(next_eip - cur_eip));
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
static void gen_debug(DisasContext *s, target_ulong cur_eip)
@@ -2694,7 +2694,7 @@ static void gen_debug(DisasContext *s, target_ulong cur_eip)
gen_op_set_cc_op(s->cc_op);
gen_jmp_im(cur_eip);
gen_helper_debug();
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
/* generate a generic end of block. Trace exception is also generated
@@ -2716,7 +2716,7 @@ static void gen_eob(DisasContext *s)
} else {
tcg_gen_exit_tb(0);
}
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
/* generate a jump to eip. No segment change must happen before as a
@@ -2729,7 +2729,7 @@ static void gen_jmp_tb(DisasContext *s, target_ulong eip, int tb_num)
s->cc_op = CC_OP_DYNAMIC;
}
gen_goto_tb(s, tb_num, eip);
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
} else {
gen_jmp_im(eip);
gen_eob(s);
@@ -6968,7 +6968,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
gen_op_set_cc_op(s->cc_op);
gen_jmp_im(pc_start - s->cs_base);
gen_helper_hlt(tcg_const_i32(s->pc - pc_start));
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
break;
case 0x100:
@@ -7125,7 +7125,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
gen_helper_vmrun(tcg_const_i32(s->aflag),
tcg_const_i32(s->pc - pc_start));
tcg_gen_exit_tb(0);
-s->is_jmp = 3;
+s->is_jmp = DISAS_TB_JUMP;
}
break;
case 1: /* VMMCALL */
Re: [Qemu-devel] Question on save_globals() in TCG
On Sat, Jul 24, 2010 at 2:53 AM, Aurelien Jarno wrote: > On Fri, Jul 23, 2010 at 08:59:54PM +0900, Jun Koi wrote: >> Hi, >> >> I am looking at the save_globals() of TCG code, and it seems this >> function saves regular registers like EAX, ..., EDI back to CPU state. >> >> But I am not sure if it also saves value of other registers, like >> EFlags, Segments, CR*, DR*, ... (?) >> From what I saw, it doesnt seem to do so. Is it correct? >> > > save_globals() is run before calling a function that can trigger a CPU > exception, to make sure that in that case all TCG variables are synced > with the CPU state. Is it correct? I always assume that save_globals() is also called at end of each block. > > Given the CPU state only uses "normal" registers, there is no need to > save the other registers. Why do you say that CPU state includes only normal registers, given that, like on x86, CPUState has also segs[], cr[] and dr[]? Another question: if save_globals() only saves regular registers, where Qemu saves other registers like segs[], cr[]? Or do they always sync, all the time? Finally, how about Eflags? I remember that Eflags is "lazy sync", but does it sync at end of each block? Thanks, Jun
Re: [Qemu-devel] Question on save_globals() in TCG
On Sat, Jul 24, 2010 at 11:49 AM, Aurelien Jarno wrote: > On Sat, Jul 24, 2010 at 09:35:44AM +0900, Jun Koi wrote: >> On Sat, Jul 24, 2010 at 2:53 AM, Aurelien Jarno wrote: >> > On Fri, Jul 23, 2010 at 08:59:54PM +0900, Jun Koi wrote: >> >> Hi, >> >> >> >> I am looking at the save_globals() of TCG code, and it seems this >> >> function saves regular registers like EAX, ..., EDI back to CPU state. >> >> >> >> But I am not sure if it also saves value of other registers, like >> >> EFlags, Segments, CR*, DR*, ... (?) >> >> From what I saw, it doesnt seem to do so. Is it correct? >> >> >> > >> > save_globals() is run before calling a function that can trigger a CPU >> > exception, to make sure that in that case all TCG variables are synced >> > with the CPU state. >> >> Is it correct? I always assume that save_globals() is also called at >> end of each block. > > Correct also here. > >> > >> > Given the CPU state only uses "normal" registers, there is no need to >> > save the other registers. >> >> Why do you say that CPU state includes only normal registers, given >> that, like on x86, CPUState has also segs[], cr[] and dr[]? >> >> >> >> Another question: if save_globals() only saves regular registers, >> where Qemu saves other registers like segs[], cr[]? Or do they always >> sync, all the time? > > It's actually the same question. You are mixing host and target > registers. save_globals() only saves "normal" host registers. Host > registers can then contain whatever registers from the target, and > more precisely the one declared as globals. > > >> Finally, how about Eflags? I remember that Eflags is "lazy sync", but >> does it sync at end of each block? >> > > It's the same. Eflags are actually stored in a lazy way in cc_* > globals. They are therefore synced with save_globals(). This is very helpful, thanks! Another question: as far as I can see in the code, most context is always synced, all the time. One exception is Eflags, which is only synced at the end of block. Is there other lazy synced context, besides EFLAGS? Thanks, Jun
Re: [Qemu-devel] Question on save_globals() in TCG
On Sun, Jul 25, 2010 at 7:57 AM, Aurelien Jarno wrote: > On Sun, Jul 25, 2010 at 01:58:51AM +0900, Jun Koi wrote: >> On Sat, Jul 24, 2010 at 11:49 AM, Aurelien Jarno >> wrote: >> > On Sat, Jul 24, 2010 at 09:35:44AM +0900, Jun Koi wrote: >> >> On Sat, Jul 24, 2010 at 2:53 AM, Aurelien Jarno >> >> wrote: >> >> > On Fri, Jul 23, 2010 at 08:59:54PM +0900, Jun Koi wrote: >> >> >> Hi, >> >> >> >> >> >> I am looking at the save_globals() of TCG code, and it seems this >> >> >> function saves regular registers like EAX, ..., EDI back to CPU state. >> >> >> >> >> >> But I am not sure if it also saves value of other registers, like >> >> >> EFlags, Segments, CR*, DR*, ... (?) >> >> >> From what I saw, it doesnt seem to do so. Is it correct? >> >> >> >> >> > >> >> > save_globals() is run before calling a function that can trigger a CPU >> >> > exception, to make sure that in that case all TCG variables are synced >> >> > with the CPU state. >> >> >> >> Is it correct? I always assume that save_globals() is also called at >> >> end of each block. >> > >> > Correct also here. >> > >> >> > >> >> > Given the CPU state only uses "normal" registers, there is no need to >> >> > save the other registers. >> >> >> >> Why do you say that CPU state includes only normal registers, given >> >> that, like on x86, CPUState has also segs[], cr[] and dr[]? >> >> >> >> >> >> >> >> Another question: if save_globals() only saves regular registers, >> >> where Qemu saves other registers like segs[], cr[]? Or do they always >> >> sync, all the time? >> > >> > It's actually the same question. You are mixing host and target >> > registers. save_globals() only saves "normal" host registers. Host >> > registers can then contain whatever registers from the target, and >> > more precisely the one declared as globals. >> > >> > >> >> Finally, how about Eflags? I remember that Eflags is "lazy sync", but >> >> does it sync at end of each block? >> >> >> > >> > It's the same. Eflags are actually stored in a lazy way in cc_* >> > globals. They are therefore synced with save_globals(). >> >> This is very helpful, thanks! >> >> Another question: as far as I can see in the code, most context is >> always synced, all the time. One exception is Eflags, which is only >> synced at the end of block. >> Is there other lazy synced context, besides EFLAGS? > > It depends on the target, some of ones are also syncing the program > counter lazily. > ok, now i see that on x86, only EFLAGS is lazy sync. many thanks, J
[Qemu-devel] [patch] use gen_update_cc_op()
this patch simplifies target-i386/translate.c a bit by replacing some
code with gen_update_cc_op()
Signed-off-by: Jun Koi
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 9543298..7b6e3c2 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -2310,10 +2310,7 @@ static inline void gen_jcc(DisasContext *s, int b,
int l1, l2, cc_op;
cc_op = s->cc_op;
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
if (s->jmp_opt) {
l1 = gen_new_label();
gen_jcc1(s, cc_op, b, l1);
@@ -2724,10 +2721,7 @@ static void gen_eob(DisasContext *s)
static void gen_jmp_tb(DisasContext *s, target_ulong eip, int tb_num)
{
if (s->jmp_opt) {
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_goto_tb(s, tb_num, eip);
s->is_jmp = DISAS_TB_JUMP;
} else {
@@ -6901,10 +6895,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
if (!s->pe) {
gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
} else {
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s->cs_base);
gen_helper_sysenter();
gen_eob(s);
@@ -6917,10 +6908,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
if (!s->pe) {
gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
} else {
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s->cs_base);
gen_helper_sysexit(tcg_const_i32(dflag));
gen_eob(s);
@@ -6929,10 +6917,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
#ifdef TARGET_X86_64
case 0x105: /* syscall */
/* XXX: is it usable in real mode ? */
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s->cs_base);
gen_helper_syscall(tcg_const_i32(s->pc - pc_start));
gen_eob(s);
@@ -6941,10 +6926,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
if (!s->pe) {
gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
} else {
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s->cs_base);
gen_helper_sysret(tcg_const_i32(s->dflag));
/* condition codes are modified only in long mode */
@@ -7085,10 +7067,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
if (!(s->cpuid_ext_features & CPUID_EXT_MONITOR) ||
s->cpl != 0)
goto illegal_op;
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s->cs_base);
gen_helper_mwait(tcg_const_i32(s->pc - pc_start));
gen_eob(s);
@@ -7613,10 +7592,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
gen_svm_check_intercept(s, pc_start, SVM_EXIT_RSM);
if (!(s->flags & HF_SMM_MASK))
goto illegal_op;
-if (s->cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s->cc_op);
-s->cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(s->pc - s->cs_base);
gen_helper_rsm();
gen_eob(s);
Re: [Qemu-devel] memory trace with qemu
On Mon, Jul 26, 2010 at 8:16 PM, malc wrote: > On Mon, 26 Jul 2010, Eliot Moss wrote: > >> On 7/26/2010 6:20 AM, Llu?s wrote: >> > Eduardo Cruz writes: >> > >> > > Thanks for your awnsers. Stean, after I find the right place to capture >> > > the >> > > reads and writes I'll definitely try your trace tool. >> > >> > > Until now, this is what i found: >> > >> > > I am using the x86-64 target, and I know that, for instance, lots of >> > > reads >> > > pass here: >> > >> > > target-i386/translate.c gen_op_ld_T1_A0() >> > >> > Ok, I've seen at least 3 people working on this lately. >> > >> > Some time ago I wrote a message proposing two sets of modifications for >> > qemu, in >> > order to allow the analysis of guest code (like feeding traces to an >> > architecture simulator). >> > >> > What I proposed is based on two different functionalities: >> > >> > 1) backdoor: a mechanism for the guest to communicate with qemu, such that >> > tracing can be started, stopped, etc. >> > >> > My current approach is to decode an instruction that is deemed invalid >> > by the >> > target ISA according to the manual. >> > >> > This is only implemented for x86 right now, but it is trivial to >> > implement on >> > other architectures as long as there are unused opcodes. >> > >> > 2) instrumentation: a set of generic macros that signal events that might >> > be >> > of >> > interest. >> >> Etc. >> >> In the context of another simulator, we developed a different >> technique, which would be quite general and might be of interest >> for QEMU. We communicate with the simulator via a "fake" *device*, >> mapped into user-mode memory using an mmap call. If someone >> devised and coded such a device, then it could be used from any >> guest. > > I'v done something similar a while ago: > http://repo.or.cz/w/qemu/malc.git/shortlog/refs/heads/wctpci in this repo tree, which part is your new code? i looked at the git log, and tried to search your name, but none looks related. thanks, Jun
[Qemu-devel] Exposing monitor on socket interface?
Hi, Is it possible to use -monitor option to expose the monitor on socket interface, such as TCP or Unix domain port, so I can access the monitor using non-stdio way? Thanks a lot, Jun
[Qemu-devel] Re: Exposing monitor on socket interface?
Thanks a lot, Juan! Jun On Wed, Mar 24, 2010 at 6:41 PM, Juan Quintela wrote: > Jun Koi wrote: >> Hi, >> >> Is it possible to use -monitor option to expose the monitor on socket >> interface, such as TCP or Unix domain port, so I can access the >> monitor using non-stdio way? > > man qemu > > search -monitor > > -monitor dev > Redirect the monitor to host device dev (same devices as the serial > port). The default device is "vc" in graphical mode and "stdio" in > non graphical mode. > > search -serial > > -serial dev > Redirect the virtual serial port to host character device dev. The > default device is "vc" in graphical mode and "stdio" in non > graphical mode. > > This option can be used several times to simulate up to 4 serial > ports. > > Use "-serial none" to disable all serial ports. > > Available character devices are: > > > "tcp:[host]:port[,server][,nowait][,nodelay]" > The TCP Net Console has two modes of operation. It can send > the serial I/O to a location or wait for a connection from a > location. By default the TCP Net Console is sent to host at > the port. If you use the server option QEMU will wait for a > client socket application to connect to the port before > continuing, unless the "nowait" option was specified. The > "nodelay" option disables the Nagle buffering algorithm. If > host is omitted, 0.0.0.0 is assumed. Only one TCP connection at > a time is accepted. You can use "telnet" to connect to the > corresponding character device. > > "Example to send tcp console to 192.168.0.2 port " > -serial tcp:192.168.0.2: > > "Example to listen and wait on port for connection" > -serial tcp::,server > > "Example to not wait and listen on ip 192.168.0.100 port " > -serial tcp:192.168.0.100:,server,nowait > > "telnet:host:port[,server][,nowait][,nodelay]" > The telnet protocol is used instead of raw tcp sockets. The > options work the same as if you had specified "-serial tcp". > The difference is that the port acts like a telnet server or > client using telnet option negotiation. This will also allow > you to send the MAGIC_SYSRQ sequence if you use a telnet that > supports sending the break sequence. Typically in unix telnet > you do it with Control-] and then type "send break" followed by > pressing the enter key. > > > I think that it is difficult to get more options that qemu in that > department :-) > > Later, Juan. >
[Qemu-devel] Semantic meaning of "stop" command?
Hi, I always thought that the "stop" command provided by the monitor interface would pause the VM completely, but it doesnt seem so? I checked this by issuing the "stop" command on my VM, and noted its clock. Few minutes later, I resumed the VM (with "cont" command). The clock is immediately updated with the new time as if it is not paused, while I expected that it is not aware that it was paused. So it seems why its interface is frozen, the VM still keeps running in the background? So what is the real meaning of this "stop" command?? And if I want to completely pause the VM (not only its interface), what should I do? Thanks, Jun
[Qemu-devel] Re: Semantic meaning of "stop" command?
On Tue, Apr 6, 2010 at 9:59 PM, Juan Quintela wrote: > Jun Koi wrote: >> Hi, >> >> I always thought that the "stop" command provided by the monitor >> interface would pause the VM completely, but it doesnt seem so? >> >> I checked this by issuing the "stop" command on my VM, and noted its >> clock. Few minutes later, I resumed the VM (with "cont" command). The >> clock is immediately updated with the new time as if it is not paused, >> while I expected that it is not aware that it was paused. So it seems >> why its interface is frozen, the VM still keeps running in the >> background? >> >> So what is the real meaning of this "stop" command?? >> And if I want to completely pause the VM (not only its interface), >> what should I do? > > "stop" stops the vm. > > For startes cloks are weird. Once told that, see the new "host" clock (from > the man page). vm clock should do what you wanted. "host" just uses > the clock from the host. It has some advantages (see 2nd paragraph of > help). I tried again with "-rtc base=localtime,clock=vm", but that didnt help: when resuming the VM, the time is still synchronized with the host. I expected that it the VM clock isolated as in the manual below, but that was not the case. Perhaps I still missed smt? Thanks, J > > Later, Juan. > > -rtc [base=utc|localtime|date][,clock=host|vm][,driftfix=none|slew] > Specify base as "utc" or "localtime" to let the RTC start at the > current UTC or local time, respectively. "localtime" is required > for correct date in MS-DOS or Windows. To start at a specific point > in time, provide date in the format "2006-06-17T16:01:21" or > "2006-06-17". The default base is UTC. > > By default the RTC is driven by the host system time. This allows > to use the RTC as accurate reference clock inside the guest, > specifically if the host time is smoothly following an accurate > external reference clock, e.g. via NTP. If you want to isolate the > guest time from the host, even prevent it from progressing during > suspension, you can set clock to "vm" instead. >
[Qemu-devel] Weird thing happen when the VM is stop! (0.12.3)
Hi, I found something very funny happening with 0.12.3: it seems the VM is still running even I already stopped it. Here is how I verified that: Boot any OS (I checked with Windows XP and Ubuntu) with 0.12.3, and stop it any time after it booted up. Use "stop" command on monitor interface. Now the VM stops. Then in the same monitor interface, run "info registers" again and again. You can see that the value of EIP and EFLAGS still change once in a while. This should not happen, becaues the VM already stopped. I checked, and dont see this problem with 0.11.1. And this doesnt happen with the latest code in the git tree, either. Any idea on why this happens??? (My host is running Ubuntu 9.10, and I am using i386-softmmu/qemu to run VM on this experiment) Thanks, Jun
[Qemu-devel] [PATCH] Cleanup dead code
This patch removes some dead code in exec.c
Signed-off-by: Jun Koi
diff --git a/exec.c b/exec.c
index 76163aa..43366ac 100644
--- a/exec.c
+++ b/exec.c
@@ -2884,15 +2884,12 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
(typically a TLB entry) back to a ram offset. */
ram_addr_t qemu_ram_addr_from_host(void *ptr)
{
-RAMBlock *prev;
RAMBlock *block;
uint8_t *host = ptr;
-prev = NULL;
block = ram_blocks;
while (block && (block->host > host
|| block->host + block->length <= host)) {
-prev = block;
block = block->next;
}
if (!block) {
Re: [Qemu-devel] Weird thing happen when the VM is stop! (0.12.3)
On Fri, Apr 9, 2010 at 10:20 PM, Luiz Capitulino wrote:
> On Fri, 9 Apr 2010 18:32:21 +0900
> Jun Koi wrote:
>
>> Hi,
>>
>> I found something very funny happening with 0.12.3: it seems the VM is
>> still running even I already stopped it.
>>
>> Here is how I verified that: Boot any OS (I checked with Windows XP
>> and Ubuntu) with 0.12.3, and stop it any time after it booted up. Use
>> "stop" command on monitor interface.
>>
>> Now the VM stops. Then in the same monitor interface, run "info
>> registers" again and again. You can see that the value of EIP and
>> EFLAGS still change once in a while. This should not happen, becaues
>> the VM already stopped.
>>
>> I checked, and dont see this problem with 0.11.1. And this doesnt
>> happen with the latest code in the git tree, either.
>>
>> Any idea on why this happens???
>
> Can you try commit 55274a305 ? If it fixes the problem we need it
> in stable, if it doesn't you can try to find the fix by using git bisect.
>
This hint makes sense, but the point is that I tried with some commits
before that 55274a305, and didnt see the problem. Still I am not sure
the problem is already fixed before 55274a305, or I am just unlucky
enough not see the problem when testing.
After bisecting, I can say that the culprit is the below patch, from Marcelo.
Now I am wondering if the above commit 55274a305 of Paolo Bonzini
fixed the bug, or other commit before that?? We should find the
correct fix, and port it to 0.12.4.
Thanks,
J
commit 535d2eb34a0f1908dc694c51ce8d4ec6dccc7807
Author: Marcelo Tosatti
Date: Tue Feb 9 12:49:04 2010 -0200
iothread: fix vcpu stop with smp tcg
Round robin vcpus in tcg_cpu_next even if the vm stopped. This
allows all cpus to enter stopped state.
Signed-off-by: Marcelo Tosatti
Signed-off-by: Anthony Liguori
(cherry picked from commit c37cc7b072fa4ca8d8d21ac31d26baff5f47f9f9)
diff --git a/vl.c b/vl.c
index 007709a..3b5a8e0 100644
--- a/vl.c
+++ b/vl.c
@@ -4042,14 +4042,15 @@ static void tcg_cpu_exec(void)
for (; next_cpu != NULL; next_cpu = next_cpu->next_cpu) {
CPUState *env = cur_cpu = next_cpu;
-if (!vm_running)
-break;
if (timer_alarm_pending) {
timer_alarm_pending = 0;
break;
}
if (cpu_can_run(env))
ret = qemu_cpu_exec(env);
+else if (env->stop)
+break;
+
if (ret == EXCP_DEBUG) {
gdb_set_stop_cpu(env);
debug_requested = 1;
Re: [Qemu-devel] Weird thing happen when the VM is stop! (0.12.3)
On Sat, Apr 10, 2010 at 3:09 AM, Marcelo Tosatti wrote: > On Sat, Apr 10, 2010 at 01:12:27AM +0900, Jun Koi wrote: >> On Fri, Apr 9, 2010 at 10:20 PM, Luiz Capitulino >> wrote: >> > On Fri, 9 Apr 2010 18:32:21 +0900 >> > Jun Koi wrote: >> > >> >> Hi, >> >> >> >> I found something very funny happening with 0.12.3: it seems the VM is >> >> still running even I already stopped it. >> >> >> >> Here is how I verified that: Boot any OS (I checked with Windows XP >> >> and Ubuntu) with 0.12.3, and stop it any time after it booted up. Use >> >> "stop" command on monitor interface. >> >> >> >> Now the VM stops. Then in the same monitor interface, run "info >> >> registers" again and again. You can see that the value of EIP and >> >> EFLAGS still change once in a while. This should not happen, becaues >> >> the VM already stopped. >> >> >> >> I checked, and dont see this problem with 0.11.1. And this doesnt >> >> happen with the latest code in the git tree, either. >> >> >> >> Any idea on why this happens??? >> > >> > Can you try commit 55274a305 ? If it fixes the problem we need it >> > in stable, if it doesn't you can try to find the fix by using git bisect. >> > >> >> This hint makes sense, but the point is that I tried with some commits >> before that 55274a305, and didnt see the problem. Still I am not sure >> the problem is already fixed before 55274a305, or I am just unlucky >> enough not see the problem when testing. >> >> After bisecting, I can say that the culprit is the below patch, from Marcelo. >> >> Now I am wondering if the above commit 55274a305 of Paolo Bonzini >> fixed the bug, or other commit before that?? We should find the >> correct fix, and port it to 0.12.4. > > Guess its c5f32c99. Can you confirm please? I back-ported this patch to 0.12.3, and it seems the problem is gone. Thanks, J
[Qemu-devel] [Patch] Simplify cpu_can_run()
This patch simplifies cpu_can_run().
Signed-off-by: Jun Koi
diff --git a/cpus.c b/cpus.c
index 0debe77..4adb66d 100644
--- a/cpus.c
+++ b/cpus.c
@@ -98,9 +98,7 @@ static void do_vm_stop(int reason)
static int cpu_can_run(CPUState *env)
{
-if (env->stop)
-return 0;
-if (env->stopped || !vm_running)
+if (env->stop || env->stopped || !vm_running)
return 0;
return 1;
}
[Qemu-devel] Missing singlestep for already-translated code?
Hi, I am looking into the singlestep command in monitor interface, and it seems that we only take into account the singlestep flag when we are translating code. So for the already-translated code, we will miss singlestep? Thanks, Jun
[Qemu-devel] Re: Missing singlestep for already-translated code?
On Tue, Apr 13, 2010 at 6:21 PM, wrote:
> Hi,
>> So for the already-translated code, we will miss singlestep?
> At least SH4(and mips?) shows such behaviour.
> I think a patch below enables single stepping in such case, too.
> But, I'm not sure if this behaviour is on purpose, nor this patch is correct.
> /yoshii
>
> diff --git a/target-sh4/translate.c b/target-sh4/translate.c
> index 3537f8c..dfa724a 100644
> --- a/target-sh4/translate.c
> +++ b/target-sh4/translate.c
> @@ -300,7 +300,7 @@ static void gen_goto_tb(DisasContext * ctx, int n,
> target_ulong dest)
> tb = ctx->tb;
>
> if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK) &&
> - !ctx->singlestep_enabled) {
> + !ctx->singlestep_enabled && !singlestep) {
> /* Use a direct jump if in same page and singlestep not enabled */
> tcg_gen_goto_tb(n);
> tcg_gen_movi_i32(cpu_pc, dest);
>
The first glance: because you are patching translate.c, I dont think
you fixed the problem.
Thanks,
J
Re: [Qemu-devel] Re: Missing singlestep for already-translated code?
On Wed, Apr 14, 2010 at 12:28 AM, Jan Kiszka wrote:
> Alexander Graf wrote:
>> On 13.04.2010, at 15:36, Jan Kiszka wrote:
>>
>>> Jun Koi wrote:
>>>> Hi,
>>>>
>>>> I am looking into the singlestep command in monitor interface, and it
>>>> seems that we only take into account the singlestep flag when we are
>>>> translating code.
>>>> So for the already-translated code, we will miss singlestep?
>>> This feature is broken. For TCG, it should at least flush the
>>> translation buffer, and for KVM it has to enable single-stepping in the
>>> kernel. That's what happens automatically when you call cpu_single_step.
>>> I guess 'singlestep' wants to be somehow orthogonal to this. But this is
>>> the wrong approach.
>>>
>>> Does anyone actually used this feature or still does so? It looks fairly
>>> redundant to me, kind of a poor-man's gdb front-end as part of the
>>> monitor console.
>>
>> Not sure what it does, but I use -singlestep quite a lot to get register
>> dumps for instructions when using -d cpu.
>
> Ah, "singlestep" is not about stopping the VM after each instruction but
> about limiting the TB length to a single instruction. Badly named and
> poorly documented.
>
> In that case, the dynamic switch should already be fine by adding a
> tb_flush() on enable. Still, someone should also patch at least the docs.
>
Do you have any comment on the below patch?
Thanks,
J
diff --git a/monitor.c b/monitor.c
index 5659991..dfa9820 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1190,8 +1190,13 @@ static void do_log(Monitor *mon, const QDict *qdict)
static void do_singlestep(Monitor *mon, const QDict *qdict)
{
const char *option = qdict_get_try_str(qdict, "option");
+CPUState *env;
+
if (!option || !strcmp(option, "on")) {
singlestep = 1;
+/* flush all the TB to force new code generation */
+for (env = first_cpu; env != NULL; env = env->next_cpu)
+tb_flush(env);
} else if (!strcmp(option, "off")) {
singlestep = 0;
} else {
[Qemu-devel] [PATCH] flush TB on singlestep command
(Thanks to Jan for comments on the last patch)
Qemu has a command named singlestep, which reduces the translated code
block to be only one instruction.
However, there is one flaw when this command is triggered via monitor
interface: we do not flush all the current TBs, so we will miss
single-step on already translated code.
This patch fixes the problem by flushing all the TB to force new code
generation.
Signed-off-by: Jun Koi
diff --git a/monitor.c b/monitor.c
index 5659991..948b861 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1190,8 +1190,14 @@ static void do_log(Monitor *mon, const QDict *qdict)
static void do_singlestep(Monitor *mon, const QDict *qdict)
{
const char *option = qdict_get_try_str(qdict, "option");
+CPUState *env;
+
if (!option || !strcmp(option, "on")) {
singlestep = 1;
+/* flush all the TBs to force new code generation */
+for (env = first_cpu; env != NULL; env = env->next_cpu) {
+tb_flush(env);
+}
} else if (!strcmp(option, "off")) {
singlestep = 0;
} else {
[Qemu-devel] TLB entry with separate addr_{read|write|code}?
Hi, In the TLB entry, why do we need to maintain separately addr_read, addr_write and addr_code? Is it impossible to have only one for all the purposes? As far as I can see in tlb_set_page(), these fields are mutually exclusive, as they either enable or get invalid value (-1). Thanks, Jun
[Qemu-devel] Re: TLB entry with separate addr_{read|write|code}?
On Fri, Apr 16, 2010 at 11:49 AM, Jun Koi wrote: > Hi, > > In the TLB entry, why do we need to maintain separately addr_read, > addr_write and addr_code? Is it impossible to have only one for all > the purposes? > > As far as I can see in tlb_set_page(), these fields are mutually > exclusive, as they either enable or get invalid value (-1). Hmm I looked at the code again, and the attributes can be read, write and execute at the same time. Thanks, J
[Qemu-devel] Which functions writes to memory?
Hi, I am writing a small tool to trace all the activities that write to an area of (virtual) memory in Qemu. I am currently doing that by putting my code at the top of the below macro in softmmu_header.h static inline void glue(glue(st, SUFFIX), MEMSUFFIX) However, it seems I still miss some written events: in some occasions, I believe that Qemu has another code writing data to memory, which happens even before this macro. Is it true that elsewhere, Qemu also writes into memory besides using above function? The memory area I am tracking for written events belong to normal area in OS kernel, where usually only normal code (kernel, not something like SMM handler) write to. Thanks a lot, Jun
Re: [Qemu-devel] Which functions writes to memory?
2010/4/16 malc : > On Fri, 16 Apr 2010, Jun Koi wrote: > >> On Fri, Apr 16, 2010 at 3:17 PM, malc wrote: >> > On Fri, 16 Apr 2010, Jun Koi wrote: >> > >> >> Hi, >> >> >> >> I am writing a small tool to trace all the activities that write to an >> >> area of (virtual) memory in Qemu. >> >> I am currently doing that by putting my code at the top of the below >> >> macro in softmmu_header.h >> >> >> >> static inline void glue(glue(st, SUFFIX), MEMSUFFIX) >> >> >> >> However, it seems I still miss some written events: in some occasions, >> >> I believe that Qemu has another code writing data to memory, which >> >> happens even before this macro. >> >> Is it true that elsewhere, Qemu also writes into memory besides using >> >> above function? >> >> >> >> The memory area I am tracking for written events belong to normal area >> >> in OS kernel, where usually only normal code (kernel, not something >> >> like SMM handler) write to. >> > >> > Once the TLB is properly set up st helpers are bypassed entirely and >> > tcg generated code writes to it directly, it's quite easy to "workaround" >> > that at the expense of much slower execution. >> > >> >> This saves me a lot of frustrated time, thanks! >> >> Now I can see that tcg code calls to __stb*_mmu(), but cannot find any >> code call to st*_mmu(). >> Do you have any hint? > > The tcg generated code fetches appropriate helper's address from the > qemu_st/ld_helpers array and calls it indirectly. Sorry if that was not clear, but my question is: which code called st*mmu() macros (in softmmu_header.h) I searched around everywhere, but dont see which calls these macros. Thanks, J
Re: [Qemu-devel] Which functions writes to memory?
On Fri, Apr 16, 2010 at 3:17 PM, malc wrote: > On Fri, 16 Apr 2010, Jun Koi wrote: > >> Hi, >> >> I am writing a small tool to trace all the activities that write to an >> area of (virtual) memory in Qemu. >> I am currently doing that by putting my code at the top of the below >> macro in softmmu_header.h >> >> static inline void glue(glue(st, SUFFIX), MEMSUFFIX) >> >> However, it seems I still miss some written events: in some occasions, >> I believe that Qemu has another code writing data to memory, which >> happens even before this macro. >> Is it true that elsewhere, Qemu also writes into memory besides using >> above function? >> >> The memory area I am tracking for written events belong to normal area >> in OS kernel, where usually only normal code (kernel, not something >> like SMM handler) write to. > > Once the TLB is properly set up st helpers are bypassed entirely and > tcg generated code writes to it directly, it's quite easy to "workaround" > that at the expense of much slower execution. > This saves me a lot of frustrated time, thanks! Now I can see that tcg code calls to __stb*_mmu(), but cannot find any code call to st*_mmu(). Do you have any hint? Thanks a lot, J
[Qemu-devel] dummy field in CPUTLBEntry?
Hi,
I find the way we calculate the dummy field in CPUTLBEntry funny. What
is the point of having:
((-sizeof(target_ulong) * 3) & (sizeof(unsigned long) - 1))
in its size? Why shouldnt it be more simple, like below?
uint8_t dummy[(1 << CPU_TLB_ENTRY_BITS) - (sizeof(target_ulong) *
3 + sizeof(unsigned long))];
Thanks,
J
typedef struct CPUTLBEntry {
/* bit TARGET_LONG_BITS to TARGET_PAGE_BITS : virtual address
bit TARGET_PAGE_BITS-1..4 : Nonzero for accesses that should not
go directly to ram.
bit 3 : indicates that the entry is invalid
bit 2..0 : zero
*/
target_ulong addr_read;
target_ulong addr_write;
target_ulong addr_code;
/* Addend to virtual address to get host address. IO accesses
use the corresponding iotlb value. */
unsigned long addend;
/* padding to get a power of two size */
uint8_t dummy[(1 << CPU_TLB_ENTRY_BITS) -
(sizeof(target_ulong) * 3 +
((-sizeof(target_ulong) * 3) & (sizeof(unsigned
long) - 1)) +
sizeof(unsigned long))];
} CPUTLBEntry;
Re: [Qemu-devel] [PATCH] flush TB on singlestep command
Thank you for the explanation of this code.
Qemu has a command named singlestep, which reduces the translated code
block to be only one instruction.
This new patch flushes TBs both when singlestep is on and off.
Signed-off-by: Jun Koi
diff --git a/monitor.c b/monitor.c
index 5659991..2b2005b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1187,13 +1187,26 @@ static void do_log(Monitor *mon, const QDict *qdict)
cpu_set_log(mask);
}
+/* flush all the TBs to force new code generation */
+static void flush_all_tb(void)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env->next_cpu) {
+tb_flush(env);
+}
+}
+
static void do_singlestep(Monitor *mon, const QDict *qdict)
{
const char *option = qdict_get_try_str(qdict, "option");
+
if (!option || !strcmp(option, "on")) {
singlestep = 1;
+flush_all_tb();
} else if (!strcmp(option, "off")) {
singlestep = 0;
+flush_all_tb();
} else {
monitor_printf(mon, "unexpected option %s\n", option);
}
On Sat, Apr 17, 2010 at 6:13 AM, Stefan Weil wrote:
> Jun Koi schrieb:
>> (Thanks to Jan for comments on the last patch)
>>
>> Qemu has a command named singlestep, which reduces the translated code
>> block to be only one instruction.
>> However, there is one flaw when this command is triggered via monitor
>> interface: we do not flush all the current TBs, so we will miss
>> single-step on already translated code.
>> This patch fixes the problem by flushing all the TB to force new code
>> generation.
>>
>> Signed-off-by: Jun Koi
>>
>>
>>
>> diff --git a/monitor.c b/monitor.c
>> index 5659991..948b861 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -1190,8 +1190,14 @@ static void do_log(Monitor *mon, const QDict
>> *qdict)
>> static void do_singlestep(Monitor *mon, const QDict *qdict)
>> {
>> const char *option = qdict_get_try_str(qdict, "option");
>> + CPUState *env;
>> +
>> if (!option || !strcmp(option, "on")) {
>> singlestep = 1;
>> + /* flush all the TBs to force new code generation */
>> + for (env = first_cpu; env != NULL; env = env->next_cpu) {
>> + tb_flush(env);
>> + }
>> } else if (!strcmp(option, "off")) {
>> singlestep = 0;
>> } else {
>
> Hi,
>
> sorry that my feedback comes rather late. I read the discussion,
> but had no time to answer.
>
> I wrote the code for the singlestep command line and monitor option
> (which already existed before as a compile time option) and still use
> it frequently. Up to now, I did not miss the tb flushing, but I see that
> it might be useful in certain cases.
>
> My typical use cases for "singlestep" are
>
> * Compare execution of same code (usually a user mode program or a kernel)
> running in different environments (32 bit or 64 bit host, big or little
> endian host, different host architectures).
> In combination with -D in_asm,cpu it is possible to find wrong tcg code
> by comparing the resulting qemu.log files.
>
> * Use singlestep to slow down the execution (yes, this is sometimes useful).
>
> In most cases, I use the command line option, but sometimes I use the
> monitor command, too.
>
> There is no logical relation between switching singlestep on or off and
> tb flushing. If there is the need for tb flush, I'd suggest to add a new
> monitor command.
>
> If the translated tbs should match the singlestep setting,
> you would also have to flush them when singlestep is disabled:
> in that case, the translated tbs only contain a single target instruction,
> so they are not very efficient - and they remain so even after
> singlestep was disabled.
>
> So either flush for singlestep on and off, or better add a new monitor
> command
> which flushes tbs.
>
> Regards,
> Stefan
>
>
Re: [Qemu-devel] Re: [PATCH] flush TB on singlestep command
On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf wrote:
>
> On 20.04.2010, at 13:38, Jan Kiszka wrote:
>
>> Alexander Graf wrote:
>>> On 20.04.2010, at 09:18, Jan Kiszka wrote:
>>>
>>>> Jun Koi wrote:
>>>>> Thank you for the explanation of this code.
>>>>>
>>>>> Qemu has a command named singlestep, which reduces the translated code
>>>>> block to be only one instruction.
>>>>> This new patch flushes TBs both when singlestep is on and off.
>>>>>
>>>>> Signed-off-by: Jun Koi
>>>>>
>>>>>
>>>>> diff --git a/monitor.c b/monitor.c
>>>>> index 5659991..2b2005b 100644
>>>>> --- a/monitor.c
>>>>> +++ b/monitor.c
>>>>> @@ -1187,13 +1187,26 @@ static void do_log(Monitor *mon, const QDict
>>>>> *qdict)
>>>>> cpu_set_log(mask);
>>>>> }
>>>>>
>>>>> +/* flush all the TBs to force new code generation */
>>>>> +static void flush_all_tb(void)
>>>>> +{
>>>>> + CPUState *env;
>>>>> +
>>>>> + for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>>> + tb_flush(env);
>>>>> + }
>>>>> +}
>>>>> +
>>>> The smaller your patch are, the more people pick on it. :)
>>>>
>>>> I was about to suggest moving this close to tb_flush, but then I
>>>> realized that the env argument of that service is misleading. In fact,
>>>> it already flushes the one and only translation buffer pool.
>>>>
>>>>> static void do_singlestep(Monitor *mon, const QDict *qdict)
>>>>> {
>>>>> const char *option = qdict_get_try_str(qdict, "option");
>>>>> +
>>>>> if (!option || !strcmp(option, "on")) {
>>>>> singlestep = 1;
>>>>> + flush_all_tb();
>>>>> } else if (!strcmp(option, "off")) {
>>>>> singlestep = 0;
>>>>> + flush_all_tb();
>>>>> } else {
>>>>> monitor_printf(mon, "unexpected option %s\n", option);
>>>>> }
>>>>>
>>>> Let's just pass mon->mon_cpu to tb_flush and skip the redundant loop.
>>>
>>> That doesn't help, no? singlestep is a global variable. Flushing only the
>>> current vcpu would still not affect the others, while the singlestep switch
>>> would.
>>
>> tb_flush uses env only to dump some state when a problem occurred.
>>
>>>
>>> According to your above comment the cache is global, but I don't think we
>>> should rely on that.
>>
>> It might make sense to define some tb_flush_all() as tb_flush(first_cpu)
>> for now to establish the infrastructure. Then we are prepared for the
>> day the tb_flush implementation may change.
>
> Right. But then the call to tb_flush_all here is still correct.
So what is the final solution do you want?
I still think that having flush_all_tb() like in the last patch is good enough.
thanks,
J
Re: [Qemu-devel] Re: [PATCH] flush TB on singlestep command
On Thu, Apr 22, 2010 at 4:20 AM, Stefan Weil wrote:
> Jan Kiszka schrieb:
>> Alexander Graf wrote:
>>
>>> On 21.04.2010, at 12:04, Jun Koi wrote:
>>>
>>>
>>>> On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf wrote:
>>>>
>>>>> On 20.04.2010, at 13:38, Jan Kiszka wrote:
>>>>>
>>>>>
>>>>>> Alexander Graf wrote:
>>>>>>
>>>>>>> On 20.04.2010, at 09:18, Jan Kiszka wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Jun Koi wrote:
>>>>>>>>
>>>>>>>>> Thank you for the explanation of this code.
>>>>>>>>>
>>>>>>>>> Qemu has a command named singlestep, which reduces the translated code
>>>>>>>>> block to be only one instruction.
>>>>>>>>> This new patch flushes TBs both when singlestep is on and off.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jun Koi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> diff --git a/monitor.c b/monitor.c
>>>>>>>>> index 5659991..2b2005b 100644
>>>>>>>>> --- a/monitor.c
>>>>>>>>> +++ b/monitor.c
>>>>>>>>> @@ -1187,13 +1187,26 @@ static void do_log(Monitor *mon, const QDict
>>>>>>>>> *qdict)
>>>>>>>>> cpu_set_log(mask);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +/* flush all the TBs to force new code generation */
>>>>>>>>> +static void flush_all_tb(void)
>>>>>>>>> +{
>>>>>>>>> + CPUState *env;
>>>>>>>>> +
>>>>>>>>> + for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>>>>>>> + tb_flush(env);
>>>>>>>>> + }
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>>
>>>>>>>> The smaller your patch are, the more people pick on it. :)
>>>>>>>>
>>>>>>>> I was about to suggest moving this close to tb_flush, but then I
>>>>>>>> realized that the env argument of that service is misleading. In fact,
>>>>>>>> it already flushes the one and only translation buffer pool.
>>>>>>>>
>>>>>>>>
>>>>>>>>> static void do_singlestep(Monitor *mon, const QDict *qdict)
>>>>>>>>> {
>>>>>>>>> const char *option = qdict_get_try_str(qdict, "option");
>>>>>>>>> +
>>>>>>>>> if (!option || !strcmp(option, "on")) {
>>>>>>>>> singlestep = 1;
>>>>>>>>> + flush_all_tb();
>>>>>>>>> } else if (!strcmp(option, "off")) {
>>>>>>>>> singlestep = 0;
>>>>>>>>> + flush_all_tb();
>>>>>>>>> } else {
>>>>>>>>> monitor_printf(mon, "unexpected option %s\n", option);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Let's just pass mon->mon_cpu to tb_flush and skip the redundant loop.
>>>>>>>>
>>>>>>> That doesn't help, no? singlestep is a global variable. Flushing only
>>>>>>> the current vcpu would still not affect the others, while the
>>>>>>> singlestep switch would.
>>>>>>>
>>>>>> tb_flush uses env only to dump some state when a problem occurred.
>>>>>>
>>>>>>
>>>>>>> According to your above comment the cache is global, but I don't think
>>>>>>> we should rely on that.
>>>>>>>
>>>>>> It might make sense to define some tb_flush_all() as tb_flush(first_cpu)
>>>>>> for now to establish the infrastructure. Then we are prepared for the
>>>>>> day the tb_flush implementation may change.
>>>>>>
>>>>> Right. But then the call to tb_flush_all here is still correct.
>>>>>
>>>> So what is the final solution do you want?
>>>>
>>>> I still think that having flush_all_tb() like in the last patch is good
>>>> enough.
>>>>
>>> I agree. And I like the patch as is.
>>>
>>> Acked-by: Alexander Graf
>>>
>>>
>>
>> Sorry, nack for keeping this service in /monitor.c/. But a bonus ack if
>> you avoid the needless loop when moving it to exec.c, adding a comment
>> that current tb_flush has global, env-invariant scope.
>>
>> Thanks,
>> Jan
>
> flush_all_tb() is now called for singlestep on and off, that's fine.
> But it's called always - no way to disable this call. That's not good.
> Sometimes I don't want to flush all TBs when I switch singlestep mode
When dont you want to flush TBs??
Thanks,
J
[Qemu-devel] Compile Qemu on Windows?
Hi, I want to compile Qemu on Windows (then run it there). Is there any instruction on how to do that? (I googled around, to no avail) Many thanks, Jun
[Qemu-devel] Problem with watchpoint in gdbstub
Hi, I am trying to debug a VM using gdb. I connected gdb to Qemu (latest code from git repo), and issued below command: ... (gdb) watch *0x77f44cd8 (gdb) c The idea is to catch the write access to address 0x77f44cd8. But after the "c" command, I saw that the window title of my VM continuously flip between "QEMU [Stopped]" and "QEMU", non-stop. This makes the VM unusable. Is it a bug? Anybody sees the same problem? Thanks, Jun
[Qemu-devel] [PATCH] A bit optimization for tlb_set_page()
It is not necessary to continue searching for watchpoint when we already found one and setup for handling watchpoint in a search loop in tlb_set_page(). This patch breaks that search loop on then. Signed-off-by: Jun Koi diff --git a/exec.c b/exec.c index 14d1fd7..6329775 100644 --- a/exec.c +++ b/exec.c @@ -2240,6 +2240,7 @@ void tlb_set_page(CPUState *env, target_ulong vaddr, /* TODO: The memory case can be optimized by not trapping reads of pages with a write breakpoint. */ address |= TLB_MMIO; +break; } }
[Qemu-devel] Re: Problem with watchpoint in gdbstub
On Tue, Apr 27, 2010 at 5:10 PM, Jan Kiszka wrote: > Jun Koi wrote: >> Hi, >> >> I am trying to debug a VM using gdb. I connected gdb to Qemu (latest >> code from git repo), and issued below command: >> >> ... >> (gdb) watch *0x77f44cd8 >> (gdb) c >> >> The idea is to catch the write access to address 0x77f44cd8. >> >> But after the "c" command, I saw that the window title of my VM >> continuously flip between "QEMU [Stopped]" and "QEMU", non-stop. >> This makes the VM unusable. >> >> Is it a bug? Anybody sees the same problem? > > I would bet your watchpoint was established by gdb as a software > watchpoint. In that case gdb will step through the target, checking > after each instruction if the memory changed. But that is certainly not the reason of the symptom I saw. > > Is that address valid at the time gdb wants to install it? I saw gdb > choosing a software watchpoint before when it wasn't. Yes, that address is valid. thanks, J
