similar to: VirtIO-MMIO on MMU-less System

On 21 June 2013 19:01, Christopher Covington <cov at codeaurora.org> wrote: > Anyhow, I just did a quick experiment with 0-size block devices, and they seem > to work for me, although trying to mount the device yields the confusing > message, "mount: mounting /dev/vda on mount failed: Invalid argument". I'm confused -- what's the significance of zero size block

On 21 June 2013 19:01, Christopher Covington <cov at codeaurora.org> wrote: > Anyhow, I just did a quick experiment with 0-size block devices, and they seem > to work for me, although trying to mount the device yields the confusing > message, "mount: mounting /dev/vda on mount failed: Invalid argument". I'm confused -- what's the significance of zero size block

On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org> wrote: > You were proposing to use a valid/existing MagicValue/Version/VendorID with a > special DeviceID that does nothing. I'm saying why not use a valid/existing > MagicValue/Version/VendorID/DeviceID with a special parameter setting, size=0, > that does nothing? Ah, I see. Well, it sounds from your

On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org> wrote: > You were proposing to use a valid/existing MagicValue/Version/VendorID with a > special DeviceID that does nothing. I'm saying why not use a valid/existing > MagicValue/Version/VendorID/DeviceID with a special parameter setting, size=0, > that does nothing? Ah, I see. Well, it sounds from your

On 20 June 2013 13:58, Christopher Covington <cov at codeaurora.org> wrote: >> On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: >>> 1. One question I've run into is: what should a virtio-mmio transport >>> with no backend look like to the guest OS? The spec as written >>> seems to assume that there's always some backend present. >>>

On 20 June 2013 13:58, Christopher Covington <cov at codeaurora.org> wrote: >> On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: >>> 1. One question I've run into is: what should a virtio-mmio transport >>> with no backend look like to the guest OS? The spec as written >>> seems to assume that there's always some backend present. >>>

Hi everybody, Wanted to hear your opinion and to receive a smart advice. I'm trying to use virt-v2v in order to convert ova image (exported from vcenter) to run on libvirt/kvm - all this inside a VM of fedora. The converted image is also a fedora. During the conversion process, in some point of libguestfs activity, I get double fault panic from L2 (printed as part of libguest output) and the

On 21 June 2013 17:02, Christopher Covington <cov at codeaurora.org> wrote: > Would using CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES enumeration > instead of device tree be any easier? My general view is that the kernel command line is the user's to manipulate, and that QEMU shouldn't touch it at all (just pass it through). (Conversely, QEMU shouldn't require the user to specify

On 21 June 2013 17:02, Christopher Covington <cov at codeaurora.org> wrote: > Would using CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES enumeration > instead of device tree be any easier? My general view is that the kernel command line is the user's to manipulate, and that QEMU shouldn't touch it at all (just pass it through). (Conversely, QEMU shouldn't require the user to specify

On 21 June 2013 17:47, Pawel Moll <pawel.moll at arm.com> wrote: > On Fri, 2013-06-21 at 17:41 +0100, Peter Maydell wrote: >> As it happens, if you use the command line to specify >> a virtio device it doesn't make the same complaint about >> bad magic number as if you specify it via dtb, but that >> should probably be fixed in the kernel :-) > > I

On 21 June 2013 17:47, Pawel Moll <pawel.moll at arm.com> wrote: > On Fri, 2013-06-21 at 17:41 +0100, Peter Maydell wrote: >> As it happens, if you use the command line to specify >> a virtio device it doesn't make the same complaint about >> bad magic number as if you specify it via dtb, but that >> should probably be fixed in the kernel :-) > > I

On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: > I'm (finally) trying to add virtio-mmio support properly to > QEMU now Fred has put all the refactoring foundations in place. > > 1. One question I've run into is: what should a virtio-mmio transport > with no backend look like to the guest OS? The spec as written > seems to assume that there's always some

On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: > I'm (finally) trying to add virtio-mmio support properly to > QEMU now Fred has put all the refactoring foundations in place. > > 1. One question I've run into is: what should a virtio-mmio transport > with no backend look like to the guest OS? The spec as written > seems to assume that there's always some

Anton Korobeynikov wrote: > Ok, what's left from QEMU then? :) The hardware emulation (interrupts, condition flags, register file etc) and execution framework (block selection and execution) from qemu are still used - translating the ARM to the native architecture is only part of the story :) > >> generating reasonable code - this approach keeps it in place while we do

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8

Hi Andrew, On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery <andrew at aj.id.au> wrote: > TCG seperates the guest (ARM) code into blocks - my front end translates > these to LLVM IR for LLVM to translate to x86.  The assumption is that LLVM > will produce a better translation than TCG*. At some future point the > TCG-generated native block is replaced by the LLVM's, and as

On 21. Aug 2020, at 11:20, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote: >> Hi Daniel, >>> On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: >>> On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote: >>>> On 21. Aug 2020, at 10:38, Daniel P. Berrangé

Hi Daniel, > On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote: >> On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: >>> On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >>>> Hi Lists, >>>> >>>> I currently

On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >> Hi Lists, >> >> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. >> >> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu >> when starting an

On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: > To get the interrupt reason to support such VIRTIO_NET_F_STATUS > features I add a new register offset VIRTIO_MMIO_ISRMEM which > will help to establish a shared memory region between qemu and > virtio-mmio device. Then the interrupt reason can be accessed by > guest driver through this region. At the