Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
Nikunj A Dadhania writes: > Hi Peter, > > Peter Maydell writes: >>> >>> That'd be awesome! FWIW "upstream" SLOF is at the following git URL: >>> >>> git://github.com/aik/SLOF.git >> >> That would result in the following updates to our mirror: >> >> - [deleted] benh >> - [deleted] debug_mem_alloc > > This is fine, there was some cleanup done to the repo. > >>e2e8ac9..10306b5 master -> master > > This is the current tree > >> + 09a3976...cc418be refs/pull/1/merge -> refs/pull/1/merge (forced update) > > I do not understand the above, these commits are not there. Neither at git://github.com/aik/SLOF.git nor at git://git.qemu.org/SLOF.git Regards, Nikunj
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
Hi Peter, Peter Maydell writes: >> >> That'd be awesome! FWIW "upstream" SLOF is at the following git URL: >> >> git://github.com/aik/SLOF.git > > That would result in the following updates to our mirror: > > - [deleted] benh > - [deleted] debug_mem_alloc This is fine, there was some cleanup done to the repo. >e2e8ac9..10306b5 master -> master This is the current tree > + 09a3976...cc418be refs/pull/1/merge -> refs/pull/1/merge (forced update) I do not understand the above, these commits are not there. > * [new tag] qemu-slof-20131118 -> qemu-slof-20131118 > * [new tag] qemu-slof-20131122 -> qemu-slof-20131122 > * [new tag] qemu-slof-20131126 -> qemu-slof-20131126 > * [new tag] qemu-slof-20131209 -> qemu-slof-20131209 > * [new tag] qemu-slof-20140121 -> qemu-slof-20140121 > * [new tag] qemu-slof-20140204 -> qemu-slof-20140204 > > Since in particular that includes deleting some references > and a forced update on another I thought I would check it > first. Regards, Nikunj
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
"Richard W.M. Jones" writes: > However attached are: > > - the libvirt XML > - the qemu command line > > which may help to reproduce the bug. I'm using upstream qemu + 91 > patches provided by Tom, as detailed earlier in this thread. I have verified this, resolved in current SLOF tree, Alexey has submitted a latest slof.bin for upstreaming. Regards Nikunj
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 21 February 2014 12:04, Alexander Graf wrote: > > On 21.02.2014, at 12:53, Peter Maydell wrote: > >> On 21 February 2014 11:48, Alexander Graf wrote: >>> Yes, he did. But to apply the update we first need the SLOF >>> copy on git.qemu.org updated. >> >> I can do that if you tell me what the upstream git repo >> it should be mirroring is. > > That'd be awesome! FWIW "upstream" SLOF is at the following git URL: > > git://github.com/aik/SLOF.git That would result in the following updates to our mirror: - [deleted] benh - [deleted] debug_mem_alloc e2e8ac9..10306b5 master -> master + 09a3976...cc418be refs/pull/1/merge -> refs/pull/1/merge (forced update) * [new tag] qemu-slof-20131118 -> qemu-slof-20131118 * [new tag] qemu-slof-20131122 -> qemu-slof-20131122 * [new tag] qemu-slof-20131126 -> qemu-slof-20131126 * [new tag] qemu-slof-20131209 -> qemu-slof-20131209 * [new tag] qemu-slof-20140121 -> qemu-slof-20140121 * [new tag] qemu-slof-20140204 -> qemu-slof-20140204 Since in particular that includes deleting some references and a forced update on another I thought I would check it first. thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 21.02.2014, at 12:53, Peter Maydell wrote: > On 21 February 2014 11:48, Alexander Graf wrote: >> Yes, he did. But to apply the update we first need the SLOF >> copy on git.qemu.org updated. > > I can do that if you tell me what the upstream git repo > it should be mirroring is. That'd be awesome! FWIW "upstream" SLOF is at the following git URL: git://github.com/aik/SLOF.git Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 21 February 2014 11:48, Alexander Graf wrote: > Yes, he did. But to apply the update we first need the SLOF > copy on git.qemu.org updated. I can do that if you tell me what the upstream git repo it should be mirroring is. thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 21.02.2014, at 12:21, Avik Sil wrote: > On 02/21/2014 04:25 PM, Aneesh Kumar K.V wrote: >> Alexander Graf writes: >> >>> The second bug is kind of interesting. If you add ~ 256 disks (using virtio-scsi), then it looks as if the firmware crashes. The total console output is below. It looks as if "c >" is some kind of prompt. qemu spins using 100% of CPU after this. >>> >>> How much RAM do you pass into the guest? Could you please try to >>> increase that size to see whether it makes a difference? If it >>> doesn't, Aneesh is your man :) >> >> Avik tells me that this is fixed in latest slof. > > Yes, the slof in upstream qemu is too old (Oct 15, 2013). With the > latest slof in https://github.com/aik/SLOF.git this issue is fixed. > AFAIR, Alexey was planning to send the latest slof to upstream qemu. Yes, he did. But to apply the update we first need the SLOF copy on git.qemu.org updated. Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 02/21/2014 04:25 PM, Aneesh Kumar K.V wrote: > Alexander Graf writes: > >> >>> The second bug is kind of interesting. If you add ~ 256 disks (using >>> virtio-scsi), then it looks as if the firmware crashes. The total >>> console output is below. It looks as if "c >" is some kind of prompt. >>> qemu spins using 100% of CPU after this. >> >> How much RAM do you pass into the guest? Could you please try to >> increase that size to see whether it makes a difference? If it >> doesn't, Aneesh is your man :) > > Avik tells me that this is fixed in latest slof. Yes, the slof in upstream qemu is too old (Oct 15, 2013). With the latest slof in https://github.com/aik/SLOF.git this issue is fixed. AFAIR, Alexey was planning to send the latest slof to upstream qemu. Regards, Avik
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
Alexander Graf writes: > >> The second bug is kind of interesting. If you add ~ 256 disks (using >> virtio-scsi), then it looks as if the firmware crashes. The total >> console output is below. It looks as if "c >" is some kind of prompt. >> qemu spins using 100% of CPU after this. > > How much RAM do you pass into the guest? Could you please try to > increase that size to see whether it makes a difference? If it > doesn't, Aneesh is your man :) Avik tells me that this is fixed in latest slof. -aneesh
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 12.02.2014, at 22:22, Tom Musta wrote: > This patch series implements the changes to Altivec introduced by Power ISA > Version 2.07. Thanks, applied to ppc-next. You might want to work with Peter and friends on Risu for PPC to verify that everything you're implementing here actually matches what real hardware does :). Alex > > Tom Musta (28): > target-ppc: Altivec 2.07: Add Instruction Flag > target-ppc: Altivec 2.07: Update AVR Structure > target-ppc: Altivec 2.07: Add GEN_VXFORM3 > target-ppc: Altivec 2.07: Add Support for Dual Altivec Instructions > target-ppc: Altivec 2.07: Add Opcode Macro for VX Form Instructions > target-ppc: Altivec 2.07: Add Support for R-Form Dual Instructions > target-ppc: Altivec 2.07: Vector Logical Instructions > target-ppc: Altivec 2.07: Add/Subtract Unsigned Doubleword Modulo > target-ppc: Altivec 2.07: Change VMUL_DO to Support 64-bit Integers > target-ppc: Altivec 2.07: Multiply Even/Odd Word Instructions > target-ppc: Altivec 2.07: vmuluw Instruction > target-ppc: Altivec 2.07: Add Vector Count Leading Zeroes > target-ppc: Altivec 2.07: Vector Population Count Instructions > target-ppc: Altivec 2.07: Vector Min/Max Doubleword Instructions > target-ppc: Altivec 2.07: Pack Doubleword Instructions > target-ppc: Altivec 2.07: Unpack Signed Word Instructions > target-ppc: Altivec 2.07: Vector Merge Instructions > target-ppc: Altivec 2.07: Change Bit Masks to Support 64-bit Rotates >and Shifts > target-ppc: Altivec 2.07: Vector Doubleword Rotate and Shift >Instructions > target-ppc: Altivec 2.07: Quadword Addition and Subtracation > target-ppc: Altivec 2.07: vbpermq Instruction > target-ppc: Altivec 2.07: Doubleword Compares > target-ppc: Altivec 2.07: Vector Gather Bits by Bytes > target-ppc: Altivec 2.07: Vector Polynomial Multiply Sum > target-ppc: Altivec 2.07: Binary Coded Decimal Instructions > target-ppc: Altivec 2.07: AES Instructions > target-ppc: Altivec 2.07: Vector SHA Sigma Instructions > target-ppc: Altivec 2.07: Vector Permute and Exclusive OR > > target-ppc/cpu.h|9 +- > target-ppc/helper.h | 62 +++ > target-ppc/int_helper.c | 1278 +-- > target-ppc/translate.c | 348 - > target-ppc/translate_init.c |2 +- > 5 files changed, 1648 insertions(+), 51 deletions(-) > >
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On Thu, Feb 20, 2014 at 01:36:57PM +0100, Alexander Graf wrote: > > On 20.02.2014, at 13:34, Richard W.M. Jones wrote: > > > On Thu, Feb 20, 2014 at 10:23:42AM +, Richard W.M. Jones wrote: > >> I am now running a full libguestfs test which will take several hours, > >> but it looks as if -- even if this test fails -- it won't be because > >> of lack of emulation / missing instructions in qemu. > > > > The tests ran. I hit two bugs, but neither seems to be related to > > qemu emulation. Please push these patches into upstream qemu :-) > > They will get into 2.0, no worries :). > > > One bug is in btrfs and is related to page size being different (and > > much larger) on ppc64. > > I remember bugs (oopses) with btrfs when you use a 4k page size created fs > and use it on a 64k page size kernel and vice versa. They still haven't fixed > that? The failure from the log is: wipefs -a --force /dev/sda1 mkfs.btrfs --alloc-start 0 --byte-count 268435456 --data single --leafsize 4096 --label test --metadata single --nodesize 4096 --sectorsize 512 /dev/sda1 Illegal leafsize (or nodesize) 4096 (smaller than 65536) I have not analysed this beyond simply looking at the command line now, but it seems that this is NOT a bug in btrfs, but a bug in the test suite, selecting a too small --leafsize parameter. Or perhaps a limitation in btrfs. Anyway, doesn't look serious. > > The second bug is kind of interesting. If you add ~ 256 disks (using > > virtio-scsi), then it looks as if the firmware crashes. The total > > console output is below. It looks as if "c >" is some kind of prompt. > > qemu spins using 100% of CPU after this. > > How much RAM do you pass into the guest? Could you please try to > increase that size to see whether it makes a difference? If it > doesn't, Aneesh is your man :) In the test case we used -m 768. I reran the test with -m 2048 -- it crashed the same way. I reran the test with -m 20480 -- it crashed the same way. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/28] target-ppc: Altivec 2.07
On 20.02.2014, at 13:34, Richard W.M. Jones wrote: > On Thu, Feb 20, 2014 at 10:23:42AM +, Richard W.M. Jones wrote: >> I am now running a full libguestfs test which will take several hours, >> but it looks as if -- even if this test fails -- it won't be because >> of lack of emulation / missing instructions in qemu. > > The tests ran. I hit two bugs, but neither seems to be related to > qemu emulation. Please push these patches into upstream qemu :-) They will get into 2.0, no worries :). > One bug is in btrfs and is related to page size being different (and > much larger) on ppc64. I remember bugs (oopses) with btrfs when you use a 4k page size created fs and use it on a 64k page size kernel and vice versa. They still haven't fixed that? > The second bug is kind of interesting. If you add ~ 256 disks (using > virtio-scsi), then it looks as if the firmware crashes. The total > console output is below. It looks as if "c >" is some kind of prompt. > qemu spins using 100% of CPU after this. How much RAM do you pass into the guest? Could you please try to increase that size to see whether it makes a difference? If it doesn't, Aneesh is your man :) Alex
