Project

General

Profile

Bug #13244

bhyve PM timer should be movable

Added by Patrick Mooney 6 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Category:
bhyve
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
bhyve
Gerrit CR:

Description

One device emulated by the bhyve kernel module is the power management timer (vpmtmr). Presently it is accessible via ioport 0x408 (corresponding to a PMBASE of 0x400). While this @PMBASE location might match certain traditional hardware system, it conflicts with ioport that qemu uses for certain device emulation (such as the debug port at 0x402) The rest of the ACPI functionality (offset from PMBASE) is implemented in userspace, but without the ability to update the in-kernel IO port for the PM timer, relocating it is not possible.

The IO port handling in the bhyve kernel should be more flexible so the PM timer, at the very least, can be relocated to a different IO port.


Related issues

Related to illumos gate - Bug #13245: bhyve IO port hooks could be better integratedClosedPatrick Mooney

Actions
Related to illumos gate - Bug #13304: bhyve ioport handling bungled on reinitClosedPatrick Mooney

Actions
#1

Updated by Electric Monk 6 months ago

  • Gerrit CR set to 1010
#2

Updated by Patrick Mooney 6 months ago

  • Related to Bug #13245: bhyve IO port hooks could be better integrated added
#3

Updated by Patrick Mooney 6 months ago

As with most bhyve changes, the first test procedure was to confirm that a variety of operating systems would still boot and run on a platform featuring the change. This was done on both AMD and Intel systems. Using dtrace, I could confirm that the PM timer handler (vpmtmr_handler) attached to the IO port in question was still being called when the guest initiated accesses to the port. The only external driver consumer, viona, was also able to attach its IO port hook and drive network traffic as expected. Using the newly-added --pmtmr-port feature in bhyvectl, I could move the PM timer port around to different addresses and verify that it wouldn't overlay an existing port handler or stumble over other "odd" conditions.

#4

Updated by Patrick Mooney 6 months ago

I was also able to manually confirm (via mdb -k) that the port hooks for a given instance looked correct and normal:

> vmm_list::walk list | ::print vmm_softc_t vmm_vm | ::print 'struct vm' ioports.iop_entries | ::eval '.,f::print ioport_entry_t'
{
    iope_func = vatpic_master_handler
    iope_arg = 0xfffffe59dd024180
    iope_port = 0x20
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpic_master_handler
    iope_arg = 0xfffffe59dd024180
    iope_port = 0x21
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpit_handler
    iope_arg = 0xfffffe5a2c125e00
    iope_port = 0x40
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpit_handler
    iope_arg = 0xfffffe5a2c125e00
    iope_port = 0x41
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpit_handler
    iope_arg = 0xfffffe5a2c125e00
    iope_port = 0x42
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpit_handler
    iope_arg = 0xfffffe5a2c125e00
    iope_port = 0x43
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpit_nmisc_handler
    iope_arg = 0xfffffe5a2c125e00
    iope_port = 0x61
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vrtc_addr_handler
    iope_arg = 0xfffffe59d0c16510
    iope_port = 0x70
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vrtc_data_handler
    iope_arg = 0xfffffe59d0c16510
    iope_port = 0x71
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpic_slave_handler
    iope_arg = 0xfffffe59dd024180
    iope_port = 0xa0
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpic_slave_handler
    iope_arg = 0xfffffe59dd024180
    iope_port = 0xa1
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vpmtmr_handler
    iope_arg = 0xfffffe5a0c9e1bd8
    iope_port = 0x408
    iope_flags = 0
    iope_pad = 0
}
{
    iope_func = vatpic_elc_handler
    iope_arg = 0xfffffe59dd024180
    iope_port = 0x4d0
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = vatpic_elc_handler
    iope_arg = 0xfffffe59dd024180
    iope_port = 0x4d1
    iope_flags = 0x1
    iope_pad = 0
}
{
    iope_func = viona_notify_iop
    iope_arg = 0xfffffe5a91a77b80
    iope_port = 0x2090
    iope_flags = 0x2
    iope_pad = 0
}
#5

Updated by Patrick Mooney 6 months ago

Mike Zeller successfully tested this (along with a few other bhyve patches) under SmartOS on an AMD Epyc machine.

#6

Updated by Electric Monk 5 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit 0e1453c3a2b94021caaa134e7c5a404243abd604

commit  0e1453c3a2b94021caaa134e7c5a404243abd604
Author: Patrick Mooney <pmooney@pfmooney.com>
Date:   2020-10-29T18:17:24.000Z

    13244 bhyve PM timer should be movable
    13245 bhyve IO port hooks could be better integrated
    Reviewed by: Robert Mustacchi <rm@fingolfin.org>
    Reviewed by: Mike Zeller <mike.zeller@joyent.com>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

#7

Updated by Patrick Mooney 5 months ago

  • Related to Bug #13304: bhyve ioport handling bungled on reinit added

Also available in: Atom PDF