On 03/20/2017 05:31 PM, Roman Bogorodskiy wrote:
Along with video and VNC support, bhyve has introduced USB tablet
support as an input device. This tablet is exposed to a guest
as a device on an XHCI controller.
At present, tablet is the only supported device on the XHCI controller
in bhyve, so to make things simple, it's allowed to only have a
single XHCI controller with a single tablet device.
In detail, this commit:
- Introduce a new capability bit for XHCI support in bhyve
- Add an XHCI controller and tabled support with 1:1 mapping
between them
- Add a couple of unit tests
---
src/bhyve/bhyve_capabilities.c | 15 +++++++
src/bhyve/bhyve_capabilities.h | 1 +
src/bhyve/bhyve_command.c | 50 ++++++++++++++++++++++
src/bhyve/bhyve_device.c | 4 +-
.../bhyvexml2argv-input-xhci-tablet.args | 9 ++++
.../bhyvexml2argv-input-xhci-tablet.ldargs | 3 ++
.../bhyvexml2argv-input-xhci-tablet.xml | 18 ++++++++
.../bhyvexml2argv-xhci-multiple-controllers.xml | 19 ++++++++
.../bhyvexml2argv-xhci-multiple-devs.xml | 19 ++++++++
.../bhyvexml2argv-xhci-no-devs.xml | 17 ++++++++
tests/bhyvexml2argvtest.c | 10 ++++-
.../bhyvexml2xmlout-input-xhci-tablet.xml | 31 ++++++++++++++
tests/bhyvexml2xmltest.c | 3 ++
13 files changed, 197 insertions(+), 2 deletions(-)
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-input-xhci-tablet.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-input-xhci-tablet.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-input-xhci-tablet.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-xhci-multiple-controllers.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-xhci-multiple-devs.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-xhci-no-devs.xml
create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-input-xhci-tablet.xml
diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index f72fdea41..a34c596f0 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve/bhyve_capabilities.c
@@ -286,6 +286,18 @@ bhyveProbeCapsFramebuffer(unsigned int *caps, char *binary)
BHYVE_CAP_FBUF);
}
+
+static int
+bhyveProbeCapsXHCIController(unsigned int *caps, char *binary)
+{
+ return bhyveProbeCapsDeviceHelper(caps, binary,
+ "-s",
+ "0,xhci",
+ "pci slot 0:0: unknown device \"xhci\"",
+ BHYVE_CAP_FBUF);
+}
+
+
int
virBhyveProbeCaps(unsigned int *caps)
{
@@ -313,6 +325,9 @@ virBhyveProbeCaps(unsigned int *caps)
if ((ret = bhyveProbeCapsFramebuffer(caps, binary)))
goto out;
+ if ((ret = bhyveProbeCapsXHCIController(caps, binary)))
+ goto out;
+
out:
VIR_FREE(binary);
return ret;
diff --git a/src/bhyve/bhyve_capabilities.h b/src/bhyve/bhyve_capabilities.h
index 3db4f1b88..3db51af02 100644
--- a/src/bhyve/bhyve_capabilities.h
+++ b/src/bhyve/bhyve_capabilities.h
@@ -45,6 +45,7 @@ typedef enum {
BHYVE_CAP_NET_E1000 = 1 << 2,
BHYVE_CAP_LPC_BOOTROM = 1 << 3,
BHYVE_CAP_FBUF = 1 << 4,
+ BHYVE_CAP_XHCI = 1 << 5,
} virBhyveCapsFlags;
Should we perhaps turn these into virBitmap? We could have something
like qemuCaps then. Because if this continues to grow, at 32 items we
will hit problem on 32 bit systems. But that can be saved to a follow up
patch.
ACK
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
