Page MenuHomeFreeBSD

pmooney_pfmooney.com (Patrick Mooney)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 26 2018, 6:21 PM (72 w, 5 d)

Recent Activity

Aug 16 2019

pmooney_pfmooney.com added a comment to D20389: bhyve vioapic writes can deadlock instance.

After discussion with @markj and @jhb, I drafted up a change which involves using an sxlock to guard against racing vioapic writes while allowing the main vioapic mutex to be dropped during the sensitive portion of the TMR update process. I don't have test hardware I can dedicate to running FreeBSD bhyve, so its performance is speculative.

Aug 16 2019, 8:00 PM · bhyve

Aug 13 2019

pmooney_pfmooney.com added a comment to D20389: bhyve vioapic writes can deadlock instance.

Thanks for pointing that out @markj. This wasn't a problem in SmartOS bhyve since all of the mutexes there are adaptive, rather than spinlocks. (Due to interface differences, we couldn't guarantee a lack of voluntary context switching inside the critical_enter/critical_exit section, and spinlocks came with their own host of deadlock problems.) Considering the constraints in play on the FreeBSD side, I'm not sure this possible without serious restructuring. The vioapic lock would need to be sleeping, so the EOI processing would require a full exit from the VMRUN critical section. Other consumers (hpet, etc) would probably require similar treatment.

Aug 13 2019, 8:32 PM · bhyve

Jul 24 2019

pmooney_pfmooney.com added a reviewer for D20365: simplify bhyve vlapic ESR logic: markj.
Jul 24 2019, 3:20 PM · bhyve
pmooney_pfmooney.com added a reviewer for D20389: bhyve vioapic writes can deadlock instance: markj.
Jul 24 2019, 3:19 PM · bhyve
pmooney_pfmooney.com added a comment to D21053: Simplify capsicumization of bhyve (cont'd).

You're correct that illumos bhyve is not being built with any kind of Capsicum support. If the WITHOUT_CAPSICUM guards are removed, we'll just shim the cap_/caph_ interfaces as successful no-ops.

Jul 24 2019, 1:22 PM

Jul 23 2019

D21036: vmx: use C99 bool, not boolean_t is now accepted and ready to land.

Looks good, with all of @kib's comments addressed.

Jul 23 2019, 3:12 PM

Jul 17 2019

pmooney_pfmooney.com added inline comments to D19495: bhyve - Snapshot Save and Restore.
Jul 17 2019, 10:15 PM · bhyve

Jul 16 2019

pmooney_pfmooney.com added inline comments to D20973: bhyve: support for enabling/disabling the net backend.
Jul 16 2019, 5:15 PM

Jul 2 2019

pmooney_pfmooney.com added inline comments to D19495: bhyve - Snapshot Save and Restore.
Jul 2 2019, 9:22 PM · bhyve

Jun 26 2019

D20755: Emulate the TEST instruction with opcode F7 /0. is now accepted and ready to land.
Jun 26 2019, 8:41 PM
pmooney_pfmooney.com added a comment to D20755: Emulate the TEST instruction with opcode F7 /0..

Looks good, once the 7F->F7 fix is made.

Jun 26 2019, 7:31 PM

Jun 24 2019

pmooney_pfmooney.com added a comment to D20389: bhyve vioapic writes can deadlock instance.

Merged downstream in SmartOS as ec6f18e9

Jun 24 2019, 3:07 PM · bhyve

Jun 18 2019

pmooney_pfmooney.com added a comment to D19495: bhyve - Snapshot Save and Restore.

I agree with @jhb that this absolutely should be placed behind #ifdef guards for now.

Jun 18 2019, 6:09 PM · bhyve
pmooney_pfmooney.com added a comment to D20389: bhyve vioapic writes can deadlock instance.

Rebased to reflect upstream changes

Jun 18 2019, 2:15 PM · bhyve

Jun 10 2019

pmooney_pfmooney.com accepted D20581: bhyve: virtio: introduce vq_kick_enable() and vq_kick_disable().
Jun 10 2019, 8:40 PM
pmooney_pfmooney.com accepted D20581: bhyve: virtio: introduce vq_kick_enable() and vq_kick_disable().
Jun 10 2019, 8:34 PM
pmooney_pfmooney.com added inline comments to D20581: bhyve: virtio: introduce vq_kick_enable() and vq_kick_disable().
Jun 10 2019, 7:37 PM
pmooney_pfmooney.com added a comment to D20365: simplify bhyve vlapic ESR logic.

Merged downstream in SmartOS as aa2898c4.

Jun 10 2019, 2:16 PM · bhyve

Jun 5 2019

pmooney_pfmooney.com accepted D20523: Don't simulate PBA access if the PBA is in a separate BAR..
Jun 5 2019, 4:46 PM

Jun 1 2019

pmooney_pfmooney.com updated the diff for D20365: simplify bhyve vlapic ESR logic.

Eliminate the ILLEGAL_VECTOR qualification in vlapic_set_error per @jhb's feedback and rebase.

Jun 1 2019, 12:10 AM · bhyve

May 23 2019

pmooney_pfmooney.com created D20389: bhyve vioapic writes can deadlock instance.
May 23 2019, 8:55 PM · bhyve
pmooney_pfmooney.com added inline comments to D20365: simplify bhyve vlapic ESR logic.
May 23 2019, 5:29 PM · bhyve

May 22 2019

pmooney_pfmooney.com updated the diff for D20365: simplify bhyve vlapic ESR logic.

Fix excess whitespace and add attribution

May 22 2019, 10:53 PM · bhyve
pmooney_pfmooney.com created D20365: simplify bhyve vlapic ESR logic.
May 22 2019, 8:29 PM · bhyve

May 21 2019

pmooney_pfmooney.com created D20335: bhyve could be more precise with vPIT.
May 21 2019, 5:37 PM · bhyve

May 17 2019

pmooney_pfmooney.com created D20296: bhyve should expose MD_CLEAR capability.
May 17 2019, 7:11 PM · bhyve
pmooney_pfmooney.com updated the diff for D19501: bhyve virtio needs barriers.

Fixed include ordering per @kib's comment.

May 17 2019, 4:19 PM
pmooney_pfmooney.com added inline comments to D19501: bhyve virtio needs barriers.
May 17 2019, 4:18 PM
pmooney_pfmooney.com updated the diff for D19501: bhyve virtio needs barriers.

Added missing atomics header

May 17 2019, 3:28 PM

May 7 2019

pmooney_pfmooney.com updated the diff for D19501: bhyve virtio needs barriers.

Implemented @kib's suggestions.

May 7 2019, 9:11 PM
pmooney_pfmooney.com added a comment to D19501: bhyve virtio needs barriers.

I'm fine with @kib's suggested changes, with the caveat that we (Joyent) only positively tested the mfence version.

May 7 2019, 5:37 PM

May 3 2019

pmooney_pfmooney.com abandoned D19499: bhyve uart broken for win2016 guest.

This issue was addressed when it was effectively side-pulled in commit #345158, despite having been posted here and accepted a week prior.

May 3 2019, 5:04 PM · bhyve

Mar 9 2019

pmooney_pfmooney.com accepted D19506: Fix bug in bhyve by ignoring writes to errata MSRs in AMD cpus.

I think this fix is good for the short term. I can confirm seeing failed writes to that MSR when running a Linux guest on Zen hardware (which were non-fatal to Linux).

Mar 9 2019, 5:17 PM · bhyve

Mar 7 2019

pmooney_pfmooney.com created D19501: bhyve virtio needs barriers.
Mar 7 2019, 8:48 PM
pmooney_pfmooney.com created D19499: bhyve uart broken for win2016 guest.
Mar 7 2019, 8:42 PM · bhyve

Feb 28 2019

pmooney_pfmooney.com added a comment to D19299: bhyve can miss PIR wake-ups.

Yes, he was concerned about my use of the reserved bits. For a VMX-only case, it was probably fine, but if we ever want PCI-passthru to post interrupts directly to the guest, we'll need those bits. The write-up for OS-7354, which switched to the separate pending_prio field, covers the reasoning.

Feb 28 2019, 5:54 PM · bhyve

Feb 27 2019

pmooney_pfmooney.com accepted D18755: Add accessor for vm->maxcpus in preperation for run time maxcpu setting.
Feb 27 2019, 10:33 PM
pmooney_pfmooney.com added a comment to D19299: bhyve can miss PIR wake-ups.

We do, in a sense, clear those bits on interrupt delivering since it involves clearing the pending bit, meaning the next 0 -> 1 transition would incur a clean of pending_prio. Clearing the lower bits in pending_prio as part of vmx_pending_intr carries no risk of incurring extra work, since interrupt notification is triggered from having an incoming prio greater than what is cached in pending_prio. Besides, spurious wake-ups from the HLT loop to check for interrupts are much preferred to missing one.

Feb 27 2019, 9:23 PM · bhyve
pmooney_pfmooney.com updated the diff for D19299: bhyve can miss PIR wake-ups.

Fixed copyright attribution per Rod's comment.

Feb 27 2019, 8:46 PM · bhyve
pmooney_pfmooney.com updated the diff for D19299: bhyve can miss PIR wake-ups.

Updated diff to include full context

Feb 27 2019, 8:40 PM · bhyve
pmooney_pfmooney.com added inline comments to D19299: bhyve can miss PIR wake-ups.
Feb 27 2019, 8:38 PM · bhyve

Feb 22 2019

pmooney_pfmooney.com added a comment to D19299: bhyve can miss PIR wake-ups.

I used git format-patch assuming phabricator would pick up on the context stuff, but apparently not. I'll be sure to increase the context for the next revision.

Feb 22 2019, 11:27 PM · bhyve
pmooney_pfmooney.com created D19299: bhyve can miss PIR wake-ups.
Feb 22 2019, 10:33 PM · bhyve
pmooney_pfmooney.com added inline comments to D18755: Add accessor for vm->maxcpus in preperation for run time maxcpu setting.
Feb 22 2019, 6:35 PM
pmooney_pfmooney.com accepted D18815: Bhyve acpi MADT table correction for VM_MAXCPU > 21.
Feb 22 2019, 6:10 PM
pmooney_pfmooney.com added inline comments to D18755: Add accessor for vm->maxcpus in preperation for run time maxcpu setting.
Feb 22 2019, 6:08 PM
pmooney_pfmooney.com accepted D18998: Make bhyve SMBIOS table topology aware.
Feb 22 2019, 5:54 PM

Feb 14 2019

pmooney_pfmooney.com accepted D19202: bhyve(8) pci_xhci.c elliminate possible double free of uopt.

This is the fix we're applying to SmartOS bhyve, after syncing from upstream.

Feb 14 2019, 8:02 PM
pmooney_pfmooney.com accepted D19200: bhyve(8) block_if.c remove multiple freeing of nopt added in r340042.

This is the fix we're applying to SmartOS bhyve, after syncing from upstream.

Feb 14 2019, 7:32 PM

Jan 24 2019

pmooney_pfmooney.com added a comment to D18816: bhyve vmm statistics tables need to be sized relative to VM_MAXCPU.

That stores the type definitions for the statistics. Storage of the actual statistic data should still be per-vcpu, hung off of struct vcpu`stats. Requiring a type definition per-vcpu doesn't make sense in that case.

Jan 24 2019, 9:35 PM
pmooney_pfmooney.com added a comment to D18816: bhyve vmm statistics tables need to be sized relative to VM_MAXCPU.

Since the statistic tables are allocated on a per-vCPU basis already, it doesn't make sense to me why the tables themselves need to be expanded like this.

Jan 24 2019, 8:55 PM

Jan 13 2019

pmooney_pfmooney.com added a comment to D18831: Increase bhyve BLOCKIF_IOV_MAX and VTBLK_RINGSZ to 128 to support modern Windows guests.

This is effectively what we did in SmartOS/illumos to address the issue:
https://github.com/joyent/illumos-joyent/commit/192e1e6405f98e4b0a12f9488793c5dd000f3f7e

Jan 13 2019, 11:19 PM · bhyve

Jan 8 2019

pmooney_pfmooney.com added a comment to D18755: Add accessor for vm->maxcpus in preperation for run time maxcpu setting.

re-write the code using an accessor function (called vmm_vm_maxcpus()) to vmm.c that does the vmx->vm->maxcpus dereference and call that. The most common use of this is in vmm.c itself, and would probably end up inlined by the compiler anyway, though there are at least 4 other files that have the need for this, and iirc there is userland code that uses the VM_MAXCPU constant that needs to NOT do that!

Jan 8 2019, 6:35 PM

Jan 7 2019

pmooney_pfmooney.com added a comment to D18755: Add accessor for vm->maxcpus in preperation for run time maxcpu setting.

Up until now, those structs have been kept opaque to the rest of the system, with accessor functions to perform necessary tasks/queries against them. Could you go into more detail about how your plans for dynamic VM_MAXCPU are impeded by similar constraints?

Jan 7 2019, 4:06 PM

May 4 2018

pmooney_pfmooney.com added a watcher for bhyve: pmooney_pfmooney.com.
May 4 2018, 4:14 PM