Re: [Qemu-discuss] QEMU: DBT vs. Interpretation
On 28 January 2015 at 02:51, Dale R. Worley wrote: > Javier Picorel writes: >> We are trying to make QEMU deterministic for >> architectural simulation. In the absence of I/O, >> let's say only user code or exceptions, is there >> any source of indeterminism (e.g., non deterministic >> compiler optimizations, TB indeterminism) of >> QEMU's DBT versus a canonical interpreter? Thanks! > > I'm not sure exactly what information you're trying to obtain. Given > that most CPU architectures have multiple implementations, and many of > those have complex internal operations, it's difficult to make an > emulator deterministic in any way other than "its behavior conforms to > the architecture specification". I had assumed the meaning here was "deterministic" in the sense of "every time you run QEMU with the same binary and settings you get exactly the same execution run". With the default switches we don't provide that (we give 'best performance' instead). -icount is I think supposed to be deterministic but probably buggy. Determinism is a requirement for the checkpoint/ reverse execution work so the people doing that are probably best placed to say what the current status is. -- PMM
Re: [Qemu-discuss] QEMU: DBT vs. Interpretation
Yes, your assumption is right. Every time we execute the same binary and settings (w/o I/O), we get the same instruction trace. The question is whether DBT introduces any source of indeterminism (e.g., arbitrary reordering of instructions in the TB or something that does not violate correctness but it’s not exactly the same). We checked the code and it seems that the TCG generates the same code every time, but we would like some confirmation. Thanks! Regards, Javier > On 28 Jan 2015, at 11:18, Peter Maydell wrote: > > On 28 January 2015 at 02:51, Dale R. Worley wrote: >> Javier Picorel writes: >>> We are trying to make QEMU deterministic for >>> architectural simulation. In the absence of I/O, >>> let's say only user code or exceptions, is there >>> any source of indeterminism (e.g., non deterministic >>> compiler optimizations, TB indeterminism) of >>> QEMU's DBT versus a canonical interpreter? Thanks! >> >> I'm not sure exactly what information you're trying to obtain. Given >> that most CPU architectures have multiple implementations, and many of >> those have complex internal operations, it's difficult to make an >> emulator deterministic in any way other than "its behavior conforms to >> the architecture specification". > > I had assumed the meaning here was "deterministic" in the sense > of "every time you run QEMU with the same binary and settings > you get exactly the same execution run". With the default > switches we don't provide that (we give 'best performance' > instead). -icount is I think supposed to be deterministic but > probably buggy. Determinism is a requirement for the checkpoint/ > reverse execution work so the people doing that are probably > best placed to say what the current status is. > > -- PMM
[Qemu-discuss] qemu-system-arm - machines with more than 1 GB RAM?
Hi, I'd like to emulate an armhf platform with at least 2, better 4 or more GB RAM, allthough didn't find one supported by qemu. (most was vexpress-a9 with up to 1 GB) Since out in the wild there are ARM devices like the imx6 with up to 2GB, this seems to be quite odd. Do you have a hint, where to find information about the maximum amount of RAM the different qemu arm machines support?
Re: [Qemu-discuss] qemu-system-arm - machines with more than 1 GB RAM?
On 28 January 2015 at 16:02, Stefan wrote: > I'd like to emulate an armhf platform with at least 2, better 4 > or more GB RAM, allthough didn't find one supported by qemu. > (most was vexpress-a9 with up to 1 GB) vexpress-a15 allows up to 30GB (assuming a 64-bit host system; 32-bit hosts are always limited to just under 2GB guest RAM). The "virtual machine" board 'virt' can also handle up to 30GB. highbank and midway can do 4GB. > Since out in the wild there are ARM devices like the imx6 > with up to 2GB, this seems to be quite odd. It's just a reflection of which SoCs and boards we've modelled. > Do you have a hint, where to find information > about the maximum amount of RAM the different qemu arm machines > support? You have to read the source code, I'm afraid. -- PMM
[Qemu-discuss] About ftp
hi, friends After `ftp.exe 10.0.2.2` successfully, why cannot i `ls` the host(OpenBSD) ? Even passive mode doesnot work too. The guest is WindowsXP running in qemu-2.x on OpenBSD. Regards!
[Qemu-discuss] A different way of networking
Hi there! When I was looking around for some documentation on how to get qemu networking I only found guides where bridges and/or VPNs were involved. Since I didn‘t want to read another manpage concerning something I probably won‘t need anywhere else and since I had the time to think about how things usually work, I created „my“ setup and wrote down what I did. Starting with my notes I wrote the documentation I was missing when I was looking around for something helpful. My setup doesn‘t need anything else than what comes with probably any Linux installation (no bridge, no VPN etc.). Another advantage of my setup is that all things are tied together with iptables rules only. A disadvantage may be that every new independent virtual machine sits in its own (sub)net. If you want to make your qemu networking without having to set up bridging and such, my (german) guide may be helpful: http://html.szaktilla.de/qemu If you have any comment or suggestion please let me know. Have fun! That‘s an order :-) Gregor
Re: [Qemu-discuss] About ftp
On 29/01/2015 02:19, z_axis wrote: hi, friends After `ftp.exe 10.0.2.2` successfully, why cannot i `ls` the host(OpenBSD) ? Even passive mode doesnot work too. The guest is WindowsXP running in qemu-2.x on OpenBSD. Regards! Three possibilities: 1. Is this one of those ftp servers (traditional) where the ftp ls command actually invokes /bin/ls on the server? In that case it could be a server issue. To test this try to ftp 127.0.0.1 from the server itself (with the same username/password) to make sure it is actually working. 2. Is this a situation where the secondary (data) channel doesn't get through. To test this, try to simply "get" a file which you know is there. The error message should be more revealing in such cases, as it now only reflects the transmission (and possible file access errors). For extra diagnostics, turn on verbose mode first. If this reveals a problem, check if you are using some kind of NAT logic between the virtual network inside qemu and the host (I seem to recall that some qemu options do this). 3. Are you sure you are in passive mode? Not all Microsoft implementations of ftp.exe actually include the code for passive mode, even when the corresponding copy of Internet Explorer does. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: [Qemu-discuss] A different way of networking
On 29/01/2015 05:01, Gregor Szaktilla wrote: Hi there! When I was looking around for some documentation on how to get qemu networking I only found guides where bridges and/or VPNs were involved. Actually, the "bridge" involved is also part of Linux itself. In fact on many moderndistributions (such as Debian 6/7/8), the needed bridge commands are preinstalledand simply need to be enabled in the network config file. Since I didn‘t want to read another manpage concerning something I probably won‘t need anywhere else and since I had the time to think about how things usually work, I created „my“ setup and wrote down what I did. Starting with my notes I wrote the documentation I was missing when I was looking around for something helpful. My setup doesn‘t need anything else than what comes with probably any Linux installation (no bridge, no VPN etc.). Another advantage of my setup is that all things are tied together with iptables rules only. A disadvantage may be that every new independent virtual machine sits in its own (sub)net. For example, on Debian, all you need to do is change the file /etc/network/interfaceson the host machine from something like: auto eth0 iface eth0 inet ... ... Tosomething like (the ... parts are unchanged): auto br0 iface br0 inet ... ... bridge_ports eth0 bridge_stp on bridge_maxwait 0 bridge_fd 0 Then qemu instances can simply be told to join br0, and it'll be like they are plugged in next tothe host computer in extra ports in your home router. No need for special iptables rules, tun/tap devices etc. (though you can still use iptables/ebtables if you want to block some traffic). I have heard that Red Hat people like much more difficult explanations, and have even included those in their GUI designs, but with Debian (and probably Ubuntu) it is really this simple. If you want to make your qemu networking without having to set up bridging and such, my (german) guide may be helpful: http://html.szaktilla.de/qemu If you have any comment or suggestion please let me know. Have fun! That‘s an order :-) Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
