Le 14/07/2018 à 03:07, David Gibson a écrit :
> On Fri, Jul 13, 2018 at 07:34:46AM -0500, Shivaprasad G Bhat wrote:
>> Qemu includes the glibc headers for the host defines and target headers are
>> part of the qemu source themselves. The glibc has the F_GETLK64, F_SETLK64
>> and F_SETLKW64 defined
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1575607
Title:
vm
On 7/14/2018 12:15 AM, Michael S. Tsirkin Wrote:
> On Fri, Jul 13, 2018 at 05:04:05PM +0300, Yury Kotov wrote:
>> virtio_queue_get_desc_addr returns 64-bit hwaddr while int is usually 32-bit.
>> If returned hwaddr is not equal to 0 but least-significant 32 bits are
>> equal to 0 then this code
On Fri, Jul 13, 2018 at 07:34:46AM -0500, Shivaprasad G Bhat wrote:
> Qemu includes the glibc headers for the host defines and target headers are
> part of the qemu source themselves. The glibc has the F_GETLK64, F_SETLK64
> and F_SETLKW64 defined to 12, 13 and 14 for all archs in
>
On Fri, 2018-07-13 at 10:11 -0400, konrad.w...@oracle.com wrote:
> (Apologies if this comes out as HTML, using Thunderbird instead of mutt
> here)..
>
> > +uint64_t pred_cmd;
> > +uint64_t arch_capabilities;
>
> Could this be 'arch_cap' ?
>
> >
> > /* End of state preserved by
On Fri, Jul 13, 2018 at 10:27:29AM +0200, Thomas Huth wrote:
> A lot of code is using the object_initialize() function followed by a call
> to object_property_add_child() to add the newly initialized object as a child
> of the current object. Both functions increase the reference counter of the
>
On Thu, Jul 12, 2018 at 08:29:27PM +0300, Viktor Prutyanov wrote:
> This patch adds field with content of KERNEL_GS_BASE MSR to QEMU note in
> ELF dump.
>
> On Windows, if all vCPUs are running usermode tasks at the time the dump is
> created, this can be helpful in the discovery of guest system
On Fri, Jul 13, 2018 at 10:27:28AM +0200, Thomas Huth wrote:
> As discovered recently, you can crash QEMU with a lot of devices
> that do not get the reference counting of child objects right.
> You just have to run 'device-list-properties' and call 'info qtree'
> afterwards.
> This patch series
On Fri, Jul 13, 2018 at 10:27:37AM +0200, Thomas Huth wrote:
> Running QEMU with valgrind indicates a problem here:
>
> echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
> "'arguments':{'typename':'a9mpcore_priv'}}" \
> "{'execute': 'human-monitor-command', " \
>
On Fri, Jul 13, 2018 at 10:27:36AM +0200, Thomas Huth wrote:
> Valgrind currently reports a problem when running QEMU like this:
>
> echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
> "'arguments':{'typename':'msf2-soc'}}" \
> "{'execute': 'human-monitor-command', "
On Fri, Jul 13, 2018 at 10:27:35AM +0200, Thomas Huth wrote:
> QEMU currently crashes when e.g. doing something like this:
>
> echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
> "'arguments':{'typename':'xlnx,zynqmp'}}" \
> "{'execute': 'human-monitor-command', " \
>
On Fri, Jul 13, 2018 at 10:27:33AM +0200, Thomas Huth wrote:
> There is a memory management problem when introspecting the a15mpcore_priv
> device. It can be seen with valgrind when running QEMU like this:
>
> echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
>
On Fri, Jul 13, 2018 at 11:29:17PM +0200, Andreas Färber wrote:
> Am 13.07.2018 um 23:16 schrieb Eduardo Habkost:
> > I wonder if we should deprecate object_initialize() and support
> > only object_initialize_child() later. Initializing an object
> > contained inside another one without making it
On Fri, Jul 13, 2018 at 10:27:32AM +0200, Thomas Huth wrote:
> QEMU currently crashes when introspecting the "iotkit" device and
> runnint "info qtree" afterwards, e.g. when running QEMU like this:
>
> echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
>
Am 13.07.2018 um 23:16 schrieb Eduardo Habkost:
> I wonder if we should deprecate object_initialize() and support
> only object_initialize_child() later. Initializing an object
> contained inside another one without making it a child of the
> parent object is a recipe for trouble.
The root
On Fri, Jul 13, 2018 at 10:27:31AM +0200, Thomas Huth wrote:
> When trying to "device_add bcm2837" on a machine that is not suitable for
> this device, you can quickly crash QEMU afterwards, e.g. with "info qtree":
>
> echo "{'execute':'qmp_capabilities'} {'execute':'device_add', " \
>
On Fri, Jul 13, 2018 at 10:27:30AM +0200, Thomas Huth wrote:
> A lot of functions are initializing an object and attach it immediately
> afterwards to the system bus. Provide a common function for this, which
> also uses object_initialize_child() to make sure that the reference
> counter is
On Fri, Jul 13, 2018 at 10:27:29AM +0200, Thomas Huth wrote:
> A lot of code is using the object_initialize() function followed by a call
> to object_property_add_child() to add the newly initialized object as a child
> of the current object. Both functions increase the reference counter of the
>
On Fri, 13 Jul 2018 13:22:31 +0530
Pankaj Gupta wrote:
> This patch adds virtio-pmem driver for KVM guest.
>
> Guest reads the persistent memory range information from Qemu over
> VIRTIO and registers it on nvdimm_bus. It also creates a nd_region
> object with the persistent memory range
On Fri, 13 Jul 2018 13:22:30 +0530
Pankaj Gupta wrote:
> This patch adds functionality to perform flush from guest to host
> over VIRTIO. We are registering a callback based on 'nd_region' type.
> As virtio_pmem driver requires this special flush interface, for rest
> of the region types we are
On Fri, Jul 13, 2018 at 11:07:15AM +0200, Thomas Huth wrote:
> On 12.07.2018 21:45, Eduardo Habkost wrote:
> > The documentation for QOM is not clear about who owns references
> > to objects (i.e. who is responsible for calling object_unref()
> > later).
> >
> > This is important considering
On Thu, Jul 12, 2018 at 08:29:27PM +0300, Viktor Prutyanov wrote:
> This patch adds field with content of KERNEL_GS_BASE MSR to QEMU note in
> ELF dump.
>
> On Windows, if all vCPUs are running usermode tasks at the time the dump is
> created, this can be helpful in the discovery of guest system
On 07/13/2018 03:41 PM, Max Reitz wrote:
> The test directory should be filtered before the image format, otherwise
> the test will fail if the image format is part of the test directory,
> like so:
>
> [...]
> -can't open: Could not open 'TEST_DIR/t.IMGFMT': Is a directory
> +can't open:
The test directory should be filtered before the image format, otherwise
the test will fail if the image format is part of the test directory,
like so:
[...]
-can't open: Could not open 'TEST_DIR/t.IMGFMT': Is a directory
+can't open: Could not open '/tmp/test-IMGFMT/t.IMGFMT': Is a directory
On 07/13/2018 03:15 PM, Max Reitz wrote:
> 223 tests persistent dirty bitmaps which are not supported in
> compat=0.10, so that option is unsupported for this test.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/223 | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
223 tests persistent dirty bitmaps which are not supported in
compat=0.10, so that option is unsupported for this test.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/223 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/qemu-iotests/223 b/tests/qemu-iotests/223
index
Hi
On Wed, Jul 11, 2018 at 6:25 PM, Igor Mammedov wrote:
> On Wed, 4 Jul 2018 18:00:41 +0200
> Marc-André Lureau wrote:
>
>> HI
>>
>> On Wed, Jul 4, 2018 at 5:39 PM, Igor Mammedov wrote:
>> > On Thu, 28 Jun 2018 19:26:57 +0200
>> > Marc-André Lureau wrote:
>> >
>> >> From: Stefan Berger
>>
The simple trace backend spawns a write-out thread which is used to
asynchronously flush the in-memory ring buffer to disk.
fork(2) does not clone all threads, only the thread that invoked
fork(2). As a result there is no write-out thread in the child process!
This causes a hang during shutdown
The simple trace backend spawns a write-out thread which is used to
asynchronously flush the in-memory ring buffer to disk.
fork(2) does not clone all threads, only the thread that invoked
fork(2). As a result there is no write-out thread in the child process!
This causes a hang during shutdown
On 07/13/2018 03:10 AM, Kevin Wolf wrote:
> The test case uses block devices with driver=file, which causes the test
> to fail after commit 230ff73904 added a deprecation warning for this.
> Fix the test case to use driver=host_device and update the reference
> output accordingly.
>
>
* guangrong.x...@gmail.com (guangrong.x...@gmail.com) wrote:
> From: Xiao Guangrong
>
> flush_compressed_data() needs to wait all compression threads to
> finish their work, after that all threads are free until the
> migration feed new request to them, reducing its call can improve
> the
* Xiao Guangrong (guangrong.x...@gmail.com) wrote:
>
>
> On 07/11/2018 04:21 PM, Peter Xu wrote:
> > On Thu, Jun 28, 2018 at 05:33:58PM +0800, Xiao Guangrong wrote:
> > >
> > >
> > > On 06/19/2018 03:36 PM, Peter Xu wrote:
> > > > On Mon, Jun 04, 2018 at 05:55:15PM +0800,
This test doesn't actually care about the format anyway, it just
supports "all formats" as a convenience. LUKS however does not use a
simple image filename which confuses this iotest.
We can simply skip the test for formats that use IMGOPTSSYNTAX for
their filenames without missing much coverage.
On 13/07/2018 17:59, Thomas Huth wrote:
> Your patch looks good at a first quick glance, but it seems not to work as
> expected: When I now run QEMU like this:
>
> echo "{'execute':'qmp_capabilities'}" \
> "{'execute':'device-list-properties'," \
> "'arguments':{'typename':'xlnx,zynqmp'}}" \
>
On 07/13/2018 03:09 AM, Kevin Wolf wrote:
> Am 13.07.2018 um 00:12 hat John Snow geschrieben:
>> This test doesn't actually care about the format anyway, it just
>> supports "all formats" as a convenience. LUKS however does not use a
>> simple image filename which confuses this iotest.
>>
>> We
On Tue, Jul 10, 2018 at 17:00:09 +0100, Peter Maydell wrote:
> When we support execution from non-RAM MMIO regions, get_page_addr_code()
> will return -1 to indicate that there is no RAM at the requested address.
> Handle this in the cpu-exec TB hashtable lookup code, treating it as
> "no match
On Tue, Jul 10, 2018 at 17:00:11 +0100, Peter Maydell wrote:
> If get_page_addr_code() returns -1, this indicates that there is no RAM
> page we can read a full TB from. Instead we must create a TB which
> contains a single instruction and which we do not cache, so it is
> executed only once.
>
>
* Peter Xu (pet...@redhat.com) wrote:
> On Mon, Jun 04, 2018 at 05:55:18PM +0800, guangrong.x...@gmail.com wrote:
> > From: Xiao Guangrong
> >
> > Current implementation of compression and decompression are very
> > hard to be enabled on productions. We noticed that too many wait-wakes
> > go to
On Fri, Jul 13, 2018 at 05:04:05PM +0300, Yury Kotov wrote:
> virtio_queue_get_desc_addr returns 64-bit hwaddr while int is usually 32-bit.
> If returned hwaddr is not equal to 0 but least-significant 32 bits are
> equal to 0 then this code will not actually stop running queue.
>
> Signed-off-by:
Our bad. Change-Id tag snuck into those from gerrit
(https://review.gerrithub.io/c/davidsaOpenu/qemu/+/415434).
Took a note to replace this line with "[PATCH v2]" but, I guess, it makes
sense
if additional comments will follow, right?
Thanks for taking a look.
On 12 July 2018 at 14:47, Kevin
Switching the resolution with -vga std was working fine before, I'm not
sure on which version it started having this issue, but it should be on
a recent version.
I use the intel i915 drivers on the host OS.
--
You received this bug notification because you are a member of qemu-
devel-ml, which
Hi Diego,
It seems this is a known limitation[1] because horizontal width is not a
multiple of 8, try 1360x768 as the nearest resolution, which works for
me on guests not supporting QXL drivers.
Regards.
[1] Proposed patch from 2013: https://lists.gnu.org/archive/html/qemu-
Public bug reported:
I am currently using QEMU on a Arch Linux host, the guest OS is also
Arch Linux.
The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the
command line I'm using to fire an Arch VM is:
$ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4
The problem
Hi
I checked in on the QEMU advent calendar side of which I have very fond
memories. I'm very impressed and grateful for the work that you've put into
this site. My question to you is the following, what are your plans for the
continuation of the program?
In case there's anything I can do I'll
Hi Francisco, thanks for your quick reply.
I've tried `xrandr --output Virtual-1 --mode 1360x768' with -vga std and
I also get a corrupted image.
I'm attaching a screenshot of what the screen corruption looks like
after changing the resolution.
Thanks.
** Attachment added: "qemu.png"
On 07/04/2018 01:24 PM, Cornelia Huck wrote:
On Fri, 29 Jun 2018 18:48:02 -0400
Tony Krowiak wrote:
Introduces a VFIO based AP device. The device is defined via
the QEMU command line by specifying:
-device vfio-ap,sysfsdev=
There may be only one vfio-ap device configured for a guest.
On 13.07.2018 13:13, Paolo Bonzini wrote:
> On 13/07/2018 10:27, Thomas Huth wrote:
>> aux_create_slave() calls qdev_init_nofail() which in turn "realizes"
>> the corresponding object. Thus this most not be called from an
>> instance_init function. Move the code to the realize function instead.
>>
Add a model of the NRF51 random number generator peripheral.
Signed-off-by: Steffen Görtz
---
Changes since v3:
- Replace bitfields
- Add VMState / reset
- Add reference to reference manual
Changes since v2:
- Add missing 'qapi/error.h' for error_abort
Changes since v1:
- Add
On 12 July 2018 at 17:48, Kevin Loughlin wrote:
> I know TrustZone has support for memory virtualization in AArch64, but I'm
> looking to create a different model. Namely, I'd like to fully virtualize
> the memory map for the "virt" board.
>
> As a basic example of what I want, assuming an
On 12 July 2018 at 17:37, Peter Maydell wrote:
> On 11 July 2018 at 05:21, Philippe Mathieu-Daudé wrote:
>> I applied and quickly tested your series on a MIPS SoC I'm working on
>> which has a tiny SRAM:
>>
>> (qemu) info mtree
>> address-space: memory
>> -
We set up TLB entries in tlb_set_page_with_attrs(), where we have
some logic for determining whether the TLB entry is considered
to be RAM-backed, and thus has a valid addend field. When we
look at the TLB entry in get_page_addr_code(), we use different
logic for determining whether to treat the
On 13/07/2018 16:55, Marc-André Lureau wrote:
> -return;
> +} else {
> +int rc = qemu_chr_fe_write(>chr, >tsr, 1);
> +
> +if ((rc == 0 ||
> + (rc == -1 && (errno == EAGAIN || errno == EINTR))) &&
> +s->tsr_retry <
Hi
On Tue, Jul 10, 2018 at 3:48 PM, Igor Mammedov wrote:
> On Tue, 5 Jun 2018 11:18:35 +0200
> Paolo Bonzini wrote:
>
>> On 05/06/2018 09:54, Sergio Lopez wrote:
>> > Only retry on serial_xmit if qemu_chr_fe_write returns 0, as this is the
>> > only recoverable error.
>> >
>> > Retrying with
On Fri, Jul 13, 2018 at 04:44:49PM +0200, Paolo Bonzini wrote:
> On 13/07/2018 16:11, konrad.w...@oracle.com wrote:
> > (Apologies if this comes out as HTML, using Thunderbird instead of mutt
> > here)..
> >
> >> + uint64_t pred_cmd;
> >> + uint64_t arch_capabilities;
> >
> > Could this be
On 07/12/2018 03:37 PM, Peter Maydell wrote:
> On 29 June 2018 at 14:29, Luc Michel wrote:
>> Add the read/write functions to handle accesses to the vCPU interface.
>> Those accesses are forwarded to the real CPU interface, with the CPU id
>> being converted to the corresponding vCPU id (vCPU
On 13/07/2018 16:11, konrad.w...@oracle.com wrote:
> (Apologies if this comes out as HTML, using Thunderbird instead of mutt
> here)..
>
>> + uint64_t pred_cmd;
>> + uint64_t arch_capabilities;
>
> Could this be 'arch_cap' ?
>
Why? Intel chose a verbose name, we should not abbrev. it
In commit 4b1a3e1e34ad97 we added a check for whether the TLB entry
we had following a tlb_fill had the INVALID bit set. This could
happen in some circumstances because a stale or wrong TLB entry was
pulled out of the victim cache. However, after commit
68fea038553039e (which prevents stale
This patchset fixes a bug in get_page_addr_code()'s
lookup of the address in the victim TLB, which was another
source of "we end up with an invalid TLB entry even after
we've done a TLB fill for it".
The second patch then removes a check that we had that was
working around the existence of the
In get_page_addr_code(), we were incorrectly looking in the victim
TLB for an entry which matched the target address for reads, not
for code accesses. This meant that we could hit on a victim TLB
entry that indicated that the address was readable but not
executable, and incorrectly bypass the call
(Apologies if this comes out as HTML, using Thunderbird instead of mutt here)..
+uint64_t pred_cmd;
+uint64_t arch_capabilities;
Could this be 'arch_cap' ?
/* End of state preserved by INIT (dummy marker). */
struct {} end_init_save;
diff --git a/target/i386/kvm.c
virtio_queue_get_desc_addr returns 64-bit hwaddr while int is usually 32-bit.
If returned hwaddr is not equal to 0 but least-significant 32 bits are
equal to 0 then this code will not actually stop running queue.
Signed-off-by: Yury Kotov
---
hw/virtio/vhost.c | 4 +---
1 file changed, 1
On Fri, Jul 13, 2018 at 08:40:19AM +0200, Paolo Bonzini wrote:
> On 12/07/2018 18:30, Stefan Hajnoczi wrote:
> > On Wed, Jul 11, 2018 at 03:33:21PM +0200, Cornelia Huck wrote:
> >> The other qemu-nbds (the inet and the unix socket ones from the first
> >> run, the second inet one from the second
On 07/12/2018 03:56 PM, Peter Maydell wrote:
> On 29 June 2018 at 14:29, Luc Michel wrote:
>> Add the gic_update_virt() function to update the vCPU interface states
>> and raise vIRQ and vFIQ as needed. This commit renames gic_update() to
>> gic_update_internal() and generalizes it to handle
On 13 July 2018 at 14:33, Luc Michel wrote:
>
>
> On 07/12/2018 03:56 PM, Peter Maydell wrote:
>> On 29 June 2018 at 14:29, Luc Michel wrote:
>>> Add the gic_update_virt() function to update the vCPU interface states
>>> and raise vIRQ and vFIQ as needed. This commit renames gic_update() to
>>>
Alex Bennée writes:
> From: Philippe Mathieu-Daudé
>
> Signed-off-by: Philippe Mathieu-Daudé
> Signed-off-by: Alex Bennée
> ---
> .shippable.yml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/.shippable.yml b/.shippable.yml
> index f74a3de3ff..9670b13f8e 100644
> ---
Add a base class that is common to virtio-gpu and vhost-user-gpu
devices.
The VirtIOGPUBase base class provides common functionalities necessary
for both virtio-gpu and vhost-user-gpu:
- common configuration (max-outputs, initial resolution, flags)
- virtio device initialization, including queue
Add base classes that are common to vhost-user-gpu-pci and
vhost-user-vga.
Signed-off-by: Marc-André Lureau
---
hw/display/virtio-vga.h | 22 +++
hw/virtio/virtio-pci.h | 16 ++---
hw/display/virtio-gpu-pci.c | 39 +---
hw/display/virtio-vga.c | 122
On 07/12/2018 05:41 PM, Peter Maydell wrote:
> The GICD_ITARGETSR implementation still has some 11MPCore behaviour
> that we were incorrectly using in our GICv1 and GICv2 implementations
> for the case where the interrupt number is less than GIC_INTERNAL.
> The desired behaviour here is:
> *
Let's check renderer_blocked instead directly.
Signed-off-by: Marc-André Lureau
---
include/hw/virtio/virtio-gpu.h | 1 -
hw/display/virtio-gpu.c| 4 +---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index
Add a vhost-user gpu backend example, based on virtio-gpu/3d device. It
is to be associated with a vhost-user-backend object, ex:
-object vhost-user-backend,id=vug,cmd="vhost-user-gpu"
TODO:
- add/check multi-head support
- crash & resume handling
- accelerated rendering/display to avoid the
Now that 2d commands are translated to 3d rendering, qemu must stop
sending 3d updates (from 2d) to Spice as well.
Signed-off-by: Marc-André Lureau
---
include/hw/virtio/virtio-gpu.h | 1 -
hw/display/virtio-gpu-3d.c | 21 -
hw/display/virtio-gpu.c| 25
Add new virtio-gpu devices with a "vhost-user" property. Tthe
associated vhost-user backend is used to handle the virtio rings and
provide rendering results thanks to the vhost-user-gpu protocol.
Example usage:
-object vhost-user-backend,id=vug,cmd="./vhost-user-gpu"
-device
There are variants of qemu_create_pidfile() in qemu-pr-helper and
qemu-ga. Let's have a common implementation in libqemuutil.
The code is based from pr-helper write_pidfile(), but allows the
caller to deal with error reporting and behaviour.
Signed-off-by: Marc-André Lureau
---
vhost-user-gpu will share the same code to open a DRM node.
Signed-off-by: Marc-André Lureau
---
include/qemu/drm.h | 6 +
ui/egl-helpers.c | 51 ++-
util/drm.c | 66 ++
MAINTAINERS| 1 +
According to Daniel Berrange, fcntl() locks have better portable
semantics than lockf().
Use an exclusive lock on the first byte with fcntl().
Signed-off-by: Marc-André Lureau
---
util/oslib-posix.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/util/oslib-posix.c
On 07/12/2018 05:41 PM, Peter Maydell wrote:
> In gic_deactivate_irq() the interrupt number comes from the guest
> (on a write to the GICC_DIR register), so we need to sanity check
> that it isn't out of range before we use it as an array index.
> Handle this in a similar manner to the check we do
Add a new vhost-user message to give a unix socket to a vhost-user
backend for GPU display updates.
Back when I started that work, I added a new GPU channel because the
vhost-user protocol wasn't bidirectional. Since then, there is a
vhost-user-slave channel for the slave to send requests to the
Add a vhost-user input backend, based on virtio-input-host device. It
takes an evdev path as argument, and can be associated with a
vhost-user-backend object, ex:
-object vhost-user-backend,id=vuid,cmd="vhost-user-input /dev/input/event0"
Signed-off-by: Marc-André Lureau
---
See vhost-user.txt protocol documentation for details.
Signed-off-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user.h | 1 +
include/hw/virtio/vhost-backend.h | 1 +
hw/virtio/vhost-user.c| 15 +++
docs/interop/vhost-user.txt | 8
Signed-off-by: Marc-André Lureau
---
include/hw/virtio/virtio-gpu.h | 2 --
hw/display/virtio-gpu.c| 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index c54c903a65..4c68bc4559 100644
---
Add a new virtio-input device, which connects to a vhost-user
backend. Usage:
-object vhost-user-backend,id=vuid \
-device vhost-user-input-pci,vhost-user=vuid
Signed-off-by: Marc-André Lureau
---
hw/virtio/virtio-pci.h | 10 +++
include/hw/virtio/virtio-input.h | 14
Ask vhost user input backend the list of virtio_input_config.
Signed-off-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user.h | 1 +
include/hw/virtio/vhost-backend.h | 4 ++
hw/virtio/vhost-user.c| 59 +++
docs/interop/vhost-user.txt
Split vhost_user_read(), so only header can be read with
vhost_user_read_header().
Signed-off-by: Marc-André Lureau
---
hw/virtio/vhost-user.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index
Signed-off-by: Marc-André Lureau
---
include/hw/virtio/virtio-gpu.h | 1 -
hw/display/virtio-gpu.c| 1 -
2 files changed, 2 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 9780f755ef..c54c903a65 100644
--- a/include/hw/virtio/virtio-gpu.h
Simplify the creation of FD sources for other users.
Signed-off-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user-glib.h | 3 +++
contrib/libvhost-user/libvhost-user-glib.c | 15 +++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
---
hw/virtio/vhost-user.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 44795880d6..5b4188bc27 100644
--- a/hw/virtio/vhost-user.c
Create a vhost-user-backend object that holds a connection to a
vhost-user backend and can be referenced from virtio devices that
support it. See later patches for input & gpu usage.
A chardev can be specified to communicate with the vhost-user backend,
ex: -chardev
The helper functions are useful to build the vhost-user-gpu backend.
Signed-off-by: Marc-André Lureau
---
include/hw/virtio/virtio-gpu-bswap.h | 61
hw/display/virtio-gpu.c | 43 +---
2 files changed, 62 insertions(+), 42 deletions(-)
An executable with its arguments may be given as 'cmd' property, ex:
-object vhost-user-backend,id=vui,cmd="./vhost-user-input
/dev/input..". The executable is then spawn and, by convention, the
vhost-user socket is passed as fd=3. It may be considered a security
breach to allow creating processes
Since commit 2566378d6d13bf4d28c7770bdbda5f7682594bbe, libvhost-user
no longer panics on disconnect (rc == 0), and instead silently ignores
an invalid VHOST_USER_NONE message.
Without extra work from the API user, this will simply busy-loop on
HUP events. The obvious thing to do is to exit(0)
Add a new function to let caller do some tuning thanks to a callback
before exec().
Signed-off-by: Marc-André Lureau
---
include/io/channel-command.h | 18 ++
io/channel-command.c | 33 ++---
2 files changed, 44 insertions(+), 7 deletions(-)
Take a VhostUserState* that can be pre-allocated, and initialize it
with the associated chardev.
Signed-off-by: Marc-André Lureau
Reviewed-by: Tiwei Bie
---
include/hw/virtio/vhost-user-blk.h | 2 +-
include/hw/virtio/vhost-user-scsi.h | 2 +-
include/hw/virtio/vhost-user.h | 2 +-
Hi,
vhost-user allows to drive a virtio device in a seperate
process. After vhost-user-net, we have seen
vhost-user-{scsi,blk,crypto} added more recently.
This series, initially proposed 2 years ago
(https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01905.html)
contributes with
Some scanouts during boot are top-down without it.
y0_top is set from VHOST_USER_GPU_DMABUF_SCANOUT code path in the last
patch of this series.
In current QEMU code base, only vfio/display uses dmabuf API. But the
VFIO query interface doesn't provide or need that detail so far.
Signed-off-by:
There is no obvious reason to have a loop counter. This limits from
reading several megabytes large buffers in one go, since socket
read/write usually have a limit.
Signed-off-by: Marc-André Lureau
Reviewed-by: Paolo Bonzini
---
chardev/char-fe.c | 6 +-
1 file changed, 1 insertion(+), 5
It's possible to write code creating a chardev backend that is not
registered. When it is not user-created, it makes sense to keep it
hidden. Let the associated frontend destroy it also in this case.
Signed-off-by: Marc-André Lureau
---
chardev/char-fe.c | 7 ++-
1 file changed, 6
A socket chardev may not have associated address (when adding client
fd manually for example). But on disconnect, updating socket filename
expects an address and may lead to this crash:
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x55d8c70c in
Commit 435da5e709 didn't convert a fcntl() call to safe_fcntl()
for TARGET_NR_fcntl64 case. There is no reason to not use it
in this case.
Fixes: 435da5e709 linux-user: Use safe_syscall wrapper for fcntl
Signed-off-by: Laurent Vivier
---
linux-user/syscall.c | 2 +-
1 file changed, 1
On 13 July 2018 at 13:36, Richard Henderson
wrote:
> On 07/13/2018 06:05 AM, Peter Maydell wrote:
>>> -if (unlikely(env->tlb_table[mmu_idx][index].addr_code & TLB_RECHECK)) {
>>> +if (unlikely((env->tlb_table[mmu_idx][index].addr_code &
>>> + (TLB_RECHECK |
Qemu includes the glibc headers for the host defines and target headers are
part of the qemu source themselves. The glibc has the F_GETLK64, F_SETLK64
and F_SETLKW64 defined to 12, 13 and 14 for all archs in
sysdeps/unix/sysv/linux/bits/fcntl-linux.h. The linux kernel generic
definition for F_*LK
1 - 100 of 179 matches
Mail list logo
