[PATCH v5 for-5.0? 0/7] Tighten qemu-img rules on missing backing format
by Eric Blake
v4 was here:
https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg03775.html
In v5:
- fix 'qemu-img convert -B' to actually warn [Kashyap]
- squash in followups
- a couple more iotest improvements
If we decide this is not 5.0 material, then patches 4 and 7 need a
tweak to s/5.0/5.1/ as the start of the deprecation clock.
Eric Blake (7):
sheepdog: Add trivial backing_fmt support
vmdk: Add trivial backing_fmt support
qcow: Tolerate backing_fmt=, but warn on backing_fmt=raw
qcow2: Deprecate use of qemu-img amend to change backing file
iotests: Specify explicit backing format where sensible
block: Add support to warn on backing file change without format
qemu-img: Deprecate use of -b without -F
docs/system/deprecated.rst | 32 ++++++++++++++++
docs/tools/qemu-img.rst | 4 ++
include/block/block.h | 4 +-
block.c | 34 +++++++++++++++--
block/qcow.c | 16 +++++++-
block/qcow2.c | 7 +++-
block/sheepdog.c | 18 ++++++++-
block/stream.c | 2 +-
block/vmdk.c | 14 +++++++
blockdev.c | 3 +-
qemu-img.c | 11 +++++-
tests/qemu-iotests/017 | 2 +-
tests/qemu-iotests/017.out | 2 +-
tests/qemu-iotests/018 | 2 +-
tests/qemu-iotests/018.out | 2 +-
tests/qemu-iotests/019 | 5 ++-
tests/qemu-iotests/019.out | 2 +-
tests/qemu-iotests/020 | 4 +-
tests/qemu-iotests/020.out | 4 +-
tests/qemu-iotests/024 | 8 ++--
tests/qemu-iotests/024.out | 5 ++-
tests/qemu-iotests/028 | 4 +-
tests/qemu-iotests/028.out | 2 +-
tests/qemu-iotests/030 | 26 +++++++++----
tests/qemu-iotests/034 | 2 +-
tests/qemu-iotests/034.out | 2 +-
tests/qemu-iotests/037 | 2 +-
tests/qemu-iotests/037.out | 2 +-
tests/qemu-iotests/038 | 2 +-
tests/qemu-iotests/038.out | 2 +-
tests/qemu-iotests/039 | 3 +-
tests/qemu-iotests/039.out | 2 +-
tests/qemu-iotests/040 | 47 ++++++++++++++++-------
tests/qemu-iotests/041 | 37 ++++++++++++------
tests/qemu-iotests/042 | 4 +-
tests/qemu-iotests/043 | 18 ++++-----
tests/qemu-iotests/043.out | 16 +++++---
tests/qemu-iotests/046 | 2 +-
tests/qemu-iotests/046.out | 2 +-
tests/qemu-iotests/050 | 4 +-
tests/qemu-iotests/050.out | 2 +-
tests/qemu-iotests/051 | 2 +-
tests/qemu-iotests/051.out | 2 +-
tests/qemu-iotests/051.pc.out | 2 +-
tests/qemu-iotests/056 | 3 +-
tests/qemu-iotests/060 | 2 +-
tests/qemu-iotests/060.out | 2 +-
tests/qemu-iotests/061 | 10 ++---
tests/qemu-iotests/061.out | 11 +++---
tests/qemu-iotests/069 | 2 +-
tests/qemu-iotests/069.out | 2 +-
tests/qemu-iotests/073 | 2 +-
tests/qemu-iotests/073.out | 2 +-
tests/qemu-iotests/082 | 10 +++--
tests/qemu-iotests/082.out | 14 ++++---
tests/qemu-iotests/085 | 4 +-
tests/qemu-iotests/085.out | 6 +--
tests/qemu-iotests/089 | 2 +-
tests/qemu-iotests/089.out | 2 +-
tests/qemu-iotests/095 | 4 +-
tests/qemu-iotests/095.out | 4 +-
tests/qemu-iotests/097 | 4 +-
tests/qemu-iotests/097.out | 16 ++++----
tests/qemu-iotests/098 | 2 +-
tests/qemu-iotests/098.out | 8 ++--
tests/qemu-iotests/110 | 4 +-
tests/qemu-iotests/110.out | 4 +-
tests/qemu-iotests/114 | 12 ++++++
tests/qemu-iotests/114.out | 9 +++++
tests/qemu-iotests/122 | 27 +++++++------
tests/qemu-iotests/122.out | 8 ++--
tests/qemu-iotests/126 | 4 +-
tests/qemu-iotests/126.out | 4 +-
tests/qemu-iotests/127 | 4 +-
tests/qemu-iotests/127.out | 4 +-
tests/qemu-iotests/129 | 3 +-
tests/qemu-iotests/133 | 2 +-
tests/qemu-iotests/133.out | 2 +-
tests/qemu-iotests/139 | 2 +-
tests/qemu-iotests/141 | 4 +-
tests/qemu-iotests/141.out | 4 +-
tests/qemu-iotests/142 | 2 +-
tests/qemu-iotests/142.out | 2 +-
tests/qemu-iotests/153 | 14 +++----
tests/qemu-iotests/153.out | 35 +++++++++--------
tests/qemu-iotests/154 | 42 ++++++++++----------
tests/qemu-iotests/154.out | 42 ++++++++++----------
tests/qemu-iotests/155 | 12 ++++--
tests/qemu-iotests/156 | 9 +++--
tests/qemu-iotests/156.out | 6 +--
tests/qemu-iotests/158 | 2 +-
tests/qemu-iotests/158.out | 2 +-
tests/qemu-iotests/161 | 8 ++--
tests/qemu-iotests/161.out | 8 ++--
tests/qemu-iotests/176 | 4 +-
tests/qemu-iotests/176.out | 32 ++++++++--------
tests/qemu-iotests/177 | 2 +-
tests/qemu-iotests/177.out | 2 +-
tests/qemu-iotests/179 | 2 +-
tests/qemu-iotests/179.out | 2 +-
tests/qemu-iotests/189 | 2 +-
tests/qemu-iotests/189.out | 2 +-
tests/qemu-iotests/191 | 12 +++---
tests/qemu-iotests/191.out | 12 +++---
tests/qemu-iotests/195 | 6 +--
tests/qemu-iotests/195.out | 6 +--
tests/qemu-iotests/198 | 2 +-
tests/qemu-iotests/198.out | 3 +-
tests/qemu-iotests/204 | 2 +-
tests/qemu-iotests/204.out | 2 +-
tests/qemu-iotests/216 | 2 +-
tests/qemu-iotests/224 | 4 +-
tests/qemu-iotests/225 | 2 +-
tests/qemu-iotests/225.out | 2 +-
tests/qemu-iotests/228 | 5 ++-
tests/qemu-iotests/245 | 3 +-
tests/qemu-iotests/249 | 4 +-
tests/qemu-iotests/249.out | 4 +-
tests/qemu-iotests/252 | 2 +-
tests/qemu-iotests/257 | 3 +-
tests/qemu-iotests/267 | 4 +-
tests/qemu-iotests/267.out | 6 +--
tests/qemu-iotests/270 | 2 +-
tests/qemu-iotests/270.out | 2 +-
tests/qemu-iotests/273 | 4 +-
tests/qemu-iotests/273.out | 4 +-
tests/qemu-iotests/279 | 4 +-
tests/qemu-iotests/279.out | 4 +-
tests/qemu-iotests/290 | 72 +++++++++++++++++++++++++++++++++++
tests/qemu-iotests/290.out | 45 ++++++++++++++++++++++
tests/qemu-iotests/group | 1 +
131 files changed, 683 insertions(+), 350 deletions(-)
create mode 100755 tests/qemu-iotests/290
create mode 100644 tests/qemu-iotests/290.out
--
2.26.0.rc2
4 years, 4 months
CFP: KVM Forum 2020
by Paolo Bonzini
================================================================
KVM Forum 2020: Call For Participation
October 28-30, 2020 - Convention Centre Dublin - Dublin, Ireland
(All submissions must be received before June 15, 2020 at 23:59 PST)
=================================================================
KVM Forum is an annual event that presents a rare opportunity for
developers and users to meet, discuss the state of Linux virtualization
technology, and plan for the challenges ahead. This highly technical
conference unites the developers who drive KVM development and the users
who depend on KVM as part of their offerings, or to power their data
centers and clouds.
Sessions include updates on the state of the KVM virtualization stack,
planning for the future, and many opportunities for attendees to
collaborate. After more than ten years in the mainline kernel, KVM
continues to be a critical part of the FOSS cloud infrastructure. Come
join us in continuing to improve the KVM ecosystem.
We understand that these are uncertain times and we are continuously
monitoring the COVID-19/Novel Coronavirus situation. Our attendees'
safety is of the utmost importance. If we feel it is not safe to meet in
person, we will turn the event into a virtual experience. We hope to
announce this at the same time as the speaker notification. Speakers
will still be expected to attend if a physical event goes ahead, but we
understand that exceptional circumstances might arise after speakers are
accepted and we will do our best to accommodate such circumstances.
Based on these factors, we encourage you to submit and reach out to us
should you have any questions. The program committee may be contacted as
a group via email: kvm-forum-2020-pc(a)redhat.com.
SUGGESTED TOPICS
----------------
* Scaling, latency optimizations, performance tuning
* Hardening and security
* New features
* Testing
KVM and the Linux Kernel:
* Nested virtualization
* Resource management (CPU, I/O, memory) and scheduling
* VFIO: IOMMU, SR-IOV, virtual GPU, etc.
* Networking: Open vSwitch, XDP, etc.
* virtio and vhost
* Architecture ports and new processor features
QEMU:
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* New storage features
* High availability, live migration and fault tolerance
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, U-Boot, etc.
Management & Infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, KubeVirt, etc.
* Storage: Ceph, Gluster, SPDK, etc.
* Network Function Virtualization: DPDK, OPNFV, OVN, etc.
* Provisioning
SUBMITTING YOUR PROPOSAL
------------------------
Abstracts due: June 15, 2020
Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes.
Submit your proposal here:
https://events.linuxfoundation.org/kvm-forum/program/cfp/
Please only use the categories "presentation" and "panel discussion"
You will receive a notification whether or not your presentation
proposal was accepted by August 17, 2020.
Speakers will receive a complimentary pass for the event. In case your
submission has multiple presenters, only the primary speaker for a
proposal will receive a complimentary event pass. For panel discussions,
all panelists will receive a complimentary event pass.
TECHNICAL TALKS
A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on work
that needs to be done, difficulties that haven't yet been solved, and on
decisions that other developers should be aware of. Summarizing recent
developments is okay but it should not be more than a small portion of
the overall talk.
END-USER TALKS
One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.
If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.
PANEL DISCUSSIONS
If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your the abstract. We will request
full biographies if a panel is accepted.
HANDS-ON / BOF SESSIONS
We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.
These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at
http://www.linux-kvm.org/page/KVM_Forum_2020_BOF
Let people you think who might be interested know about your BOF, and
encourage them to add their names to the wiki page as well. Please add
your ideas to the list before KVM Forum starts.
HOTEL / TRAVEL
--------------
This year's event will take place at the Conference Center Dublin. For
information on hotels close to the conference, please visit
https://events.linuxfoundation.org/kvm-forum/attend/venue-travel/.
Information on conference hotel blocks will be available later in
Spring 2020.
DATES TO REMEMBER
-----------------
* CFP Opens: Monday, April 27, 2020
* CFP Closes: Monday, June 15 at 11:59 PM PST
* CFP Notifications: Monday, August 17
* Schedule Announcement: Thursday, August 20
* Slide Due Date: Monday, October 26
* Event Dates: Wednesday, October 28 – Friday, October 30
Thank you for your interest in KVM. We're looking forward to your
submissions and, if the conditions will permit it, to seeing you at the
KVM Forum 2020 in October!
-your KVM Forum 2020 Program Committee
Please contact us with any questions or comments at
kvm-forum-2020-pc(a)redhat.com
4 years, 4 months
[PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration
by Yan Zhao
This patchset introduces a migration_version attribute under sysfs of VFIO
Mediated devices.
This migration_version attribute is used to check migration compatibility
between two mdev devices.
Currently, it has two locations:
(1) under mdev_type node,
which can be used even before device creation, but only for mdev
devices of the same mdev type.
(2) under mdev device node,
which can only be used after the mdev devices are created, but the src
and target mdev devices are not necessarily be of the same mdev type
(The second location is newly added in v5, in order to keep consistent
with the migration_version node for migratable pass-though devices)
Patch 1 defines migration_version attribute for the first location in
Documentation/vfio-mediated-device.txt
Patch 2 uses GVT as an example for patch 1 to show how to expose
migration_version attribute and check migration compatibility in vendor
driver.
Patch 3 defines migration_version attribute for the second location in
Documentation/vfio-mediated-device.txt
Patch 4 uses GVT as an example for patch 3 to show how to expose
migration_version attribute and check migration compatibility in vendor
driver.
(The previous "Reviewed-by" and "Acked-by" for patch 1 and patch 2 are
kept in v5, as there are only small changes to commit messages of the two
patches.)
v5:
added patch 2 and 4 for mdev device part of migration_version attribute.
v4:
1. fixed indentation/spell errors, reworded several error messages
2. added a missing memory free for error handling in patch 2
v3:
1. renamed version to migration_version
2. let errno to be freely defined by vendor driver
3. let checking mdev_type be prerequisite of migration compatibility check
4. reworded most part of patch 1
5. print detailed error log in patch 2 and generate migration_version
string at init time
v2:
1. renamed patched 1
2. made definition of device version string completely private to vendor
driver
3. reverted changes to sample mdev drivers
4. described intent and usage of version attribute more clearly.
Yan Zhao (4):
vfio/mdev: add migration_version attribute for mdev (under mdev_type
node)
drm/i915/gvt: export migration_version to mdev sysfs (under mdev_type
node)
vfio/mdev: add migration_version attribute for mdev (under mdev device
node)
drm/i915/gvt: export migration_version to mdev sysfs (under mdev
device node)
.../driver-api/vfio-mediated-device.rst | 183 ++++++++++++++++++
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/i915/gvt/gvt.c | 39 ++++
drivers/gpu/drm/i915/gvt/gvt.h | 7 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 55 ++++++
drivers/gpu/drm/i915/gvt/migration_version.c | 170 ++++++++++++++++
drivers/gpu/drm/i915/gvt/vgpu.c | 13 +-
7 files changed, 466 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/migration_version.c
--
2.17.1
4 years, 4 months
[PATCH libvirt v1 0/6] Fix ZPCI address auto-generation on s390
by Shalini Chellathurai Saroja
The ZPCI address validation or autogeneration does not work as
expected in the following scenarios
1. uid = 0 and fid = 0
2. uid = 0 and fid > 0
3. uid = 0 and fid not specified
4. uid not specified and fid > 0
5. 2 ZPCI devices with uid > 0 and fid not specified.
This is because of the following reasons
1. If uid = 0 or fid = 0 the code assumes that user has not specified
the corresponding address
2. If either uid or fid is provided, the code assumes that both uid
and fid addresses are specified by the user.
This patch fixes these issues.
Shalini Chellathurai Saroja (6):
conf: fix ZPCI address validation on s390
tests: qemu: add tests for ZPCI on s390
conf: fix ZPCI address auto-generation on s390
qemu: move ZPCI uid validation into device validation
tests: qemu: add more tests for ZPCI on S390
tests: add test with PCI and CCW device
src/conf/device_conf.c | 45 ++++++--------
src/conf/domain_addr.c | 59 +++++++++++++------
src/conf/domain_conf.c | 2 +-
src/libvirt_private.syms | 4 +-
src/qemu/qemu_validate.c | 26 +++++++-
src/util/virpci.c | 23 ++------
src/util/virpci.h | 6 +-
.../hostdev-vfio-zpci-autogenerate-fids.args | 31 ++++++++++
.../hostdev-vfio-zpci-autogenerate-fids.xml | 29 +++++++++
.../hostdev-vfio-zpci-autogenerate-uids.args | 31 ++++++++++
.../hostdev-vfio-zpci-autogenerate-uids.xml | 29 +++++++++
.../hostdev-vfio-zpci-ccw-memballoon.args | 28 +++++++++
.../hostdev-vfio-zpci-ccw-memballoon.xml | 17 ++++++
.../hostdev-vfio-zpci-duplicate.xml | 30 ++++++++++
...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 21 +++++++
.../hostdev-vfio-zpci-multidomain-many.args | 6 +-
.../hostdev-vfio-zpci-set-zero.xml | 21 +++++++
.../hostdev-vfio-zpci-uid-set-zero.xml | 20 +++++++
tests/qemuxml2argvtest.c | 25 ++++++++
.../hostdev-vfio-zpci-multidomain-many.xml | 6 +-
20 files changed, 387 insertions(+), 72 deletions(-)
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml
--
2.21.1
4 years, 4 months
[PATCH v2 1/3] libxl: Add 'permissive' option for PCI devices
by Marek Marczykowski-Górecki
From: Simon Gaiser <simon(a)invisiblethingslab.com>
By setting the permissive flag the Xen guest access to the PCI config space
is not filtered. This might be a security risk, but it's required for
some devices and the IOMMU and interrupt remapping should (mostly?)
contain it. Because of it (and that the attribute is Xen only), in an
example include "permissive='no'" - to not expose users copying from
documentation to extra risk.
Example usage:
<devices>
...
<hostdev mode='subsystem' type='pci' managed='yes' permissive='yes'>
<source>
<address domain='0x0000' bus='0x06' slot='0x02' function='0x0'/>
</source>
</hostdev>
</devices>
Signed-off-by: Simon Gaiser <simon(a)invisiblethingslab.com>
Signed-off-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com>
---
Changes in v2:
- improve documentation (version info, example)
- update schema
- use virTristateBool
- add a test
- improve commit message
- news entry
---
docs/formatdomain.html.in | 7 +++++--
docs/news.xml | 11 +++++++++++-
docs/schemas/domaincommon.rng | 10 ++++++++++-
src/conf/domain_conf.c | 19 +++++++++++++++++++-
src/conf/domain_conf.h | 1 +-
src/libxl/libxl_conf.c | 1 +-
tests/libxlxml2domconfigdata/moredevs-hvm.json | 6 ++++++-
tests/libxlxml2domconfigdata/moredevs-hvm.xml | 5 +++++-
8 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index c530573..0d1146e 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -4987,7 +4987,7 @@
<pre>
...
<devices>
- <hostdev mode='subsystem' type='pci' managed='yes'>
+ <hostdev mode='subsystem' type='pci' managed='yes' permissive='no'>
<source>
<address domain='0x0000' bus='0x06' slot='0x02' function='0x0'/>
</source>
@@ -5082,7 +5082,10 @@
(or <code>virsh nodedev-detach</code> before starting the guest
or hot-plugging the device and <code>virNodeDeviceReAttach</code>
(or <code>virsh nodedev-reattach</code>) after hot-unplug or
- stopping the guest.
+ stopping the guest. When <code>permissive</code>
+ (<span class="since">since 6.3.0, Xen only</span>) is "yes"
+ the pci config space access will not be filtered. This might be
+ a security issue. The default is "no".
</dd>
<dt><code>scsi</code></dt>
<dd>For SCSI devices, user is responsible to make sure the device
diff --git a/docs/news.xml b/docs/news.xml
index 5835013..a8e992a 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -109,6 +109,17 @@
and/or fine tuned per individual host.
</description>
</change>
+ <change>
+ <summary>
+ xen: Add support for 'permissive' PCI device option
+ </summary>
+ <description>
+ <code>permissive</code> is a Xen-specific PCI device option that
+ disables config space write filtering. It is needed for proper
+ functioning of some devices using non-standard config space
+ registers.
+ </description>
+ </change>
</section>
<section title="Improvements">
</section>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 7f18e5b..5a71222 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3065,6 +3065,11 @@
<ref name="virYesNo"/>
</attribute>
</optional>
+ <optional>
+ <attribute name="permissive">
+ <ref name="virYesNo"/>
+ </attribute>
+ </optional>
<interleave>
<element name="source">
<optional>
@@ -4899,6 +4904,11 @@
<ref name="virYesNo"/>
</attribute>
</optional>
+ <optional>
+ <attribute name="permissive">
+ <ref name="virYesNo"/>
+ </attribute>
+ </optional>
<choice>
<ref name="hostdevsubsyspci"/>
<ref name="hostdevsubsysusb"/>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 89cd8c5..fe1a864 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -8434,6 +8434,7 @@ virDomainHostdevDefParseXMLSubsys(xmlNodePtr node,
virDomainHostdevSubsysSCSIVHostPtr scsihostsrc = &def->source.subsys.u.scsi_host;
virDomainHostdevSubsysMediatedDevPtr mdevsrc = &def->source.subsys.u.mdev;
g_autofree char *managed = NULL;
+ g_autofree char *permissive = NULL;
g_autofree char *sgio = NULL;
g_autofree char *rawio = NULL;
g_autofree char *backendStr = NULL;
@@ -8449,6 +8450,15 @@ virDomainHostdevDefParseXMLSubsys(xmlNodePtr node,
if ((managed = virXMLPropString(node, "managed")) != NULL)
ignore_value(virStringParseYesNo(managed, &def->managed));
+ if ((permissive = virXMLPropString(node, "permissive")) != NULL) {
+ if ((def->permissive = virTristateBoolTypeFromString(permissive)) < 0) {
+ virReportError(VIR_ERR_XML_ERROR,
+ _("unknown hostdev permissive setting '%s'"),
+ permissive);
+ return -1;
+ }
+ }
+
sgio = virXMLPropString(node, "sgio");
rawio = virXMLPropString(node, "rawio");
model = virXMLPropString(node, "model");
@@ -26091,6 +26101,9 @@ virDomainActualNetDefFormat(virBufferPtr buf,
virDomainHostdevDefPtr hostdef = virDomainNetGetActualHostdev(def);
if (hostdef && hostdef->managed)
virBufferAddLit(buf, " managed='yes'");
+ if (hostdef && hostdef->permissive)
+ virBufferAsprintf(buf, " permissive='%s'",
+ virTristateBoolTypeToString(hostdef->permissive));
}
if (def->trustGuestRxFilters)
virBufferAsprintf(buf, " trustGuestRxFilters='%s'",
@@ -26279,6 +26292,9 @@ virDomainNetDefFormat(virBufferPtr buf,
virBufferAsprintf(buf, "<interface type='%s'", typeStr);
if (hostdef && hostdef->managed)
virBufferAddLit(buf, " managed='yes'");
+ if (hostdef && hostdef->permissive)
+ virBufferAsprintf(buf, " permissive='%s'",
+ virTristateBoolTypeToString(hostdef->permissive));
if (def->trustGuestRxFilters)
virBufferAsprintf(buf, " trustGuestRxFilters='%s'",
virTristateBoolTypeToString(def->trustGuestRxFilters));
@@ -28063,6 +28079,9 @@ virDomainHostdevDefFormat(virBufferPtr buf,
if (def->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) {
virBufferAsprintf(buf, " managed='%s'",
def->managed ? "yes" : "no");
+ if (def->permissive)
+ virBufferAsprintf(buf, " permissive='%s'",
+ virTristateBoolTypeToString(def->permissive));
if (def->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI &&
scsisrc->sgio)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index ecb80ef..24ec03c 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -345,6 +345,7 @@ struct _virDomainHostdevDef {
bool missing;
bool readonly;
bool shareable;
+ virTristateBool permissive;
union {
virDomainHostdevSubsys subsys;
virDomainHostdevCaps caps;
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 458dfc2..23dd0e4 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -2284,6 +2284,7 @@ libxlMakePCI(virDomainHostdevDefPtr hostdev, libxl_device_pci *pcidev)
pcidev->bus = pcisrc->addr.bus;
pcidev->dev = pcisrc->addr.slot;
pcidev->func = pcisrc->addr.function;
+ pcidev->permissive = hostdev->permissive == VIR_TRISTATE_BOOL_YES;
return 0;
}
diff --git a/tests/libxlxml2domconfigdata/moredevs-hvm.json b/tests/libxlxml2domconfigdata/moredevs-hvm.json
index 7bfd68b..474aa2c 100644
--- a/tests/libxlxml2domconfigdata/moredevs-hvm.json
+++ b/tests/libxlxml2domconfigdata/moredevs-hvm.json
@@ -88,6 +88,12 @@
"dev": 16,
"bus": 10,
"rdm_policy": "invalid"
+ },
+ {
+ "dev": 8,
+ "bus": 10,
+ "permissive": true,
+ "rdm_policy": "invalid"
}
],
"vfbs": [
diff --git a/tests/libxlxml2domconfigdata/moredevs-hvm.xml b/tests/libxlxml2domconfigdata/moredevs-hvm.xml
index f7eb09f..1b6b738 100644
--- a/tests/libxlxml2domconfigdata/moredevs-hvm.xml
+++ b/tests/libxlxml2domconfigdata/moredevs-hvm.xml
@@ -48,6 +48,11 @@
<address type='pci' domain='0x0000' bus='0x0a' slot='0x10' function='0x0'/>
</source>
</interface>
+ <hostdev mode='subsystem' type='pci' managed='yes' permissive='yes'>
+ <source>
+ <address domain='0x0000' bus='0x0a' slot='0x08' function='0x0'/>
+ </source>
+ </hostdev>
<graphics type='vnc'/>
<video>
<model type='cirrus' vram='8192' heads='1' primary='yes'/>
base-commit: c3ace7e234ccd43d5a008d93e122e6d47cd58e17
--
git-series 0.9.1
4 years, 5 months
[libvirt PATCH 0/6] Add ability to create mediated devices in libvirt
by Jonathon Jongsma
This is the first portion of an effort to support persistent mediated devices
with libvirt. This first series simply enables creating and destroying
non-persistent mediated devices via the virNodeDeviceCreateXML() and
virNodeDeviceDestroy() functions. The 'mdevctl' utility[1] provides the backend
implementation.
[1] https://github.com/mdevctl/mdevctl
Jonathon Jongsma (6):
nodedev: factor out nodeDeviceHasCapability()
nodedev: add support for mdev attributes
nodedev: refactor nodeDeviceFindNewDevice()
nodedev: store mdev UUID in mdev caps
nodedev: add mdev support to virNodeDeviceCreateXML()
nodedev: add mdev support to virNodeDeviceDestroy()
docs/schemas/nodedev.rng | 6 +
libvirt.spec.in | 3 +
m4/virt-external-programs.m4 | 3 +
src/conf/node_device_conf.c | 59 ++++-
src/conf/node_device_conf.h | 3 +
src/conf/virnodedeviceobj.c | 34 +++
src/conf/virnodedeviceobj.h | 3 +
src/libvirt_private.syms | 3 +
src/node_device/node_device_driver.c | 326 ++++++++++++++++++++++++---
src/node_device/node_device_udev.c | 5 +-
src/util/virmdev.c | 12 +
src/util/virmdev.h | 11 +
12 files changed, 425 insertions(+), 43 deletions(-)
--
2.21.1
4 years, 5 months
[PATCH 00/15] tests: qemu: Detect deprecation in the QMP schema (deprecation part 1)
by Peter Krempa
Recent qemu versions started adding the 'deprecated' feature to commands
and fields. Use this data to validate that our code doesn't rely on
deprecated commands. It turns out that we still use some old migration
commands (See 14/15) and add validator to catch anything deprecated
early.
Peter Krempa (15):
testQemuHotplugCpuPrepare: Allow unused monitor commands only on
failure
testutilsqemuschema: Introduce testQEMUSchemaValidateCommand
qemuMonitorTestProcessCommandDefaultValidate: Use
testQEMUSchemaValidateCommand
qemuMonitorTestProcessCommandDefaultValidate: Clean up return value
use
qemumonitortestutils: Introduce
qemuMonitorTestSkipDeprecatedValidation
testutilsqemuschema: Use automatic variable clearing where possible
testutilsqemuschema: Pass in 'schema' and 'debug' variables to workers
in a struct
testQEMUSchemaValidate(Command): Allow skipping validation of
deprecated fields
testQemuHotplugCpuPrepare: Allow deprecated commands for non-modern
cpu hotplug test
qemumonitorjsontest: Add infrastructure for generated tests of
deprecated commands
testQemuMonitorJSONqemuMonitorJSONQueryCPUs: Split off test for
query-cpus-fast
qemumonitorjsontest: Allow use of deprecated 'query-cpus'
qemumonitorjsontest: Allow use of deprecated 'cpu-add' and 'change'
command
qemumonitorjsontest: Mark recently deprecated migration command in our
tests
testQEMUSchemaValidate*: Reject usage of fields with 'deprecated' set
tests/qemublocktest.c | 14 +-
tests/qemuhotplugtest.c | 11 +-
tests/qemumonitorjsontest.c | 67 +++++--
tests/qemumonitortestutils.c | 66 ++++---
tests/qemumonitortestutils.h | 2 +
tests/testutilsqemuschema.c | 334 ++++++++++++++++++++++-------------
tests/testutilsqemuschema.h | 9 +
7 files changed, 325 insertions(+), 178 deletions(-)
--
2.26.2
4 years, 5 months
[libvirt PATCH] xenconfig: Add feature gfx_passthru
by Artur Puzio
gfx_passthru xl.cfg option enables GPU specific quirks required for working
Intel GPU passthru. Qemu (used for device model by xen) will refuse to start
a VM when an IGD is passed, but this option was not set in Xen.
Signed-off-by: Artur Puzio <contact(a)puzio.waw.pl>
---
docs/formatdomain.html.in | 7 +++++++
docs/schemas/domaincommon.rng | 5 +++++
src/conf/domain_conf.c | 4 ++++
src/conf/domain_conf.h | 1 +
src/libxl/libxl_conf.c | 13 +++++++++++++
5 files changed, 30 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 91d6f6c0d3..5307844a23 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -2064,6 +2064,7 @@
<xen>
<e820_host state='on'/>
<passthrough state='on' mode='share_pt'/>
+ <gfx_passthru state='on'/>
</xen>
<pvspinlock state='on'/>
<gic version='2'/>
@@ -2270,6 +2271,12 @@
<td>on, off; mode - optional string sync_pt or share_pt</td>
<td><span class="since">6.3.0</span></td>
</tr>
+ <tr>
+ <td>gfx_passthru</td>
+ <td>Enable Intel GPU specific quirks. Required and allowed only when passing an IGD.</td>
+ <td>on, off</td>
+ <td><span class="since">6.3.0</span></td>
+ </tr>
</table>
</dd>
<dt><code>pmu</code></dt>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 9d60b090f3..7d8ea879a1 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -6409,6 +6409,11 @@
</optional>
</element>
</optional>
+ <optional>
+ <element name="gfx_passthru">
+ <ref name="featurestate"/>
+ </element>
+ </optional>
</interleave>
</element>
</define>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 8a87586936..75f72ff64c 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -214,6 +214,7 @@ VIR_ENUM_IMPL(virDomainXen,
VIR_DOMAIN_XEN_LAST,
"e820_host",
"passthrough",
+ "gfx_passthru"
);
VIR_ENUM_IMPL(virDomainXenPassthroughMode,
@@ -19649,6 +19650,7 @@ virDomainFeaturesDefParse(virDomainDefPtr def,
switch ((virDomainXen) feature) {
case VIR_DOMAIN_XEN_E820_HOST:
+ case VIR_DOMAIN_XEN_GFX_PASSTHRU:
break;
case VIR_DOMAIN_XEN_PASSTHROUGH:
@@ -23579,6 +23581,7 @@ virDomainDefFeaturesCheckABIStability(virDomainDefPtr src,
}
switch ((virDomainXen) i) {
case VIR_DOMAIN_XEN_E820_HOST:
+ case VIR_DOMAIN_XEN_GFX_PASSTHRU:
break;
case VIR_DOMAIN_XEN_PASSTHROUGH:
@@ -29235,6 +29238,7 @@ virDomainDefFormatFeatures(virBufferPtr buf,
switch ((virDomainXen) j) {
case VIR_DOMAIN_XEN_E820_HOST:
+ case VIR_DOMAIN_XEN_GFX_PASSTHRU:
virBufferAddLit(&childBuf, "/>\n");
break;
case VIR_DOMAIN_XEN_PASSTHROUGH:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 4afd8f04bc..f28f0741ac 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1867,6 +1867,7 @@ typedef enum {
typedef enum {
VIR_DOMAIN_XEN_E820_HOST = 0,
VIR_DOMAIN_XEN_PASSTHROUGH,
+ VIR_DOMAIN_XEN_GFX_PASSTHRU,
VIR_DOMAIN_XEN_LAST
} virDomainXen;
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 458dfc2399..a5605f6200 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -679,6 +679,19 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
return -1;
}
#endif
+ if (def->features[VIR_DOMAIN_FEATURE_XEN] == VIR_TRISTATE_SWITCH_ON) {
+ switch ((virTristateSwitch) def->xen_features[VIR_DOMAIN_XEN_GFX_PASSTHRU]) {
+ case VIR_TRISTATE_SWITCH_ON:
+ libxl_defbool_set(&b_info->u.hvm.gfx_passthru, true);
+ break;
+ case VIR_TRISTATE_SWITCH_OFF:
+ libxl_defbool_set(&b_info->u.hvm.gfx_passthru, false);
+ break;
+ case VIR_TRISTATE_SWITCH_ABSENT:
+ case VIR_TRISTATE_SWITCH_LAST:
+ break;
+ }
+ }
} else if (pvh) {
b_info->cmdline = g_strdup(def->os.cmdline);
b_info->kernel = g_strdup(def->os.kernel);
--
2.26.2
4 years, 5 months
[PATCH v2 00/40] convert virObjects to GObject
by Rafael Fonseca
This patch series convert various simple instances of virObject to a
GObject equivalent.
virLockableObject and virObjects which are subclassed will be covered
in future patchsets.
New in v2:
- use *Dispose for unreffing objects and *Finalize for freeing data,
as suggested in the GLib documentation
- use `g_clear_object` instead of `if + g_object_unref`
- properly update gendispatch as types are converted
- virDomain is now converted to GObject too
- added a helper function for freeing array of GObjects
- added previously missed conversion spots
Rafael Fonseca (40):
util: virresctrl: convert classes to GObject
conf: capabilities: convert virCaps to GOBject
qemu: convert virQEMUCaps to GObject
util: add function to unref array of GObjects
rpc: convert virNetClientProgram to GObject
rpc: convert virNetServerProgram to GObject
conf: convert virDomainXMLOption to GObject
bhyve: convert bhyveMonitor to GObject
bhyve: convert virBhyveDriverConfig to GObject
rpc: convert virNetServerService to GObject
conf: convert virDomainCapsCPUModels to GObject
util: convert dnsmasqCaps to GObject
conf: convert virDomainChrSourceDef to GObject
rpc: gendispatch: prepare for GObject conversion
admin: convert virAdmServer to GObject
admin: convert virAdmClient to GObject
datatypes: convert virDomainCheckpoint to GObject
datatypes: convert virDomainSnapshot to GObject
datatypes: convert virNWFilter to GObject
datatypes: convert virNWFilterBinding to GObject
datatypes: convert virNetwork to GObject
datatypes: convert virNetworkPort to GObject
datatypes: convert virInterface to GObject
datatypes: convert virStoragePool to GObject
datatypes: convert virStorageVol to GObject
datatypes: convert virNodeDevice to GObject
datatypes: convert virSecret to GObject
datatypes: convert virStream to GObject
datatypes: convert virDomain to GObject
rpc: gendispatch: use g_autoptr where possible
conf: convert virNetworkXMLOption to GObject
lxc: convert virLXCDriverConfig to GObject
libxl: convert libxlDriverConfig to GObject
hypervisor: convert virHostdevManager to GObject
libxl: convert libxlMigrationDstArgs to GObject
qemu: convert qemuBlockJobData to GObject
qemu: convert virQEMUDriverConfig to GObject
conf: convert virDomain*Private to GObject
conf: convert virSaveCookie to GObject
util: convert virStorageSource to GObject
src/admin/admin_remote.c | 9 +-
src/admin/libvirt-admin.c | 4 +-
src/admin/libvirt_admin_private.syms | 4 +-
src/bhyve/bhyve_capabilities.c | 19 +-
src/bhyve/bhyve_conf.c | 36 +-
src/bhyve/bhyve_driver.c | 33 +-
src/bhyve/bhyve_monitor.c | 48 +-
src/bhyve/bhyve_monitor.h | 3 +-
src/bhyve/bhyve_utils.h | 11 +-
src/conf/capabilities.c | 51 +-
src/conf/capabilities.h | 6 +-
src/conf/domain_capabilities.c | 48 +-
src/conf/domain_capabilities.h | 10 +-
src/conf/domain_conf.c | 129 ++--
src/conf/domain_conf.h | 36 +-
src/conf/domain_event.c | 58 +-
src/conf/network_conf.c | 24 +-
src/conf/network_conf.h | 12 +-
src/conf/network_event.c | 7 +-
src/conf/node_device_event.c | 11 +-
src/conf/node_device_util.c | 4 +-
src/conf/secret_event.c | 15 +-
src/conf/snapshot_conf.c | 2 +-
src/conf/snapshot_conf.h | 2 +-
src/conf/storage_capabilities.c | 4 +-
src/conf/storage_event.c | 15 +-
src/conf/virchrdev.c | 4 +-
src/conf/virconftypes.h | 3 +-
src/conf/virdomaincheckpointobjlist.c | 7 +-
src/conf/virdomainsnapshotobjlist.c | 7 +-
src/conf/virinterfaceobj.c | 5 +-
src/conf/virnetworkobj.c | 10 +-
src/conf/virnodedeviceobj.c | 3 +-
src/conf/virnwfilterbindingobjlist.c | 2 +-
src/conf/virnwfilterobj.c | 7 +-
src/conf/virsavecookie.c | 10 +-
src/conf/virsavecookie.h | 14 +-
src/conf/virsecretobj.c | 2 +-
src/conf/virstorageobj.c | 4 +-
src/datatypes.c | 977 ++++++++++++++++--------
src/datatypes.h | 219 +++---
src/esx/esx_driver.c | 33 +-
src/hyperv/hyperv_driver.c | 8 +-
src/hypervisor/virhostdev.c | 49 +-
src/hypervisor/virhostdev.h | 13 +-
src/interface/interface_backend_netcf.c | 7 +-
src/interface/interface_backend_udev.c | 8 +-
src/libvirt-domain-checkpoint.c | 7 +-
src/libvirt-domain-snapshot.c | 7 +-
src/libvirt-domain.c | 6 +-
src/libvirt-interface.c | 6 +-
src/libvirt-network.c | 14 +-
src/libvirt-nodedev.c | 6 +-
src/libvirt-nwfilter.c | 14 +-
src/libvirt-secret.c | 7 +-
src/libvirt-storage.c | 12 +-
src/libvirt-stream.c | 7 +-
src/libvirt_private.syms | 35 +-
src/libxl/libxl_capabilities.c | 19 +-
src/libxl/libxl_conf.c | 65 +-
src/libxl/libxl_conf.h | 12 +-
src/libxl/libxl_driver.c | 175 ++---
src/libxl/libxl_migration.c | 103 +--
src/libxl/xen_common.c | 3 +-
src/locking/lock_daemon.c | 28 +-
src/locking/lock_driver_lockd.c | 19 +-
src/locking/sanlock_helper.c | 5 +-
src/logging/log_daemon.c | 28 +-
src/logging/log_manager.c | 15 +-
src/lxc/lxc_conf.c | 46 +-
src/lxc/lxc_conf.h | 10 +-
src/lxc/lxc_controller.c | 20 +-
src/lxc/lxc_driver.c | 98 +--
src/lxc/lxc_monitor.c | 2 +-
src/lxc/lxc_process.c | 35 +-
src/network/bridge_driver.c | 24 +-
src/nwfilter/nwfilter_driver.c | 3 +-
src/openvz/openvz_conf.c | 8 +-
src/qemu/qemu_blockjob.c | 130 ++--
src/qemu/qemu_blockjob.h | 15 +-
src/qemu/qemu_capabilities.c | 176 +++--
src/qemu/qemu_capabilities.h | 9 +-
src/qemu/qemu_conf.c | 42 +-
src/qemu/qemu_conf.h | 19 +-
src/qemu/qemu_domain.c | 441 +++++------
src/qemu/qemu_domain.h | 157 ++--
src/qemu/qemu_driver.c | 34 +-
src/qemu/qemu_hotplug.c | 3 +-
src/qemu/qemu_migration.c | 34 +-
src/qemu/qemu_process.c | 20 +-
src/qemu/qemu_virtiofs.c | 12 +-
src/remote/remote_daemon.c | 52 +-
src/remote/remote_daemon_dispatch.c | 188 ++---
src/remote/remote_daemon_stream.c | 6 +-
src/remote/remote_driver.c | 178 ++---
src/rpc/gendispatch.pl | 90 ++-
src/rpc/virnetclient.c | 7 +-
src/rpc/virnetclientprogram.c | 29 +-
src/rpc/virnetclientprogram.h | 10 +-
src/rpc/virnetclientstream.c | 4 +-
src/rpc/virnetserver.c | 21 +-
src/rpc/virnetserverprogram.c | 30 +-
src/rpc/virnetserverprogram.h | 17 +-
src/rpc/virnetserverservice.c | 103 ++-
src/security/virt-aa-helper.c | 9 +-
src/storage/storage_backend.c | 3 +-
src/storage/storage_driver.c | 7 +-
src/storage/storage_util.c | 4 +-
src/test/test_driver.c | 33 +-
src/util/virdnsmasq.c | 56 +-
src/util/virdnsmasq.h | 6 +-
src/util/virfdstream.c | 4 +-
src/util/virfilecache.c | 43 +-
src/util/virfilecache.h | 12 +-
src/util/virobject.c | 24 +
src/util/virobject.h | 4 +
src/util/virresctrl.c | 164 ++--
src/util/virresctrl.h | 15 +-
src/util/virsecret.c | 3 +-
src/util/virstoragefile.c | 45 +-
src/util/virstoragefile.h | 9 +-
src/vbox/vbox_common.c | 19 +-
src/vmware/vmware_conf.c | 13 +-
src/vz/vz_driver.c | 33 +-
src/vz/vz_sdk.c | 22 +-
tests/bhyveargv2xmltest.c | 4 +-
tests/bhyvexml2argvtest.c | 4 +-
tests/bhyvexml2xmltest.c | 4 +-
tests/cputest.c | 48 +-
tests/domaincapstest.c | 5 +-
tests/domainconftest.c | 4 +-
tests/genericxml2xmltest.c | 4 +-
tests/networkxml2conftest.c | 10 +-
tests/networkxml2xmltest.c | 3 +-
tests/openvzutilstest.c | 4 +-
tests/qemublocktest.c | 3 +-
tests/qemucapabilitiestest.c | 9 +-
tests/qemucaps2xmltest.c | 29 +-
tests/qemucapsprobe.c | 4 +-
tests/qemuhotplugtest.c | 6 +-
tests/qemumemlocktest.c | 3 +-
tests/testutils.c | 4 +-
tests/testutilslxc.c | 22 +-
tests/testutilsqemu.c | 31 +-
tests/testutilsxen.c | 7 +-
tests/vircaps2xmltest.c | 6 +-
tests/vircapstest.c | 14 +-
tests/virfilecachetest.c | 69 +-
tests/virnetdaemontest.c | 4 +-
tests/virresctrltest.c | 6 +-
tests/vmx2xmltest.c | 10 +-
tests/xml2vmxtest.c | 12 +-
152 files changed, 2804 insertions(+), 2712 deletions(-)
--
2.25.3
4 years, 5 months
[PATCH V3 0/5] Introduce getHost support for ARM CPU driver
by ZhengZhenyu
Introduce getHost support for ARM CPU driver. First add
some data about commonly used ARM CPU models, and their
vendors into cpu_map, then added some helper methods as
callbacks to load them. Read and parse vendor_id, part_id
and CPU flags of local CPU from corresponding registers.
Signed-off-by: Zhenyu Zheng <zhengzhenyulixi(a)gmail.com>
ZhengZhenyu (5):
cpu_map: Introduce ARM cpu models
cpu: Introduce virCPUarmData to virCPUData
cpu: Introduce ARM related structs
cpu: Add helper funtions to parse vendor and model
cpu: Introduce getHost support for ARM CPU driver
src/cpu/Makefile.inc.am | 1 +
src/cpu/cpu.h | 2 +
src/cpu/cpu_arm.c | 450 +++++++++++++++++++++++++++++-
src/cpu/cpu_arm_data.h | 31 ++
src/cpu_map/Makefile.inc.am | 7 +
src/cpu_map/arm_Falkor.xml | 16 ++
src/cpu_map/arm_Kunpeng-920.xml | 24 ++
src/cpu_map/arm_ThunderX299xx.xml | 16 ++
src/cpu_map/arm_cortex-a53.xml | 16 ++
src/cpu_map/arm_cortex-a57.xml | 15 +
src/cpu_map/arm_cortex-a72.xml | 15 +
src/cpu_map/arm_vendors.xml | 14 +
src/cpu_map/index.xml | 15 +
13 files changed, 619 insertions(+), 3 deletions(-)
create mode 100644 src/cpu/cpu_arm_data.h
create mode 100644 src/cpu_map/arm_Falkor.xml
create mode 100644 src/cpu_map/arm_Kunpeng-920.xml
create mode 100644 src/cpu_map/arm_ThunderX299xx.xml
create mode 100644 src/cpu_map/arm_cortex-a53.xml
create mode 100644 src/cpu_map/arm_cortex-a57.xml
create mode 100644 src/cpu_map/arm_cortex-a72.xml
create mode 100644 src/cpu_map/arm_vendors.xml
--
2.26.0.windows.1
4 years, 5 months