Re: [Qemu-devel] RFC raspberry pi sd-card reset

Hi, (Sorry for top-posting, just wanted to give you some quick context.) The Pi-specific quirk here is that there are two different SD controllers on the board, both accessing the same card, where only one can be used at a time. IIRC Clement Deschamps added this reparenting logic to

Re: [Qemu-devel] [PATCH] Added periodic IRQ support for bcm2836_control local timer

> From: bzt > Sent: Wednesday, 27 February 2019 03:54 > > I'd like to add more drivers for the bcm283[567] too, and this question goes > to > Andrew Baumann mostly. I've seen implemented those missing drivers in his > repo, which aren't in the qemu mainline yet. I don't want to reinvent the >

Re: [Qemu-devel] [v3 PATCH] hw/arm/bcm2835_peripherals: add bcm283x sp804-alike timer

Hi Mark, > From: Mark > Sent: Sunday, 10 February 2019 08:58 > Subject: [v3 PATCH] hw/arm/bcm2835_peripherals: add bcm283x sp804-alike > timer Thanks for the patch. The integration with bcm2835_peripherals looks good, but hopefully one of the QEMU maintainers can give you a review of the timer

Re: [Qemu-devel] [PATCH for 3.1 v2 1/7] MAINTAINERS: Add an entry for the Raspberry Pi machines

> From: Peter Maydell > Sent: Monday, 5 November 2018 09:58 > > On 5 November 2018 at 17:06, Andrew Baumann > wrote: > > From: Peter Maydell > >> Andrew, as the original submitter of the Raspberry Pi code would you > >> like to be listed as a maintainer for it? > > > > Thanks for asking;

Re: [Qemu-devel] [PATCH for 3.1 v2 1/7] MAINTAINERS: Add an entry for the Raspberry Pi machines

> From: Peter Maydell > Sent: Monday, 5 November 2018 07:26 > > On 2 November 2018 at 00:12, Philippe Mathieu-Daudé > wrote: > > So far the Raspi machines use the BCM2836 SoC which includes a BCM2835 > > for the peripherals. > > > > Signed-off-by: Philippe Mathieu-Daudé > > --- > >

Re: [Qemu-devel] crashes with win2008 host

Thanks for digging into this Fred, and sorry -- it seems Andrey and I both missed that subtlety with TryAcquireSRWLockExclusive when we first made this change. On the other hand, since these OSes are a decade old (mainstream support ended; will drop out of extended support in just over a

Re: [Qemu-devel] crashes with win2008 host

Does this crash always happen at startup? Is it deterministic? c135 is STATUS_DLL_NOT_FOUND. I suspect ntdll is trying to demand-load another DLL to provide that API, and it is missing or corrupt on your Windows installation. BTW, you’ll probably get a better stack trace from a native

Re: [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct CPU type

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > Now we have separate types for BCM2386 and BCM2387, we might as well > just hard-code the CPU type they use rather than having it passed > through as an

Re: [Qemu-devel] [PATCH 5/9] hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > Our BCM2836 type is really a generic one that can be any of > the bcm283x family. Rename it accordingly. We change only > the names which are visible via the

Re: [Qemu-devel] [PATCH 6/9] hw/arm/bcm2836: Create proper bcm2837 device

> From: Peter Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The bcm2837 is pretty similar to the bcm2836, but it does have > some differences. Notably, the MPIDR affinity aff1 values it > sets for the CPUs are 0x0, rather than the 0xf that the bcm2836 > uses, and if

Re: [Qemu-devel] [PATCH 4/9] hw/arm/bcm2386: Fix parent type of bcm2386

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The TypeInfo and state struct for bcm2386 disagree about what the > parent class is -- the TypeInfo says it's TYPE_SYS_BUS_DEVICE, > but the BCM2386State

Re: [Qemu-devel] [PATCH 1/9] hw/arm/raspi: Don't do board-setup or secure-boot for raspi3

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > For the rpi1 and 2 we want to boot the Linux kernel via some > custom setup code that makes sure that the SMC instruction > acts as a no-op, because it's used

Re: [Qemu-devel] [PATCH 7/9] hw/arm/bcm2836: Use correct affinity values for BCM2837

> From: Peter Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The BCM2837 sets the Aff1 field of the MPIDR affinity values for the > CPUs to 0, whereas the BCM2836 uses 0xf. Set this correctly, as it > is required for Linux to boot. > > Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH v3 33/42] hw/arm/bcm2835_peripherals: implement SDHCI Spec v3

> From: Philippe Mathieu-Daudé [mailto:philippe.mathieu.da...@gmail.com] > Sent: Friday, 29 December 2017 09:49 > > Signed-off-by: Philippe Mathieu-Daudé > --- > > Note, the bcm2835 seems to have 1KB minimum blocksize, however the > current > model is implemented with 512B. >

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: bzt bzt [mailto:bztem...@gmail.com] > Sent: Tuesday, 28 November 2017 03:27 > Yes, I agree. I've provided a parameterised version on Oct 24, which does not > have a separate bcm2837 implementation. Is that patch ok? That patch was moving in the right direction, but I think there were two

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Saturday, 25 November 2017 10:05 > On 25 November 2017 at 16:43, bzt bzt wrote: > > Dear Andrew, > > > > A month passed, and the maintainers didn't gave a damn about raspi3 > support > > in qemu. Any ideas? > >

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

> From: Ladi Prosek [mailto:lpro...@redhat.com] > Sent: Tuesday, 7 November 2017 00:11 > > On Mon, Nov 6, 2017 at 7:41 PM, Andrew Baumann > wrote: > > Hi, > > > > I just noticed this thread, and the problem sounded very familiar... > > > >> From: Ladi Prosek > >>

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

Hi, I just noticed this thread, and the problem sounded very familiar... > From: Ladi Prosek > Sent: Monday, 6 November 2017 07:16 [...] > FS base passes all the checks in windbg_on_load() as the guest kernel > loads and it returns true. QEMU then sends some data over the pipe. > Windbg doesn't

[Qemu-devel] [PATCH v4] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. We previously returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guest OSes may depend

Re: [Qemu-devel] [PATCH v3] arm: implement cache/shareability attribute bits for PAR registers

> From: Andrew Baumann > Sent: Tuesday, 31 October 2017 21:02 [...] > +static uint8_t convert_stage2_attrs(CPUARMState *env, uint8_t s2attrs) > +{ > +uint8_t hiattr = extract32(s2attrs, 2, 2); > +uint8_t loattr = extract32(s2attrs, 0, 2); > +uint8_t hihint = 0, lohint = 0; > + > +

[Qemu-devel] [PATCH v3] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. We previously returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guest OSes may depend

Re: [Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 31 October 2017 17:53 > > On 31 October 2017 at 01:23, Andrew Baumann > wrote: > >> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > >> Hi. This is looking pretty good, but I have a few

Re: [Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 31 October 2017 03:25 > > On 20 October 2017 at 22:49, Andrew Baumann > wrote: > > On a successful address translation instruction, PAR is supposed to > > contain cacheability and shareability

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: bzt bzt [mailto:bztem...@gmail.com] > Sent: Tuesday, 24 October 2017 02:54 > On Mon, Oct 23, 2017 at 6:34 PM, Andrew Baumann wrote: > Are there any changes from bcm2836 other than the CPU model? > > > Duplicating the whole file just to have a different CPU seems like a bad >

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: Qemu-devel On Behalf Of bzt bzt > Sent: Sunday, 22 October 2017 06:21 > > I've added support for "-M raspi3" to qemu. This is my first patch, I hope > it's okay. The github repo is here: https://github.com/bztsrc/qemu-raspi3 > in case my patch does not work for some reason. Thanks for

[Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. We previously returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guest OSes may depend

Re: [Qemu-devel] [RFC PATCH] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Thursday, 19 October 2017 09:51 > > On 18 October 2017 at 01:16, Andrew Baumann > wrote: > Hi; thanks for this patch. Looks like you forgot to add your > signed-off-by line. Thanks for the review! I

[Qemu-devel] [RFC PATCH] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. Previous versions of QEMU returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guests may

Re: [Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

> From: Andrew Baumann > Sent: Friday, 13 October 2017 11:19 > > Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should > always turn into atomic 8-byte writes on the host, however if we missed > in the softmmu, and the TLB line was marked as not dirty, then we > would end up

[Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should always turn into atomic 8-byte writes on the host, however if we missed in the softmmu, and the TLB line was marked as not dirty, then we would end up tearing the 8-byte write into two 4-byte writes in

Re: [Qemu-devel] Torn read/write possible on aarch64/x86-64 MTTCG?

> From: Richard Henderson [mailto:rth7...@gmail.com] On Behalf Of Richard > Henderson > Sent: Monday, 24 July 2017 15:03 > > On 07/24/2017 02:23 PM, Emilio G. Cota wrote: > > (Adding some Cc's) > > > > On Mon, Jul 24, 2017 at 19:05:33 +0000, Andrew Baumann vi

[Qemu-devel] Torn read/write possible on aarch64/x86-64 MTTCG?

Hi all, I'm trying to track down what appears to be a translation bug in either the aarch64 target or x86_64 TCG (in multithreaded mode). The symptoms are entirely consistent with a torn read/write -- that is, a 64-bit load or store that was translated to two 32-bit loads and stores -- but

Re: [Qemu-devel] [PATCH 2/2] file-posix: Do runtime check for ofd lock API

> From: Fam Zheng [mailto:f...@redhat.com] > Sent: Friday, 21 July 2017 3:21 > > It is reported that on Windows Subsystem for Linux, ofd operations fail > with -EINVAL. In other words, QEMU binary built with system headers that > exports F_OFD_SETLK doesn't necessarily run in an environment that

Re: [Qemu-devel] Disable image locking for snapshot drive?

w wrote: > > > > On 07/17/2017 07:30 PM, Andrew Baumann via Qemu-devel wrote: > > > >> I'm running a recent Linux build of qemu on Windows Subsystem for > Linux > > > (WSL) which doesn't appear to implement file locking: > > > >> > > > &

Re: [Qemu-devel] Disable image locking for snapshot drive?

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 18 July 2017 8:07 > On 07/17/2017 07:33 PM, John Snow wrote: > > On 07/17/2017 07:30 PM, Andrew Baumann via Qemu-devel wrote: > >> I'm running a recent Linux build of qemu on Windows Subsystem for Linux >

Re: [Qemu-devel] Disable image locking for snapshot drive?

> From: John Snow [mailto:js...@redhat.com] > Sent: Monday, 17 July 2017 17:34 > On 07/17/2017 07:30 PM, Andrew Baumann via Qemu-devel wrote: > > Hi all, > > > > I'm running a recent Linux build of qemu on Windows Subsystem for Linux > (WSL) which doesn't ap

[Qemu-devel] Disable image locking for snapshot drive?

Hi all, I'm running a recent Linux build of qemu on Windows Subsystem for Linux (WSL) which doesn't appear to implement file locking: $ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 -device virtio-blk-pci,drive=hd0 qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0:

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

> From: Andrew Baumann > Sent: Monday, 10 April 2017 10:05 > > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > > Sent: Friday, 7 April 2017 23:13 > > I can't easily find documentation for that 0x4000 memory mapping, > > which I figured I'd keep in; should it just be removed from bcm2835? >

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

> From: Omar Rizwan [mailto:omar.riz...@gmail.com] > Sent: Friday, 7 April 2017 23:13 > On Fri, Apr 7, 2017 at 10:57 PM Andrew Baumann > wrote: > > > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > > > Sent: Friday, 7 April 2017 22:43 > > Did you do any testing

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

Hi Omar, > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > Sent: Friday, 7 April 2017 22:43 Did you do any testing of this? One of the reasons I never got around to upstreaming this was that I couldn't get Raspbian working reliably (there was some problem with stalled DMA reads from the MMC

Re: [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives

> From: Cornelia Huck [mailto:cornelia.h...@de.ibm.com] > Sent: Monday, 3 April 2017 7:20 > > On Fri, 24 Mar 2017 15:01:41 -0700 > Andrew Baumann wrote: > > > From: Andrey Shedel > > > > The multithreaded TCG implementation exposed deadlocks

Re: [Qemu-devel] [PATCH for 2.9?] tap-win32: don't abort in tap_enable(); enables -netdev tap

> From: Jason Wang [mailto:jasow...@redhat.com] > Sent: Tuesday, 28 March 2017 19:39 > > On 2017年03月29日 02:55, Andrew Baumann wrote: > >> From: Stefan Weil [mailto:s...@weilnetz.de] > >> Sent: Tuesday, 28 March 2017 11:28 > >> Am 25.03.2017 um 00:46 schrieb Andrew Baumann: > >>> The docs

Re: [Qemu-devel] [PATCH v3 for-2.9?] virtio: fix vring_align() on 64-bit windows

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 28 March 2017 11:52 > > On 03/28/2017 01:38 PM, Stefan Weil wrote: > > Am 25.03.2017 um 00:19 schrieb Andrew Baumann: > >> long is 32-bits on 64-bit windows, which caused the top half of the > >> address to be truncated; this patch

Re: [Qemu-devel] [PATCH for 2.9?] tap-win32: don't abort in tap_enable(); enables -netdev tap

> From: Stefan Weil [mailto:s...@weilnetz.de] > Sent: Tuesday, 28 March 2017 11:28 > Am 25.03.2017 um 00:46 schrieb Andrew Baumann: > > The docs generally steer users away from using the legacy -net > > parameter, however on win32 attempting to enable a tap device using > > -netdev tap fails at

Re: [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 28 March 2017 10:36 > > Hi; it's been pointed out to me that we have a problem with qemu-devel > unsubscribing people because of DMARC. Specifically: > * microsoft.com publishes a DMARC policy that has p=reject > * some