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

POSIX equivalents. To enable that, it requires a Windows Vista or newer host OS. [AB: edited commit message] Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- The major implication of this patch is that it drops support for pre-Vista versions of Windows. However, those OSes are pa

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

> This patch replaces all the custom synchronisation code for mutexes > > and condition variables with native Windows primitives (SRWlocks and > > condition variables) with the same semantics as their POSIX > > equivalents. To enable that, it requires a Windows Vista or newer host

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

long is 32-bits on 64-bit windows, which caused the top half of the address to be truncated; this patch changes it to use the QEMU_ALIGN_UP macro which does not suffer the same problem Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> Reviewed-by: Eric Blake <ebl...@r

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

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 an abort() in tap_enable(). Removing the abort()s seems to be enough to get everything working, so do that. Signed-off-by: Andrew Baumann

Re: [Qemu-devel] [PATCH for-2.9 v2] virtio: fix vring_align() on 64-bit win32 platforms

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Friday, 24 March 2017 15:20 > So is 'win32' really a 64-bit platform, or should the subject be '64-bit > windows'? Sigh. Yes, ok, it's a little silly if you put it like that. I guess I was thinking of the _WIN32 ifdef and the files named

Re: [Qemu-devel] [PATCH] virtio: fix vring_align() on 64-bit win32 platforms

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 21 March 2017 15:52 > > On 03/21/2017 05:31 PM, Andrew Baumann wrote: > > "long" is 32-bits on win32, but we need to promote it to a 64-bit hwaddr > > before negating, or else the top half of the a

[Qemu-devel] [PATCH] virtio: fix vring_align() on 64-bit win32 platforms

"long" is 32-bits on win32, but we need to promote it to a 64-bit hwaddr before negating, or else the top half of the address is truncated Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- include/hw/virtio/virtio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletio

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

I just noticed this bug via qemu-devel. For the record, recent QEMU (2.11-rc1 and later) can run recent arm64 Windows images using -M virt and the virtio storage/input/networking drivers in the guest. I was using older UEFI build that still includes the VGA framebuffer support. (I only just

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

@Laszlo, I got the binaries from someone else, but they from a parallel build system... nothing particularly special: some preprocessor rules to build against the newer WDK, and also it was just those three drivers (netkvm, vioinput, viostor). I imagine you can get the same result by tweaking the

[PATCH] MAINTAINERS: Remove myself (for raspi).

Signed-off-by: Andrew Baumann --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e4b3a4bcdf..3baa83dfc9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -818,7 +818,6 @@ F: docs/system/arm/palm.rst Raspberry Pi M: Peter Maydell -R: Andrew Baumann

RE: Any example command lines for the RaspberryPi Models

> From: Alex Bennée > > Someone was asking on IRC earlier and I realised we don't give any examples > in the documentation of how to attach block devices. I found a reference in > an out-of-tree repo that mentioned -sd which seems right but I assume you > must be able to use -device sd-card as

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

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

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 > >>

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

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 > <andrew.baum...@microsoft.com> wrote: > > > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > > > Sent: Friday, 7 April 20

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 i

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 <andrew.baum...@microsoft.com> wrote: > > > From: Andrey Shedel <ashe...@microsoft.com> > > > > The mu

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

[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] 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

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] [PATCH 2/2] file-posix: Do runtime check for ofd lock API

t.vhdx,if=none,id=hd0: Failed to unlock > byte 100 > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to lock > byte 100 > > Let's do a runtime check to cope with that. > > Reported-by: Andrew Baumann <andrew.baum...@microsoft.com> > Signed

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 +, 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] Disable image locking for snapshot drive?

> From: Fam Zheng [mailto:f...@redhat.com] > Sent: Wednesday, 19 July 2017 23:53 > > On Tue, 07/18 16:19, Andrew Baumann wrote: > > > From: Eric Blake [mailto:ebl...@redhat.com] > > > Sent: Tuesday, 18 July 2017 8:07 > > > On 07/17/2017 07:33 PM, John Sno

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

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

in access_with_adjusted_size(). Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- This manifested as a race in lock-free synchronisation with an aarch64 Windows guest on an x86-64 host (with multithreaded TCG). exec.c | 13 + 1 file changed, 13 insertions(+) diff --git a/exec.c b/exec.c

[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] 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] 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 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

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 > <andrew.baum...@microsoft.com> wrote: > > Hi, > > > > I just noticed this thread, and the problem sounded very

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

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

on them. This patch collects the attribute bits in the page-table walk, and updates PAR with the correct attributes for all LPAE translations. Short descriptor formats still return 0 for these bits, as in the prior implementation, but now log an unimplemented message. Signed-off-by: Andrew Baumann

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

on them. This patch collects the attribute bits in the page-table walk, and updates PAR with the correct attributes for all LPAE translations. Short descriptor formats still return 0 for these bits, as in the prior implementation. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com>

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 h

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

on them. This patch collects the attribute bits in the page-table walk, and updates PAR with the correct attributes for all LPAE translations. Short descriptor formats still return 0 for these bits, as in the prior implementation. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com>

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 > <andrew.baum...@microsoft.com> wrote: > > On a successful address translation instruction, PAR is supposed to > > cont

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 > <andrew.baum...@microsoft.com> wrote: > >> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > >> Hi. This i

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 > <andrew.baum...@microsoft.com> wrote: > Hi; thanks for this patch. Looks like you forgot to add your > signed-off-by line.

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

*] (c) 2013 Jan Petrous > + * > + * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft > + * Written by Andrew Baumann > + * > + * Raspberry Pi 3 emulation 2017 by bzt > + * > + * This code is licensed under the GNU GPLv2 and later. > + */ > + >

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 7/9] hw/arm/bcm2836: Use correct affinity values for BCM2837

first line of this comment should probably move or just be deleted. It's not relevant here. > * TODO: this should be converted to a property of ARM_CPU > */ > -s->cpus[n].mp_affinity = 0xF00 | n; > +s->cpus[n].mp_affinity = (info->clusterid &

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

etup; > +binfo.secure_board_setup = true; > + binfo.secure_boot = true; > +} > > /* Pi2 and Pi3 requires SMP setup */ > if (version >= 2) { Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com>

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

CM2836_NCPUS; > +mc->max_cpus = BCM283X_NCPUS; > +mc->min_cpus = BCM283X_NCPUS; > +mc->default_cpus = BCM283X_NCPUS; > mc->default_ram_size = 1024 * 1024 * 1024; > mc->ignore_memory_transaction_failures = true; > }; > @@ -212,9 +212,9 @@ static void raspi3_machine_init(MachineClass *mc) > mc->no_floppy = 1; > mc->no_cdrom = 1; > mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"); > -mc->max_cpus = BCM2836_NCPUS; > -mc->min_cpus = BCM2836_NCPUS; > -mc->default_cpus = BCM2836_NCPUS; > +mc->max_cpus = BCM283X_NCPUS; > +mc->min_cpus = BCM283X_NCPUS; > +mc->default_cpus = BCM283X_NCPUS; > mc->default_ram_size = 1024 * 1024 * 1024; > } > DEFINE_MACHINE("raspi3", raspi3_machine_init) Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com>

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

> -object_property_set_str(OBJECT(>soc), machine->cpu_type, "cpu-type", > - _abort); > object_property_set_int(OBJECT(>soc), smp_cpus, "enabled-cpus", > _abort); > int board_rev = version == 3 ? 0xa02082 : 0xa21041; What about the default_cpu_type field of MachineClass set in raspi[23]_machine_init? That seems irrelevant now... Also, if anyone cares (I don't), we also just lost the ability to override the CPU type of a raspi model. Otherwise, Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com> Cheers, Andrew

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

static void bcm2836_class_init(ObjectClass *oc, void > *data) > > static const TypeInfo bcm2836_type_info = { > .name = TYPE_BCM2836, > -.parent = TYPE_SYS_BUS_DEVICE, > +.parent = TYPE_DEVICE, > .instance_size = sizeof(BCM2836State), > .instance_init =

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] [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 maint

Re: [Qemu-devel] crashes with win2008 host

isn’t a great idea either – it fixed a deadlock. Andrew From: KONRAD Frederic Sent: Friday, September 14, 2018 4:17:36 AM To: Andrew Baumann; Andrey Shedel Cc: Paolo Bonzini; QEMU Developers Subject: Re: [Qemu-devel] crashes with win2008 host Ok finally got

Re: [Qemu-devel] crashes with win2008 host

debugger (windbg, etc.) in this scenario. Cheers, Andrew From: KONRAD Frederic Sent: Thursday, September 13, 2018 10:02:56 AM To: Andrey Shedel Cc: Andrew Baumann; Paolo Bonzini; QEMU Developers Subject: crashes with win2008 host Hi Andrey, I've strange

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 d

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] RFC raspberry pi sd-card reset

From: Damien Hedde Sent: Wednesday, July 31, 2019 7:21:02 AM To: QEMU Developers Cc: Peter Maydell ; Andrew Baumann ; f4...@amsat.org ; qemu-arm Subject: RFC raspberry pi sd-card reset Hi, Concerning the reset on the raspi2/3 machine, I ran into an issue with the sd-card

<    1   2   3