[Qemu-devel] [PULL v1 00/21] Multi-arch queue

2015-09-10 Thread Peter Crosthwaite
Flush of multi-arch pre-requisite work. multi-arch queue: * add EM_MOXIE * Cleanup ELF_MACHINE and remove from cpu.h The following changes since commit 9d34158a5af734e8de0b42b0a7228200c426a8d0: Merge remote-track

[Qemu-devel] [PULL v1 12/21] or32: Remove ELF_MACHINE from cpu.h

2015-09-10 Thread Peter Crosthwaite
From: Peter Crosthwaite The only generic code relying on this is linux-user, but linux users' default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle this. The bootloader can just pass EM_OPENRISC directly, as that is architecture specific code. This removes another architecture spe

[Qemu-devel] [PULL v1 13/21] tricore: Remove ELF_MACHINE from cpu.h

2015-09-10 Thread Peter Crosthwaite
From: Peter Crosthwaite The bootloader can just pass EM_TRICORE directly, as that is architecture specific code. This removes another architecture specific definition from the global namespace. Cc: Bastian Koppelmann Acked-By: Bastian Koppelmann Reviewed-by: Richard Henderson Acked-By: Riku

[Qemu-devel] [PULL v1 18/21] mips: Remove ELF_MACHINE from cpu.h

2015-09-10 Thread Peter Crosthwaite
From: Peter Crosthwaite The only generic code relying on this is linux-user, but linux users' default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle this. The bootloaders can just pass EM_MIPS directly, as that is architecture specific code. This removes another architecture specif

[Qemu-devel] [PULL v1 15/21] sh4: Remove ELF_MACHINE from cpu.h

2015-09-10 Thread Peter Crosthwaite
From: Peter Crosthwaite The only generic code relying on this is linux-user, but linux users' default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle this. This removes another architecture specific definition from the global namespace. Cc: Aurelien Jarno Acked-by: Aurelien Jarno

Re: [Qemu-devel] [PATCH v17 00/21] Deterministic replay core

2015-09-10 Thread Pavel Dovgaluk
Paolo, Are these patches good enough? Pavel Dovgalyuk > -Original Message- > From: Pavel Dovgalyuk [mailto:pavel.dovga...@ispras.ru] > Sent: Monday, September 07, 2015 11:40 AM > To: qemu-devel@nongnu.org > Cc: edgar.igles...@xilinx.com; peter.mayd...@linaro.org; > igor.rubi...@gmail.co

Re: [Qemu-devel] [PATCH v17 00/21] Deterministic replay core

2015-09-10 Thread Paolo Bonzini
On 11/09/2015 07:52, Pavel Dovgaluk wrote: > Paolo, > > Are these patches good enough? Haven't reviewed them as I already have a 50 patch queue. I will look at them next week. I can already tell you that I'd like some comments in front of clock warp calls, but that can be added as a follow up

Re: [Qemu-devel] [RFC PATCH v1 00/25] error: Automatic error concatenation and prefixing

2015-09-10 Thread Markus Armbruster
Quick initial high-level feedback, since I'm afraid real review will take a while (series is long, and I'm still swamped). Peter Crosthwaite writes: > Hi Markus and all, > > This patch series adds support for automatically concatenating multiple > errors to the one Error *. > > I'll start with w

Re: [Qemu-devel] Aspirant for AMD IOMMU emulation project for Outreachy

2015-09-10 Thread Jan Kiszka
Hi Rita, [CC'ing Andrew due to overlap with split irqchip topic] On 2015-09-09 19:41, Rita Sinha wrote: > Hi Jan, > >> >> Most likely than not you'll work on the Intel IOMMU and I would >> suggest, if you wish to get your feet dirty, just start right away >> with the Intel IOMMU (In which case J

Re: [Qemu-devel] [PATCH] ide: fix ATAPI command permissions

2015-09-10 Thread Michael Tokarev
09.09.2015 19:28, John Snow wrote: > We're a little too lenient with what we'll let an ATAPI drive handle. > Clamp down on the IDE command execution table to remove CD_OK permissions > from commands that are not and have never been ATAPI commands. FWIW, this issue has been assigned CVE-2015-6855 i

Re: [Qemu-devel] Aspirant for AMD IOMMU emulation project for Outreachy

2015-09-10 Thread Jan Kiszka
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-09-11 08:50, Jan Kiszka wrote: > Hi Rita, > > [CC'ing Andrew due to overlap with split irqchip topic] > > On 2015-09-09 19:41, Rita Sinha wrote: >> Hi Jan, >> >>> >>> Most likely than not you'll work on the Intel IOMMU and I would >>> sugge

<    1   2   3   4   5