Commit Graph

7 Commits

Author SHA1 Message Date
Qi Feng Huo
cf0f05d2e9 qemu: add iommu_platform knob for qemuParams
Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>

fix typo

Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>

qemu: remove useless fmt.Sprintf for qemuParams

Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>

fix test cases for s390x

Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>
2020-07-30 22:19:49 +08:00
Julio Montes
abca6f3ce9 Add multidevs option to fsdev
multidevs specifies how to deal with multiple devices being shared with a 9p
export. `multidevs=remap` fixes the following warning:

```
9p: Multiple devices detected in same VirtFS export, which might lead to file
ID collisions and severe misbehaviours on guest!
You should either use a separate export for each device shared from host or
use virtfs option 'multidevs=remap'!
```

Signed-off-by: Julio Montes <julio.montes@intel.com>
2020-07-23 10:56:22 -05:00
Peng Tao
3700c55dd7 qemu: add block device readonly support
So that we can attach it readonly.

Signed-off-by: Peng Tao <bergwolf@hyper.sh>
2020-02-21 08:58:53 +01:00
Sergio Lopez
88a25a2d68 Refactor code to support multiple virtio transports at runtime
Currently, virtio transports for each device are determined with
architecture dependent build time conditionals. This isn't the ideal
solution, as virtio transports aren't exactly tied to the host's
architecture.

For example, aarch64 VMs do support both PCI and MMIO devices, and
after the recent introduction of the microvm machine type, that's also
the case for x86_64.

This patch extends each device that supports multiple transports with
a VirtioTransport field, so users of the library can manually specify
a transport for each device. To avoid breaking the compatibility, if
VirtioTransport is empty a behavior equivalent to the legacy one is
achieved by checking runtime.GOARCH and Config.Machine.Type.

Keeping support for isVirtioPCI/isVirtioCCW in qmp.go is a bit
tricky. Eventually, the hot-plug API should be extended so callers
must manually specify the transport for the device.

Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-02-07 18:17:12 +01:00
Alice Frosi
6d6b2d8892 s390x: add s390x travis support
Since we have travis support for s390x. Let's enable it

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
2019-12-17 14:54:09 +01:00
Mark Ryan
d6173077f1 Run tests for the s390x build
It turns out it is possible to run the unit tests for the s390x build
on travis by renaming the s390x specific files, so that their
inclusion in the build is determined only by tags and not by filename,
and by introducing a new tag s390x_test that we can use to force
their inclusion into a build by using this tag.  The .travis file is
then updated to include the line

go test --tags s390x_test ./...

This creates a build on travis that includes the s390x specific
files and runs the unit tests.

Signed-off-by: Mark Ryan <mark.d.ryan@intel.com>
2018-12-03 15:56:20 +01:00
Alice Frosi
c80fc3b12f qemu: Add s390x support
The PR adds the s390x support. It sets the CCW devices and sets to false
all the devices in the mapping isVirtioPCI. It reimplements the functions
QemuNetdevParam and QemuDeviceParam to print an error message if the vhost-user
devices are used. It introduces a new function ExecuteNetCCWDeviceAdd for qmp
for the CCW devices.

Fixes: #37

Co-authored-by: Yash D Jain <ydjainopensource@gmail.com>
Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
2018-11-30 10:13:28 +01:00