Re: [PATCH v2] KVM: Specify byte order for KVM_EXIT_MMIO
On 26.01.2014, at 06:43, Victor Kamensky wrote:
> On 25 January 2014 19:46, Victor Kamensky wrote:
>> On 25 January 2014 10:31, Christoffer Dall
>> wrote:
>>> On Sat, Jan 25, 2014 at 04:23:00PM +, Peter Maydell wrote:
On 25 January 2014 02:15, Alexander Graf wrote:
> Ok, let's go through the combinations for a 32-bit write of 0x01020304 on
> PPC and what data[] looks like
>>
>> Alex, could you please for the clarification purpose, tell
>> us what instructions BE guest and LE guest run in below
>> cases. Suppose r0 register has device address, and r1
>> register has word as 0x01020304. And suppose we have
>> regular memory instead of io at r0 address. How do you
>> see 'unsigned char data[4]' will look like if 'data'
>> address is at r0.
>>
>> For this, for a moment, I think, we can forget about KVM,
>> just consider BE guest and LE guest running on regular
>> h/w.
>>
>> Next we will consider cases as below when the same
>> BE guest and LE guest runs on top of BE host or LE
>> host KVM in different proposals combinations. Effectively
>> defining non-virtual examples first and consider how they
>> will work under KVM.
>>
>> I was thinking that that you consider
>>
>> BE guest:
>> stw r1, 0, r0
>> just write r1 at r0 address
>>
>> LE guest
>> stwbrx r1, 0, r0
>> stwbrx - word byteswap r1 value and write it at r0 address
>>
>> which would produce at r0 address
>> data[] = {0x01, 0x02, 0x03, 0x04}
>> for both above cases, and have the same effect
>> on device if its register is mapped at r0 address.
>>
>> But judging by your other response in previous email, I
>> think you have something different in mind. Please
>> describe it.
>
> Alex, I reread your tables again. I think that just
> 'stw r1, 0, r0' for both LE and BE will match them. As
> far as data[] concerned in BE it will be data[] = {0x01,
> 0x02, 0x03, 0x04}, and in LE it wil lbe data[] = {0x04,
> 0x03, 0x02, 0x01}.
>
> Do we agree that these are two different memory
> transactions, as far as device concerned?
Not sure I understand what you mean by that. "stw" is "stw" regardless of the
MSR.LE setting. The only reason we care about all of this in KVM is that we
implement an instruction emulator that needs to do what the CPU does - and that
one interprets MSR.LE.
>
>> Thanks,
>> Victor
>>
> your proposal:
>
> BE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
> BE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
>
> -> ldw_p() will give us the correct value to work with
>
> current proposal:
>
> BE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
> BE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
> LE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
>
> -> *(uint32_t*)data will give us the correct value to work with
For completeness, ditto, ARM:
Scott's proposal (you end up with the same values in
the data array as for PPC, so userspace has to know the
"default" endianness so it can do a byteswap
>
> Actually userland need to mange mismatch between
> native internal data of simulated device and device
> endianity. If native endianity mismatches device qemu
> need to do byteswap. Otherwise it will be just copy it
> into mmio.data as bytes array.
> In qemu there is already infrastructure that handles
> that. My ARM BE KVM patches use Scott's mmio.
> data[] definition and I did not do anything in qemu
> to make that work.
Right, that's what I indicated with my original email. Scott's proposal makes
current QEMU "just work" while our proposal needs QEMU changes.
>
if the
process endianness doesn't match it; on QEMU
ldl_p() handles this for us, as you say):
BE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
LE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
BE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
LE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
>
> Peter, thank you for adding ARM case. It really
> helps to see the difference between definitions.
>
> Don't you agree that Scott's definition has advantage
> because its interpretation does not depend on
> CPU type?
>
> It is always the same for the same 'device access
> operation', guest endianity, host endianity. If one
> look at 'stw r1, 0, r0' in BE guest, and 'stwbrx r1,
> 0, r0' in LE guest, which is the same memory
> transaction as device concerned. Table using
> Scott's definition will always look like
>
> LE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
> BE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
>
> if ARM would work with this device to do the
> same thing, its table will look exactly the same.
>
current proposal:
BE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
>
Re: [PATCH v2] KVM: Specify byte order for KVM_EXIT_MMIO
On 26.01.2014, at 04:46, Victor Kamensky wrote: > On 25 January 2014 10:31, Christoffer Dall > wrote: >> On Sat, Jan 25, 2014 at 04:23:00PM +, Peter Maydell wrote: >>> On 25 January 2014 02:15, Alexander Graf wrote: Ok, let's go through the combinations for a 32-bit write of 0x01020304 on PPC and what data[] looks like > > Alex, could you please for the clarification purpose, tell > us what instructions BE guest and LE guest run in below > cases. Suppose r0 register has device address, and r1 > register has word as 0x01020304. And suppose we have > regular memory instead of io at r0 address. How do you > see 'unsigned char data[4]' will look like if 'data' > address is at r0. > > For this, for a moment, I think, we can forget about KVM, > just consider BE guest and LE guest running on regular > h/w. > > Next we will consider cases as below when the same > BE guest and LE guest runs on top of BE host or LE > host KVM in different proposals combinations. Effectively > defining non-virtual examples first and consider how they > will work under KVM. > > I was thinking that that you consider > > BE guest: > stw r1, 0, r0 > just write r1 at r0 address > > LE guest > stwbrx r1, 0, r0 > stwbrx - word byteswap r1 value and write it at r0 address LE guests also use "stw", but with MSR.LE=1. Of course an OS that tries to access the same device on the same CPU with MSR.LE=1 that it used to access with stw may use stwbrx to swap the endianness of the resulting operation because the CPU will swap it again because of MSR.LE. But that's guest OS logic which we can't rely on in KVM. Maybe the guest was using stwbrx in the BE case and is using stw with LE. Maybe it uses stw in both cases and fetches the bytes it needs to write from a buffer it has prepared. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM Test report, kernel c760f5e2... qemu 0169c511...
Hi All,
This is KVM upstream test result against kvm.git next branch and qemu.git
master branch.
kvm.git next branch: c760f5e29d92adf5184589f1e616a4be146fb57c based on
kernel 3.13.0
qemu.git master branch: 0169c511554cb0014a00290b0d3d26c31a49818f
We found no new bug and no fix bug in the past two weeks.
New issues (1):
1. Host call trace and guest hang after create guest.
https://bugzilla.kernel.org/show_bug.cgi?id=69361
Fixed issue (0):
Old issues (9):
--
1. guest panic with parameter "-cpu host" in qemu command line (about vPMU
issue).
https://bugs.launchpad.net/qemu/+bug/994378
2. Nested Virt: VMX can't be initialized in L1 Xen ("Xen on KVM")
https://bugzilla.kernel.org/show_bug.cgi?id=45931
3. Guest hang when doing kernel build and writing data in guest.
https://bugs.launchpad.net/qemu/+bug/1096814
4. with 'monitor pty', it needs to flush pts device after sending command to it
https://bugs.launchpad.net/qemu/+bug/1185228
5. [Nested] Windows XP Mode can not work
https://bugzilla.kernel.org/show_bug.cgi?id=60782
6. [Nested]L2 guest failed to start in VMware on KVM
https://bugzilla.kernel.org/show_bug.cgi?id=61411
7. [BISECTED][Nested]L2 guest boot up fail(kvm on kvm).
https://bugzilla.kernel.org/show_bug.cgi?id=67061
8. win7 guest boot up fail.
https://bugs.launchpad.net/qemu/+bug/1261265
9. save guest running time is more than 450s with AVX running.
https://bugs.launchpad.net/qemu/+bug/1261268
Test environment:
==
Platform IvyBridge-EP Sandybridge-EP
CPU Cores 32 32
Memory size 64GB 32GB
Thanks,
Zhou Chao
[Bug 69361] Host call trace and guest hang after create guest.
https://bugzilla.kernel.org/show_bug.cgi?id=69361 --- Comment #7 from Zhou, Chao --- (In reply to Marcelo Tosatti from comment #6) > Could be a duplicate of > http://marc.info/?l=linux-kernel&m=139038631607917&q=raw Can you try that > patch please after apply this patch to kvm.git commit:c760f5e29d92adf5184589f1e616a4be146fb57c, both guest and host work fine, the bug can't reproduce. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 69361] Host call trace and guest hang after create guest.
https://bugzilla.kernel.org/show_bug.cgi?id=69361 --- Comment #6 from Marcelo Tosatti --- Could be a duplicate of http://marc.info/?l=linux-kernel&m=139038631607917&q=raw Can you try that patch please -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.13 hangs when I tried to start a KVM at a 32 bit stable Gentoo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/24/2014 01:36 PM, Paolo Bonzini wrote:
> Il 23/01/2014 20:50, Toralf Förster ha scritto:
> | What makes the situation really annyoing - sometimes I just can
> | restart my wlan device it the system works normal, but sometimes
> | the whole system hangs and for those cases then sometimes not even
> | sysrq buttons do work.
>
> Can you reproduce it with the wlan driver disabled completely?
yes - with CONFIG_WLAN=n I do get a similar thing :
Jan 26 11:23:17 n22 kernel: NET: Registered protocol family 17
Jan 26 11:23:17 n22 kernel: device vnet0 entered promiscuous mode
Jan 26 11:23:17 n22 kernel: br0: port 4(vnet0) entered forwarding state
Jan 26 11:23:17 n22 kernel: br0: port 4(vnet0) entered forwarding state
Jan 26 11:23:17 n22 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes
ready
Jan 26 11:23:17 n22 kernel: cgroup: libvirtd (6113) created nested cgroup for
controller "memory" which has incomplete hierarchy support. Nested cgroups may
change behavior in the future.
Jan 26 11:23:17 n22 kernel: cgroup: "memory" requires setting use_hierarchy to
1 on the root.
Jan 26 11:23:19 n22 ntpd[6015]: Listen normally on 5 br0
fe80::837:18ff:feae:caf0 UDP 123
Jan 26 11:23:19 n22 ntpd[6015]: Listen normally on 6 vnet0
fe80::fc54:ff:fed0:f1eb UDP 123
Jan 26 11:23:19 n22 ntpd[6015]: peers refreshed
Jan 26 11:23:35 n22 kernel: br0: port 4(vnet0) entered disabled state
Jan 26 11:23:35 n22 kernel: device vnet0 left promiscuous mode
Jan 26 11:23:35 n22 kernel: br0: port 4(vnet0) entered disabled state
Jan 26 11:23:38 n22 ntpd[6015]: Deleting interface #6 vnet0,
fe80::fc54:ff:fed0:f1eb#123, interface stats: received=0, sent=0, dropped=0,
active_time=19 secs
Jan 26 11:23:38 n22 ntpd[6015]: peers refreshed
Jan 26 11:23:45 n22 kernel: device vnet0 entered promiscuous mode
Jan 26 11:23:45 n22 kernel: br0: port 4(vnet0) entered forwarding state
Jan 26 11:23:45 n22 kernel: br0: port 4(vnet0) entered forwarding state
Jan 26 11:23:48 n22 ntpd[6015]: Listen normally on 7 vnet0
fe80::fc54:ff:fed0:f1eb UDP 123
Jan 26 11:23:48 n22 ntpd[6015]: peers refreshed
Jan 26 11:24:09 n22 kernel: br0: port 4(vnet0) entered disabled state
Jan 26 11:24:09 n22 kernel: device vnet0 left promiscuous mode
Jan 26 11:24:09 n22 kernel: br0: port 4(vnet0) entered disabled state
Jan 26 11:24:11 n22 ntpd[6015]: Deleting interface #7 vnet0,
fe80::fc54:ff:fed0:f1eb#123, interface stats: received=0, sent=0, dropped=0,
active_time=23 secs
Jan 26 11:24:11 n22 ntpd[6015]: peers refreshed
Jan 26 11:24:28 n22 kernel: device vnet0 entered promiscuous mode
Jan 26 11:24:28 n22 kernel: br0: port 4(vnet0) entered forwarding state
Jan 26 11:24:28 n22 kernel: br0: port 4(vnet0) entered forwarding state
Jan 26 11:24:31 n22 ntpd[6015]: Listen normally on 8 vnet0
fe80::fc54:ff:fed0:f1eb UDP 123
Jan 26 11:24:31 n22 ntpd[6015]: peers refreshed
Jan 26 11:24:57 n22 kernel: hda-intel: IRQ timing workaround is activated for
card #0. Suggest a bigger bdl_pos_adj.
Jan 26 11:25:34 n22 kernel: INFO: rcu_sched self-detected stall on CPU { 3}
(t=6 jiffies g=23149 c=23148 q=7132)
Jan 26 11:25:34 n22 kernel: sending NMI to all CPUs:
Jan 26 11:25:34 n22 kernel: NMI backtrace for cpu 3
Jan 26 11:25:34 n22 kernel: CPU: 3 PID: 6523 Comm: qemu-system-x86 Not tainted
3.13.0 #5
Jan 26 11:25:34 n22 kernel: Hardware name: LENOVO 4180F65/4180F65, BIOS
83ET75WW (1.45 ) 05/10/2013
Jan 26 11:25:34 n22 kernel: task: e410c8a0 ti: eec6 task.ti: eec6
Jan 26 11:25:34 n22 kernel: EIP: 0060:[] EFLAGS: 0006 CPU: 3
Jan 26 11:25:34 n22 kernel: EIP is at __const_udelay+0xd/0x20
Jan 26 11:25:34 n22 kernel: EAX: 01062560 EBX: 2710 ECX: c1557e60 EDX:
00278af4
Jan 26 11:25:34 n22 kernel: ESI: c155c500 EDI: f3627c80 EBP: eec61c64 ESP:
eec61c64
Jan 26 11:25:34 n22 kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jan 26 11:25:34 n22 kernel: CR0: 80050033 CR2: CR3: 23c2e000 CR4:
000427f0
Jan 26 11:25:34 n22 kernel: Stack:
Jan 26 11:25:34 n22 kernel: eec61c74 c102dc75 c14b9db5 c155c500 eec61cb8
c108ba1c c14c3ac0 ea60
Jan 26 11:25:34 n22 kernel: 5a6d 5a6c 1bdc c106aadd 0001
c155c500 c1595544 f3627c80
Jan 26 11:25:34 n22 kernel: 1bdc 0003 e410c8a0 0003
eec61ccc c104a2fb f3627ec0
Jan 26 11:25:34 n22 kernel: Call Trace:
Jan 26 11:25:34 n22 kernel: []
arch_trigger_all_cpu_backtrace+0x55/0x70
Jan 26 11:25:34 n22 kernel: [] rcu_check_callbacks+0x38c/0x590
Jan 26 11:25:34 n22 kernel: [] ? account_system_time+0xbd/0x170
Jan 26 11:25:34 n22 kernel: [] update_process_times+0x3b/0x70
Jan 26 11:25:34 n22 kernel: [] tick_sched_handle.isra.12+0x33/0x40
Jan 26 11:25:34 n22 kernel: [] tick_sched_timer+0x40/0x70
Jan 26 11:25:34 n22 kernel: [] ? __remove_hrtimer+0x40/0xa0
Jan 26 11:25:34 n22 kernel: [] __run_hrtimer+0x69/0x190
Jan 26 11:25:34 n22 kernel: [] ? tick_sched_do_timer+0x40/0x40
Jan 26 11:25:34 n22 kernel: [] hrtimer_interrupt+0xf7/0x290
Jan 26 11:25:34 n22 kernel: [] ? tic
