Re: [Qemu-discuss] How to check cpu running mode?
Jakob:
I need more help,just now,I'm trigger a page fault in 64-bit mode,see this
picture:
https://github.com/krishna116/test/blob/master/test-qemu-in-64bit-mode.png
so I can write some system mode code accroding to this information,
but my follow code seems can't get the right answer, is my algorithm wrong?
//this is my algorithm in 64-bit mode:
#define CS_L_BIT 0x1<<(32+22-1)
//CS_selector_index=0x7; //0x38>>3
//GDTR_base=0x7E9; //0x7e9f598&~0x
int64* segment_descriptor_address=(int64*)(int64) (*(0x7E9+0x7*8*2));
//GDTR_base+CS_selector_index* sizeof(Segment_Descriptor*2)
if((*segment_descriptor_address)_L_BIT)
{
//it is 64bit mode
}else
{
//it is Compatibility mode
}
thank you,
krishna
Re: [Qemu-discuss] How to check cpu running mode?
it looks excellent code,although I'm not very familiar with ASM code,I will dig into it, thank you,Jakob! by krishna. At 2018-08-17 22:00:40, "Jakob Bohm" wrote: >On 17/08/2018 15:32, Jakob Bohm wrote: >> On 17/08/2018 12:27, krishnaLee wrote: >>> Hi, >>> as to my known,intel x64 cpu can work at 64-bit mode or >>> Compatibility mode, >>> so thery are two kind of x64-mode, >>> I find QEMU can run at each of them, >>> I want to write som C code to check it if it is running at 64-bit >>> mode or Compatibility mode, what's the key? >>> >> This mode is a bit in the segment descriptor referenced by the >> current CS register, the following or similar code should be >> able to check this(note that this code has to use only >> instructions that have the same encoding in all CPU modes!): >> >> ; UNTESTED HYPOTHETICAL CODE!!! >> >> ; First, check that we are not running in real or VM8086 >> ;mode, because then the following will not work >> ;(LAR will trigger an undefined opcode exception). >> ; Doing this is left as an exercise for the reader >> >> ; The following is valid in 16, 32 and 64 bit protected mode >> ;the instructions should have the same opcodes, they are >> ;shown here using the 32 bit mode Intel syntax >> .386 >> MOV EAX,CS >> LAR EAX,EAX >> JNZ SHORT modeerror >> SHR EAX,21 >> JCSHORT mode64 >> SHR EAX,1 >> JC SHORT mode32 >> mode16j: >> .286 >> ; Code here is 16 bit code and can use all 16 bit instructions >> JMP mode16; This can be a longer jmp now that we know the >> ; instruction encoding >> mode32j: >> .386 >> ; Code here is 32 bit code and can use all 32 bit instructions >> JMP mode32; This can be a longer jmp now that we know the >> ; instruction encoding >> mode64j: >> .amd64 ; Note, not sure what directive tells MASM to generate >> 64bit opcodes >> ; Code here is 64 bit code and can use all 64 bit instructions >> JMP mode64; This can be a longer jmp now that we know the >> ; instruction encoding >> modeerror: >> ; This really shouldn't happen! >> ; One possible way would be if something changed the CS descriptor >> ;in the descriptor table without reloading CS >> ; Code here is still restricted to mode independent instructions! >> >> ; Alternatively, a code sequence could be constructed that has different >> ;effects depending on CPU mode but doesn't directly query the CS >> ;descriptor table entry, avoiding the modeerror case above. >> >> ; UNTESTED HYPOTHETICAL CODE!!! >> >> ; Perhaps >> .386 >> XOR EAX,EAX ; XOR AX,AX if 16 bit mode >> NOT EAX ; 16 bit: AX is now 0h >> ; 32 bit: EAX is now 0h >> ; 64 bit: RAX is now 0h (UNTESTED) >> SHR EAX,16 >> JNC SHORT mode16j >> SHR EAX,16 >> JNC SHORT mode32j >> mode64j: >> ; as above >> mode32j: >> ; as above >> mode16j: >> .286 >> SMSW AX >> SHR AX,1 >> JNC SHORT mode16real >> ; Add code here to test if this is VM8086 mode or 16 bit >> ;protected mode >> ; First set up a stack, 4 byte aligned >> ; CODE MISSING >> ; Next do the classic tricks to detect if this is at least >> ;a 386, this involves using 16 bit PUSHF and POPF >> ; CODE MISSING >> ;The missing code should jump to mode16rj if < 386 >> ; Next use code to determine if in VM8086 mode, note that >> ;PUSHFD hides the desired EFLAGS bit from us, so another >> ;trick is needed >> ; CODE MISSING >>;The missing code should jump to mode16rj if real mode >> mode16vj: >> .286 >> ; Code here is 16 bit code and can use all 16 bit instructions >> ; VM8086 mode >> JMP mode16v ; This can be a longer jmp now that we know the >> ; instruction encoding >> mode16rj: >> .286 >> ; Code here is 16 bit code and can use all 16 bit instructions >> ; Real mode, full CPU access! >> JMP mode16v ; This can be a longer jmp now that we know the >> ; instruction encoding >Corrections: > >In the first example, the first shift should be > SHR EAX,22 > >In the second example, the first shift should be > SHR EAX,17 > >And the entire 16 bit case needs to be regrouped: > >mode16rj: > .286 > ; Code here is 16 bit code and can use all 16 bit instructions > ; Real mode, full CPU access! > ; May or may not be the unofficial large-segment real mode > JMP mode16r ; This can be a longer jmp now that we know the > ; instruction encoding >mode16j: > .286 > ; 16 bit code, maybe protected, real, VM8086 or even > ;the unofficial large-segment real mode > > ; First set up a stack, 4 byte aligned > ; CODE MISSING OR ASSUME STACK ALREADY VALID > ; Next do the classic
Re: [Qemu-discuss] Request for information inclusion on the wiki links page section of QEMU project!
OK! Thanks, Thomas! Best Regards,Daniel Bruno. Em sexta-feira, 17 de agosto de 2018 03:05:30 BRT, Thomas Huth escreveu: On 08/16/2018 08:48 AM, Thomas Huth wrote: [...] > Having said that, I think we can remove most of the other GUI entries in > the Wiki nowadays, since they seem to be pretty much out-of-date. FYI, I've now refreshed the links page, but in a little bit different way: I've introduced a "legacy GUI" section for GUIs that likely do not work with the latest version anymore (since there were a couple of them). I've also added JavaQemu there, too. Please let us know if you release a new version again that is also tested with the latest QEMU, then I can move the link to the normal GUI section, too. Thomas
Re: [Qemu-discuss] How to check cpu running mode?
On 17/08/2018 15:32, Jakob Bohm wrote: On 17/08/2018 12:27, krishnaLee wrote: Hi, as to my known,intel x64 cpu can work at 64-bit mode or Compatibility mode, so thery are two kind of x64-mode, I find QEMU can run at each of them, I want to write som C code to check it if it is running at 64-bit mode or Compatibility mode, what's the key? This mode is a bit in the segment descriptor referenced by the current CS register, the following or similar code should be able to check this(note that this code has to use only instructions that have the same encoding in all CPU modes!): ; UNTESTED HYPOTHETICAL CODE!!! ; First, check that we are not running in real or VM8086 ; mode, because then the following will not work ; (LAR will trigger an undefined opcode exception). ; Doing this is left as an exercise for the reader ; The following is valid in 16, 32 and 64 bit protected mode ; the instructions should have the same opcodes, they are ; shown here using the 32 bit mode Intel syntax .386 MOV EAX,CS LAR EAX,EAX JNZ SHORT modeerror SHR EAX,21 JCSHORT mode64 SHR EAX,1 JC SHORT mode32 mode16j: .286 ; Code here is 16 bit code and can use all 16 bit instructions JMP mode16 ; This can be a longer jmp now that we know the ; instruction encoding mode32j: .386 ; Code here is 32 bit code and can use all 32 bit instructions JMP mode32 ; This can be a longer jmp now that we know the ; instruction encoding mode64j: .amd64 ; Note, not sure what directive tells MASM to generate 64bit opcodes ; Code here is 64 bit code and can use all 64 bit instructions JMP mode64 ; This can be a longer jmp now that we know the ; instruction encoding modeerror: ; This really shouldn't happen! ; One possible way would be if something changed the CS descriptor ; in the descriptor table without reloading CS ; Code here is still restricted to mode independent instructions! ; Alternatively, a code sequence could be constructed that has different ; effects depending on CPU mode but doesn't directly query the CS ; descriptor table entry, avoiding the modeerror case above. ; UNTESTED HYPOTHETICAL CODE!!! ; Perhaps .386 XOR EAX,EAX ; XOR AX,AX if 16 bit mode NOT EAX ; 16 bit: AX is now 0h ; 32 bit: EAX is now 0h ; 64 bit: RAX is now 0h (UNTESTED) SHR EAX,16 JNC SHORT mode16j SHR EAX,16 JNC SHORT mode32j mode64j: ; as above mode32j: ; as above mode16j: .286 SMSW AX SHR AX,1 JNC SHORT mode16real ; Add code here to test if this is VM8086 mode or 16 bit ; protected mode ; First set up a stack, 4 byte aligned ; CODE MISSING ; Next do the classic tricks to detect if this is at least ; a 386, this involves using 16 bit PUSHF and POPF ; CODE MISSING ; The missing code should jump to mode16rj if < 386 ; Next use code to determine if in VM8086 mode, note that ; PUSHFD hides the desired EFLAGS bit from us, so another ; trick is needed ; CODE MISSING ; The missing code should jump to mode16rj if real mode mode16vj: .286 ; Code here is 16 bit code and can use all 16 bit instructions ; VM8086 mode JMP mode16v ; This can be a longer jmp now that we know the ; instruction encoding mode16rj: .286 ; Code here is 16 bit code and can use all 16 bit instructions ; Real mode, full CPU access! JMP mode16v ; This can be a longer jmp now that we know the ; instruction encoding Corrections: In the first example, the first shift should be SHR EAX,22 In the second example, the first shift should be SHR EAX,17 And the entire 16 bit case needs to be regrouped: mode16rj: .286 ; Code here is 16 bit code and can use all 16 bit instructions ; Real mode, full CPU access! ; May or may not be the unofficial large-segment real mode JMP mode16r ; This can be a longer jmp now that we know the ; instruction encoding mode16j: .286 ; 16 bit code, maybe protected, real, VM8086 or even ; the unofficial large-segment real mode ; First set up a stack, 4 byte aligned ; CODE MISSING OR ASSUME STACK ALREADY VALID ; Next do the classic tricks to detect if this is at least ; a 286, this involves using 16 bit PUSHF and POPF ; CODE MISSING ; The missing code should jump to mode16rj if < 286 SMSW AX SHR AX,1 JNC SHORT mode16rj ; So now it is protected mode or VM8086 mode ; First check if at least a 386 (we know it's at least 286) ; CODE MISSING ; The missing code should jump to mode16pj if a 286 ; Add code here to test if this is VM8086 mode or 16 bit ; protected mode ; Next use code to
Re: [Qemu-discuss] How to check cpu running mode?
On 17/08/2018 12:27, krishnaLee wrote: Hi, as to my known,intel x64 cpu can work at 64-bit mode or Compatibility mode, so thery are two kind of x64-mode, I find QEMU can run at each of them, I want to write som C code to check it if it is running at 64-bit mode or Compatibility mode, what's the key? This mode is a bit in the segment descriptor referenced by the current CS register, the following or similar code should be able to check this(note that this code has to use only instructions that have the same encoding in all CPU modes!): ; UNTESTED HYPOTHETICAL CODE!!! ; First, check that we are not running in real or VM8086 ; mode, because then the following will not work ; (LAR will trigger an undefined opcode exception). ; Doing this is left as an exercise for the reader ; The following is valid in 16, 32 and 64 bit protected mode ; the instructions should have the same opcodes, they are ; shown here using the 32 bit mode Intel syntax .386 MOV EAX,CS LAR EAX,EAX JNZ SHORT modeerror SHR EAX,21 JCSHORT mode64 SHR EAX,1 JC SHORT mode32 mode16j: .286 ; Code here is 16 bit code and can use all 16 bit instructions JMP mode16 ; This can be a longer jmp now that we know the ; instruction encoding mode32j: .386 ; Code here is 32 bit code and can use all 32 bit instructions JMP mode32 ; This can be a longer jmp now that we know the ; instruction encoding mode64j: .amd64 ; Note, not sure what directive tells MASM to generate 64bit opcodes ; Code here is 64 bit code and can use all 64 bit instructions JMP mode64 ; This can be a longer jmp now that we know the ; instruction encoding modeerror: ; This really shouldn't happen! ; One possible way would be if something changed the CS descriptor ; in the descriptor table without reloading CS ; Code here is still restricted to mode independent instructions! ; Alternatively, a code sequence could be constructed that has different ; effects depending on CPU mode but doesn't directly query the CS ; descriptor table entry, avoiding the modeerror case above. ; UNTESTED HYPOTHETICAL CODE!!! ; Perhaps .386 XOR EAX,EAX ; XOR AX,AX if 16 bit mode NOT EAX ; 16 bit: AX is now 0h ; 32 bit: EAX is now 0h ; 64 bit: RAX is now 0h (UNTESTED) SHR EAX,16 JNC SHORT mode16j SHR EAX,16 JNC SHORT mode32j mode64j: ; as above mode32j: ; as above mode16j: .286 SMSW AX SHR AX,1 JNC SHORT mode16real ; Add code here to test if this is VM8086 mode or 16 bit ; protected mode ; First set up a stack, 4 byte aligned ; CODE MISSING ; Next do the classic tricks to detect if this is at least ; a 386, this involves using 16 bit PUSHF and POPF ; CODE MISSING ; The missing code should jump to mode16rj if < 386 ; Next use code to determine if in VM8086 mode, note that ; PUSHFD hides the desired EFLAGS bit from us, so another ; trick is needed ; CODE MISSING ; The missing code should jump to mode16rj if real mode mode16vj: .286 ; Code here is 16 bit code and can use all 16 bit instructions ; VM8086 mode JMP mode16v ; This can be a longer jmp now that we know the ; instruction encoding mode16rj: .286 ; Code here is 16 bit code and can use all 16 bit instructions ; Real mode, full CPU access! JMP mode16v ; This can be a longer jmp now that we know the ; instruction encoding Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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] Best networking mode when using Wi-Fi
On Fri, 17 Aug 2018 13:00:06 +0200 user 96710 wrote: > Here's what I want to do: use Qemu on my Windows host while on Wi-Fi. > > Currently, I can only use SLIRP with Wi-Fi, but since it's quite slow I > would like to know what other options do I have. > > When the PC uses Ethernet, I can bridge the TAP and the Ethernet, however a > Wireless connection cannot be bridged: https://superuser.com/a/658143. I have bridge on my Linux PC: # brctl show bridge name bridge id STP enabled interfaces br1 8000.001b210e62eb no enp4s1 wlan0 But I run hostapd on wlan0, I don't know if it works as a client, but I suspect it does. Regards, Nerijus
[Qemu-discuss] Best networking mode when using Wi-Fi
Here's what I want to do: use Qemu on my Windows host while on Wi-Fi. Currently, I can only use SLIRP with Wi-Fi, but since it's quite slow I would like to know what other options do I have. When the PC uses Ethernet, I can bridge the TAP and the Ethernet, however a Wireless connection cannot be bridged: https://superuser.com/a/658143. I've seen solutions for Linux that manage to use TAP with Wi-Fi, but I don't know how to replicate the same in Windows. For example, https://forums.gentoo.org/viewtopic-t-987790-start-0.html The Qemu guide mentions these other networking modes besides SLIRP and TAP: bridge, l2tpv3, vde, netmap, vhost-user, socket, hubport. I don't know how they work. Could one of these be used to provide Internet to the guest when I'm on Wi-Fi? Another option is figuring out if programs like WinGate or OpenVPN would be able to provide the TAP with Internet. Can anyone offer some insight? Regards.
[Qemu-discuss] How to check cpu running mode?
Hi, as to my known,intel x64 cpu can work at 64-bit mode or Compatibility mode, so thery are two kind of x64-mode, I find QEMU can run at each of them, I want to write som C code to check it if it is running at 64-bit mode or Compatibility mode, what's the key? thank you, by krishna.
Re: [Qemu-discuss] qcow2 performanceimprove
On Fri, Aug 17, 2018 at 10:28:49AM +0800, yang.bi...@zte.com.cn wrote: > > > > If there is no backing file or snapshot you still need to fill > > > > the cluster with zeroes, and that's going to be slower with > > > > larger clusters. > > > If not fill zeroes and only write guest data ,what`s wrong could > > > happen ? > > The following could happen: > > 1) Guest reads at offset [0, 4k] -> there's only zeroes > > 2) Guest writes at offset [8k, 16k] > > 3) Guest reads at offset [0, 4k] -> there's something else now > Why could guest read the area at offset [0, 4k] has not be writen > yet ? Jakob already gave you some answers, but here's a simple one: because it might have already been written. If the guest wrote zeroes to [0, 1M] you can't generally assume that there's an allocated 1MB cluster on the qcow2 file filled with zeroes. - QEMU can detect that the guest tried to write zeroes and decide to leave the cluster unallocated (see for example the "detect_zeroes" option, or the "WRITE SAME" SCSI command). - The qcow2 file could have been converted at some point, and zero-filled clusters could have been deallocated for efficiency. Berto
Re: [Qemu-discuss] Latest Qemu-COLO Segfaults
Hello Again,
Any News on the Problems that I had? Have they been fixed or am I just
doing things wrong?
Regards,
Lukas Straub
On Tue, 5 Jun 2018 22:08:09 +0200
Lukas Straub wrote:
> Hi Zhang,
> I have tested Your latest Patch, and the Crash is gone and the
> Secondary now Synchronizes fine. So far so good. :)
>
> However sadly, I found more Problems:
> First it seems like COLO has problems comparing Packets send by the
> VMs as it's doing a lot of Checkpoints when doing even simple network
> operations. ping to local LAN for example is around ~200-4000ms and
> ssh is unusable, because input lags almost 10 Seconds behind. Also I
> get lots of messages on the primary qemu, see the log attached.
>
> Secondly, I couldn't really Failover. While the Secondary VM continues
> to run when the Primary Fails, it's unable to send/receive network
> packets. Also when executing { "execute": "x-colo-lost-heartbeat" }
> (is this still needed for Failover?), the Secondary Aborts:
>
> qemu-system-x86_64: Can't receive COLO message: Input/output error
> {"timestamp": {"seconds": 1528226730, "microseconds": 287902},
> "event": "COLO_EXIT", "data": {"mode": "secondary", "reason":
> "error"}} qemu-system-x86_64: Unable to connect character device
> red0: Failed to connect socket: Connection refused
> { "execute": "x-colo-lost-heartbeat" }
> {"return": {}}
> {"timestamp": {"seconds": 1528226733, "microseconds": 218936},
> "event": "STOP"}
> qemu-system-x86_64: Conflicts with use by a block device as 'root',
> which does not allow 'resize' on node0
> qemu-system-x86_64:
> free(): invalid size
>
>
> Third, Periodic mode (Remus-like without all the
> comparing/filters/rewriters) doesn't seem to work , the primary
> crashes at the first STOP:
>
> {"timestamp": {"seconds": 1528228672, "microseconds": 407981},
> "event": "RESUME"}
> {"timestamp": {"seconds": 1528228690, "microseconds": 230970},
> "event": "STOP"}
> qemu-system-x86_64: util/qemu-thread-posix.c:64: qemu_mutex_lock_impl:
> Assertion `mutex->initialized' failed.
>
> I use the scripts attached to test qemu-COLO (simply copying-pasting
> the echo output to the qmp monitor).
>
> I'm very glad that you work on Qemu-COLO.
>
> Many Thanks,
> Lukas Straub
