[PATCH v2] hvf: use standard CR0 and CR4 register definitions

Signed-off-by: Cameron Esfahani --- v2: + Fix duplicate line Roman Bolshakov found in review. --- target/i386/cpu.h | 2 ++ target/i386/hvf/hvf.c | 2 +- target/i386/hvf/vmx.h | 15 --- target/i386/hvf/x86.c | 6 +++--- target/i386/hvf/x86.h | 34

[PATCH v2] nrf51: Fix last GPIO CNF address

NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last valid CNF register: it's referring to the last byte of the last valid CNF register. This hasn't been a problem up to now, as current implementation in memory.c turns an unaligned 4-byte read from 0x77f to a single byte read

Re: [PATCH v2 07/12] acpi: move aml builder code for rtc device

I'm curious why there's two ranges as well. In our branch of QEMU, I've had to modify this RTC creation code to have only one range instead of two ranges. Traditionally Macs have had one range for RTC and we have incompatibility with a two ranges. If you could change it to one range without

Re: [PATCH v1 2/3] hvf: Make long mode enter and exit code clearer.

I'll update with your feedback. Cameron Esfahani di...@apple.com "We do what we must because we can." Aperture Science > On Apr 5, 2020, at 11:51 AM, Roman Bolshakov wrote: > > On Mon, Mar 30, 2020 at 05:16:05PM -0700, Cameron Esfahani wrote: >> Signed-off-by: Cameron Esfahani >> --- >>

Re: [PATCH v1 1/3] hvf: use standard CR0 and CR4 register definitions

Responses inline Cameron Esfahani di...@apple.com "We do what we must because we can." Aperture Science > On Apr 5, 2020, at 10:58 AM, Roman Bolshakov wrote: > > On Mon, Mar 30, 2020 at 05:16:04PM -0700, Cameron Esfahani wrote: >> Signed-off-by: Cameron Esfahani >> --- >>

Re: [PATCH v1] nrf51: Fix last GPIO CNF address

I'm not burying anything. This patch is stand alone and all the tests do work. They work with or without Cedric's nee Andrew's patch. But, if some derivative of that patch is eventually implemented, something needs to be done for this NRF51 gpio qtest to work. There are two possibilities

[PATCH v1] nrf51: Fix last GPIO CNF address

NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last valid CNF register: it's referring to the last byte of the last valid CNF register. This hasn't been a problem up to now, as current implementation in memory.c turns an unaligned 4-byte read from 0x77f to a single byte read

Re: [PATCH v1] usb: Add read support for HCIVERSION register to XHCI

n steps of 2-bytes. >>> >>> But I'll defer to Gerd on this... >>> >>> Cameron Esfahani >>> di...@apple.com >>> >>> "Americans are very skilled at creating a custom meaning from something >>> that's mass-produced." >>>

Re: [PATCH v1] usb: Add read support for HCIVERSION register to XHCI

for any of the 4-byte fields... Cameron Esfahani di...@apple.com "In the elder days of Art, Builders wrought with greatest care each minute and unseen part; For the gods see everywhere." "The Builders", H. W. Longfellow > On Mar 31, 2020, at 2:57 AM, Cameron Esfahani via

Re: [PATCH v1] usb: Add read support for HCIVERSION register to XHCI

cans are very skilled at creating a custom meaning from something that's mass-produced." Ann Powers > On Mar 31, 2020, at 12:52 AM, Philippe Mathieu-Daudé > wrote: > > On 3/30/20 11:44 PM, Cameron Esfahani via wrote: >> macOS will read HCIVERSION separate from CAPLENGTH.

Re: [PATCH] i386: hvf: Reset IRQ inhibition after moving RIP

Reviewed-by: Cameron Esfahani LGTM. Cameron Esfahani di...@apple.com "There are times in the life of a nation when the only place a decent man can find himself is in prison." > On Mar 28, 2020, at 10:44 AM, Roman Bolshakov wrote: > > The sequence of instructions exposes an issue: > sti

[PATCH v1 3/3] hvf: Support AVX512 guests on capable hardware

macOS lazily enables AVX512. Explicitly enable it if the processor supports it. cpu_x86_cpuid() tries to handle OSXSAVE but refers to env->cr[4] for the guest copy of CR4. HVF doesn't support caching CPUID values like KVM, so we need to track it ourselves. Signed-off-by: Cameron Esfahani ---

[PATCH v1 1/3] hvf: use standard CR0 and CR4 register definitions

Signed-off-by: Cameron Esfahani --- target/i386/cpu.h | 2 ++ target/i386/hvf/hvf.c | 1 + target/i386/hvf/vmx.h | 15 --- target/i386/hvf/x86.c | 6 +++--- target/i386/hvf/x86.h | 34 -- target/i386/hvf/x86_mmu.c | 2

[PATCH v1 0/3] hvf: Support AVX512 guests and cleanup

HVF had its own copy of the CR0 and CR4 register definitions. Remove them in favor of the definitions in target/i386/cpu.h. Change long mode enter and exit code to be clearer. Support AVX512 guests on capable hardware. This involves two separate changes: - Correctly manage the OSXSAVE bit in

[PATCH v1 2/3] hvf: Make long mode enter and exit code clearer.

Signed-off-by: Cameron Esfahani --- target/i386/hvf/vmx.h | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h index 8ec2e6414e..1a1b150c97 100644 --- a/target/i386/hvf/vmx.h +++ b/target/i386/hvf/vmx.h @@ -121,6 +121,7 @@

[PATCH v1] usb: Add read support for HCIVERSION register to XHCI

macOS will read HCIVERSION separate from CAPLENGTH. Add a distinct handler for that register. Signed-off-by: Cameron Esfahani --- hw/usb/hcd-xhci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c index b330e36fe6..061f8438de 100644 ---

Re: [PATCH 04/11] MAINTAINERS: Add an entry for the HVF accelerator

Please add me to the HVF maintainers as well. Cameron Esfahani di...@apple.com "In the elder days of Art, Builders wrought with greatest care each minute and unseen part; For the gods see everywhere." "The Builders", H. W. Longfellow > On Mar 16, 2020, at 5:00 AM, Philippe Mathieu-Daudé

Re: [PATCH 04/11] MAINTAINERS: Add an entry for the HVF accelerator

Sorry I didn't see this yesterday. We've (Apple) signed up for taking over HVF ownership. I didn't realize I needed to add to the MAINTAINERS list. Roman, we also have a bunch of pending fixes for some of the issues you've listed. We're in the process of upstreaming them. Cameron Esfahani

[PATCH v2 2/2] vnc: prioritize ZRLE compression over ZLIB

In my investigation, ZRLE always compresses better than ZLIB so prioritize ZRLE over ZLIB, even if the client hints that ZLIB is preferred. zlib buffer is always reset in zrle_compress_data(), so using offset to calculate next_out and avail_out is useless. Signed-off-by: Cameron Esfahani ---

[PATCH v2 0/2] vnc: fix VNC artifacts

Remove VNC optimization to reencode framebuffer update as raw if it's smaller than the default encoding. QEMU's implementation was naive and didn't account for the ZLIB z_stream mutating with each compression. Just saving and restoring the output buffer offset wasn't sufficient to "rewind" the

[PATCH v2 1/2] vnc: fix VNC artifacts

Patch de3f7de7f4e257ce44cdabb90f5f17ee99624557 was too simplistic in its implementation: it didn't account for the ZLIB z_stream mutating with each compression. Because of the mutation, simply resetting the output buffer's offset wasn't sufficient to "rewind" the operation. The mutated z_stream

Re: [PATCH v1] vnc: fix VNC artifacts

I’m new to this process, what are the next steps? Cameron Esfahani di...@apple.com > On Jan 16, 2020, at 11:47 PM, Gerd Hoffmann wrote: > > On Thu, Jan 16, 2020 at 07:50:58PM -0800, Cameron Esfahani wrote: >> Remove VNC optimization to reencode framebuffer update as raw if it's >> smaller

Re: [PATCH v1] vnc: fix VNC artifacts

Yes. Personally, I'd also take the change to vnc-enc-zrle.c: because vs->zrle->zlib is reset at the top of the function, using vs->zrle->zlib.offset in determining zstream->next_out and zstream->avail_out is useless. Cameron Esfahani di...@apple.com "All that is necessary for the triumph of

[PATCH v1] vnc: fix VNC artifacts

Remove VNC optimization to reencode framebuffer update as raw if it's smaller than the default encoding. QEMU's implementation was naive and didn't account for the ZLIB z_stream mutating with each compression. Just saving and restoring the output buffer offset wasn't sufficient to "rewind" the

Re: [Bug 1818937] Crash with HV_ERROR on macOS host

Try against 4.2. Cameron Esfahani di...@apple.com "In the elder days of Art, Builders wrought with greatest care each minute and unseen part; For the gods see everywhere." "The Builders", H. W. Longfellow > On Dec 30, 2019, at 8:41 AM, Alex Fliker > wrote: > > Are there any updates?

Re: [PATCH v3 0/1] Fix bochs memory leak

Ping. Cameron Esfahani di...@apple.com "Americans are very skilled at creating a custom meaning from something that's mass-produced." Ann Powers > On Dec 12, 2019, at 12:30 AM, Cameron Esfahani via > wrote: > > Fix a small memory leak in the Bochs display driver.

[PATCH v3 0/1] Fix bochs memory leak

Fix a small memory leak in the Bochs display driver. Each frame would leak about 304 bytes. v2: Add missing signed-off-by line. v3: Add reviewed-by and fixes lines. Cameron Esfahani (1): display/bochs-display: fix memory leak hw/display/bochs-display.c | 2 ++ 1 file changed, 2

[PATCH v3 1/1] display/bochs-display: fix memory leak

Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame. Fixes: 33ebad54056 Signed-off-by: Cameron Esfahani Reviewed-by: Philippe Mathieu-Daudé --- hw/display/bochs-display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/display/bochs-display.c

[PATCH v2 0/1] Fix bochs memory leak

Fix a small memory leak in the Bochs display driver. Each frame would leak about 304 bytes. v2: Add missing signed-off-by line. Cameron Esfahani (1): display/bochs-display: fix memory leak hw/display/bochs-display.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.24.0

[PATCH v2 1/1] display/bochs-display: fix memory leak

Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame. Signed-off-by: Cameron Esfahani --- hw/display/bochs-display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/display/bochs-display.c b/hw/display/bochs-display.c index dc1bd1641d..215db9a231 100644 ---

[PATCH v1 1/1] display/bochs-display: fix memory leak

Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame. --- hw/display/bochs-display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/display/bochs-display.c b/hw/display/bochs-display.c index dc1bd1641d..215db9a231 100644 --- a/hw/display/bochs-display.c +++

[PATCH v1 0/1] Fix bochs memory leak

Fix a small memory leak in the Bochs display driver. Each frame would leak about 304 bytes. Cameron Esfahani (1): display/bochs-display: fix memory leak hw/display/bochs-display.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.24.0

[PATCH v2] Fix some comment spelling errors.

Signed-off-by: Cameron Esfahani Reviewed-by: Stefan Weil --- target/i386/machine.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/target/i386/machine.c b/target/i386/machine.c index 2699eed94e..ee342ddd50 100644 --- a/target/i386/machine.c +++

[PATCH] Fix some comment spelling errors.

Signed-off-by: Cameron Esfahani --- target/i386/machine.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/i386/machine.c b/target/i386/machine.c index 2699eed94e..f21823f179 100644 --- a/target/i386/machine.c +++ b/target/i386/machine.c @@ -261,7 +261,7 @@ static

[PATCH v3 1/5] hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in

If an area is non-RAM and non-ROMD, then remove mappings so accesses will trap and can be emulated. Change hvf_find_overlap_slot() to take a size instead of an end address: it wouldn't return a slot because callers would pass the same address for start and end. Don't always map area as

[PATCH v3 2/5] hvf: remove TSC synchronization code because it isn't fully complete

The existing code in QEMU's HVF support to attempt to synchronize TSC across multiple cores is not sufficient. TSC value on other cores can go backwards. Until implementation is fixed, remove calls to hv_vm_sync_tsc(). Pass through TSC to guest OS. Signed-off-by: Cameron Esfahani

[PATCH v3 4/5] hvf: more accurately match SDM when setting CR0 and PDPTE registers

More accurately match SDM when setting CR0 and PDPTE registers. Clear PDPTE registers when resetting vcpus. Signed-off-by: Cameron Esfahani Signed-off-by: Paolo Bonzini --- target/i386/hvf/hvf.c | 8 target/i386/hvf/vmx.h | 18 ++ 2 files changed, 18 insertions(+), 8

[PATCH v3 0/5] hvf: stability fixes for HVF

The following patches fix stability issues with running QEMU on Apple Hypervisor Framework (HVF): - non-RAM, non-ROMD areas need to trap so accesses can be correctly emulated. - Current TSC synchronization implementation is insufficient: when running with more than 1 core, TSC values can go

[PATCH v3 5/5] hvf: correctly inject VMCS_INTR_T_HWINTR versus VMCS_INTR_T_SWINTR.

Previous implementation in hvf_inject_interrupts() would always inject VMCS_INTR_T_SWINTR even when VMCS_INTR_T_HWINTR was required. Now correctly determine when VMCS_INTR_T_HWINTR is appropriate versus VMCS_INTR_T_SWINTR. Make sure to clear ins_len and has_error_code when ins_len isn't valid

[PATCH v3 3/5] hvf: correctly handle REX prefix in relation to legacy prefixes

In real x86 processors, the REX prefix must come after legacy prefixes. REX before legacy is ignored. Update the HVF emulation code to properly handle this. Fix some spelling errors in constants. Fix some decoder table initialization issues found by Coverity. Signed-off-by: Cameron Esfahani

Re: [PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them

So far so good. Without any workaround, I could get it to fail within a few seconds. With your change, I've been running for a few minutes without a problem. But, this is on my laptop, so I'll wait until I can test it on a wider-range of machines at work next week. If it continues to work,

Re: [PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them

Cameron Esfahani di...@apple.com "Americans are very skilled at creating a custom meaning from something that's mass-produced." Ann Powers > On Nov 26, 2019, at 12:04 PM, Cameron Esfahani via > wrote: > > Our test case was booting many concurrent macOS VMs under heav

Re: [PATCH v2 0/5] hvf: stability fixes for HVF

Let me see if I can add some assertions. Cameron Esfahani di...@apple.com "The cake is a lie." Common wisdom > On Nov 25, 2019, at 2:28 AM, Paolo Bonzini wrote: > > Certainly no doubt about patches 1-4, while for patch 5 I'm wondering if > it's masking another bug; I'd prefer to have also

Re: [PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them

Our test case was booting many concurrent macOS VMs under heavy system load. I don't know if I could create one to replicate that. Cameron Esfahani di...@apple.com "In the elder days of Art, Builders wrought with greatest care each minute and unseen part; For the gods see everywhere." "The

[PATCH v2 4/5] hvf: more accurately match SDM when setting CR0 and PDPTE registers

More accurately match SDM when setting CR0 and PDPTE registers. Clear PDPTE registers when resetting vcpus. Signed-off-by: Cameron Esfahani --- target/i386/hvf/hvf.c | 8 target/i386/hvf/vmx.h | 18 ++ 2 files changed, 18 insertions(+), 8 deletions(-) diff --git

[PATCH v2 1/5] hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in

If an area is non-RAM and non-ROMD, then remove mappings so accesses will trap and can be emulated. Change hvf_find_overlap_slot() to take a size instead of an end address: it wouldn't return a slot because callers would pass the same address for start and end. Don't always map area as

[PATCH v2 0/5] hvf: stability fixes for HVF

The following patches fix stability issues with running QEMU on Apple Hypervisor Framework (HVF): - non-RAM, non-ROMD areas need to trap so accesses can be correctly emulated. - Current TSC synchronization implementation is insufficient: when running with more than 1 core, TSC values can go

[PATCH v2 2/5] hvf: remove TSC synchronization code because it isn't fully complete

The existing code in QEMU's HVF support to attempt to synchronize TSC across multiple cores is not sufficient. TSC value on other cores can go backwards. Until implementation is fixed, remove calls to hv_vm_sync_tsc(). Pass through TSC to guest OS. Signed-off-by: Cameron Esfahani ---

[PATCH v2 3/5] hvf: correctly handle REX prefix in relation to legacy prefixes

In real x86 processors, the REX prefix must come after legacy prefixes. REX before legacy is ignored. Update the HVF emulation code to properly handle this. Fix some spelling errors in constants. Fix some decoder table initialization issues found by Coverity. Signed-off-by: Cameron Esfahani

[PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them

Save away type as well as vector in hvf_store_events() so we can correctly reinject both in hvf_inject_interrupts(). Make sure to clear ins_len and has_error_code when ins_len isn't valid and error_code isn't set. Signed-off-by: Cameron Esfahani --- target/i386/hvf/hvf.c| 18

[PATCH 4/5] hvf: more accurately match SDM when setting CR0 and PDPTE registers

More accurately match SDM when setting CR0 and PDPTE registers. Clear PDPTE registers when resetting vcpus. Signed-off-by: Cameron Esfahani --- target/i386/hvf/hvf.c | 8 target/i386/hvf/vmx.h | 18 ++ 2 files changed, 18 insertions(+), 8 deletions(-) diff --git

[PATCH 3/5] hvf: correctly handle REX prefix in relation to legacy prefixes

In real x86 processors, the REX prefix must come after legacy prefixes. REX before legacy is ignored. Update the HVF emulation code to properly handle this. Fix some spelling errors in constants. Fix some decoder table initialization issues found by Coverity. Signed-off-by: Cameron Esfahani

[PATCH 1/5] hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in

If an area is non-RAM and non-ROMD, then remove mappings so accesses will trap and can be emulated. Change hvf_find_overlap_slot() to take a size instead of an end address: it wouldn't return a slot because callers would pass the same address for start and end. Don't always map area as

[PATCH 5/5] hvf: save away type as well as vector so we can reinject them

Save away type as well as vector in hvf_store_events() so we can correctly reinject both in hvf_inject_interrupts(). Make sure to clear ins_len and has_error_code when ins_len isn't valid and error_code isn't set. Signed-off-by: Cameron Esfahani --- target/i386/hvf/hvf.c| 16

[PATCH 0/5] hvf: stability fixes for HVF

The following patches fix stability issues with running QEMU on Apple Hypervisor Framework (HVF): - non-RAM, non-ROMD areas need to trap so accesses can be correctly emulated. - Current TSC synchronization implementation is insufficient: when running with more than 1 core, TSC values can go

[PATCH 2/5] hvf: remove TSC synchronization code because it isn't fully complete

The existing code in QEMU's HVF support to attempt to synchronize TSC across multiple cores is not sufficient. TSC value on other cores can go backwards. Until implementation is fixed, remove calls to hv_vm_sync_tsc(). Pass through TSC to guest OS. Signed-off-by: Cameron Esfahani ---