Hi Michael,
On Mon, Dec 25, 2023 at 11:06:35AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 20, 2023 at 12:37:17PM +0800, Leo Yan wrote:
> > This series is to refactor vhost stub vhost-user-input.
> >
> > Since vhost input stub requires set_config() callback for co
The Virtio input device invokes set_config() callback for retrieving
the event configuration info, but the callback is not supported in
vhost-user-base.
This patch adds support set_config() callback in vhost-user-base.
Signed-off-by: Leo Yan
Reviewed-by: Marc-André Lureau
---
hw/virtio/vhost
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan
---
MAINTAINERS | 1 +
docs/system/device-emulation.rst | 1 +
docs/system/devices/vhost-user-input.rst | 45
docs/system/devices/vhost-user.rst | 4
changing folder for vhost-user-input.c. (Manos)
Leo Yan (4):
hw/virtio: Support set_config() callback in vhost-user-base
docs/system: Add vhost-user-input documentation
hw/virtio: Move vhost-user-input into virtio folder
hw/virtio: derive vhost-user-input from vhost-user-ba
vhost-user-input is in the input folder. On the other hand, the folder
'hw/virtio' maintains other virtio stubs (e.g. I2C, RNG, GPIO, etc).
This patch moves vhost-user-input into the virtio folder for better code
organization. No functionality change.
Signed-off-by: Leo Yan
---
MAINTAINERS
the duplicate property from
vhost-user-input-pci.
Signed-off-by: Leo Yan
---
hw/virtio/vhost-user-input-pci.c | 3 -
hw/virtio/vhost-user-input.c | 114 +--
include/hw/virtio/virtio-input.h | 6 +-
3 files changed, 21 insertions(+), 102 deletions(-)
diff --git
Hi Marc-André,
+ Mathieu for vhost RNG stuff.
On Tue, Nov 14, 2023 at 01:54:50PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Mon, Nov 13, 2023 at 11:04 PM Leo Yan wrote:
[...]
> > @@ -2233,6 +2233,7 @@ L: virtio...@redhat.com
> > virtio-input
> > M: Gerd Hoffman
458672-1-alex.ben...@linaro.org>
>
>
> That patchset is deferred until after the release, so this one
> will be, too. I have tagged it, to help make sure it's not
> lost pls ping me after the release.
Just remind, I have sent v2.
And will monitor mailing list for the release.
Thanks,
Leo
vhost-user-input is in the input folder. On the other hand, the folder
'hw/virtio' maintains other virtio stubs (e.g. I2C, RNG, GPIO, etc).
This patch moves vhost-user-input into the virtio folder for better code
organization. No functionality change.
Signed-off-by: Leo Yan
---
MAINTAINERS
the duplicate property from
vhost-user-input-pci.
Signed-off-by: Leo Yan
---
hw/virtio/vhost-user-input-pci.c | 3 -
hw/virtio/vhost-user-input.c | 114 +--
include/hw/virtio/virtio-input.h | 6 +-
3 files changed, 21 insertions(+), 102 deletions(-)
diff --git
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan
---
MAINTAINERS | 1 +
docs/system/devices/vhost-user-input.rst | 44
docs/system/devices/vhost-user.rst | 2 +-
3 files changed, 46 insertions(+), 1 deletion
The Virtio input device invokes set_config() callback for retrieving
the event configuration info, but the callback is not supported in
vhost-user-base.
This patch adds support set_config() callback in vhost-user-base.
Signed-off-by: Leo Yan
---
hw/virtio/vhost-user-base.c | 17
ase.
Based-on: <20231107180752.3458672-1-alex.ben...@linaro.org>
Changes from v1:
- Fixed typo in vhost-user-input.rst.
- Updated MAINTAINERS for new added input document and
changing folder for vhost-user-input.c.
Leo Yan (4):
hw/virtio: Support set_config() callback in vhost-user-base
docs/system
Hi Manos,
On Mon, Nov 13, 2023 at 09:24:09AM +0200, Manos Pitsidianakis wrote:
> Hello Leo,
>
> On Mon, 13 Nov 2023 03:16, Leo Yan wrote:
> > vhost-user-input is in the input folder. On the other hand, the folder
> > 'hw/virtio' maintains other virtio stubs (e.g
On Mon, Nov 13, 2023 at 09:16:40AM +0800, Leo Yan wrote:
> This adds basic documentation for vhost-user-input.
>
> Signed-off-by: Leo Yan
> ---
> docs/system/devices/vhost-user-input.rst | 44
> docs/system/devices/vhost-user.rst | 2 +-
>
vhost-user-input is in the input folder. On the other hand, the folder
'hw/virtio' maintains other virtio stubs (e.g. I2C, RNG, GPIO, etc).
This patch moves vhost-user-input into the virtio folder for better code
organization. No functionality change.
Signed-off-by: Leo Yan
---
hw/input
ase.
Based-on: <20231107180752.3458672-1-alex.ben...@linaro.org>
Leo Yan (4):
hw/virtio: Support set_config() callback in vhost-user-base
docs/system: Add vhost-user-input documentation
hw/virtio: Move vhost-user-input into virtio folder
hw/virtio: derive vhost-user-input from vhost-user-base
doc
the duplicate property from
vhost-user-input-pci.
Signed-off-by: Leo Yan
---
hw/virtio/vhost-user-input-pci.c | 3 -
hw/virtio/vhost-user-input.c | 114 +--
include/hw/virtio/virtio-input.h | 6 +-
3 files changed, 21 insertions(+), 102 deletions(-)
diff --git
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan
---
docs/system/devices/vhost-user-input.rst | 44
docs/system/devices/vhost-user.rst | 2 +-
2 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 docs/system/devices/vhost
The Virtio input device invokes set_config() callback for retrieving
the event configuration info, but the callback is not supported in
vhost-user-base.
This patch adds support set_config() callback in vhost-user-base.
Signed-off-by: Leo Yan
---
hw/virtio/vhost-user-base.c | 17
From: Leo Hou
cpu_by_arch_id() uses hartid-base as the index to obtain the corresponding
CPUState structure variable.
qemu_get_cpu() uses cpu_index as the index to obtain the corresponding CPUState
structure variable.
In heterogeneous CPU or multi-socket scenarios, multiple aclint needs
Just to test the email address, no reply required.
hi , all
Does qemu plan to support CPU heterogeneity?
On Thu, Oct 26, 2023 at 01:06:21PM +0800, Leo Yan wrote:
> On Wed, Oct 25, 2023 at 11:18:41AM -0600, Mathieu Poirier wrote:
> > Since the driver doesn't support interrupts, we must return early when
> > index is set to VIRTIO_CONFIG_IRQ_IDX. Basically the same thing
tifier helpers for
> VIRTIO_CONFIG_IRQ_IDX".
>
> Fixes: 544f0278afca ("virtio: introduce macro VIRTIO_CONFIG_IRQ_IDX")
> Signed-off-by: Mathieu Poirier
Tested this patch and the vhost-user-i2c device works with it:
Tested-by: Leo Yan
,
> void *data)
> mc->init = xen_arm_init;
> mc->max_cpus = 1;
> mc->default_machine_opts = "accel=xen";
> +/* Set explicitly here to make sure that real ram_size is passed */
> +mc->default_ram_size = 0;
This patch fails to apply on my side
Why can't I receive a subscription reply email?
Hmm… so this dates back quite long ago unfortunately, I had basically
forgotten about this bug report as I had opened it while just
experimenting with qemu.
To the best of my recollection, this was happening with a NixOS, either
16.09, 17.03 or unstable, at an update that was probably within 0-2
On Fri, Apr 17, 2020 at 5:34 PM John Snow wrote:
>
>
> On 4/17/20 6:57 PM, Leo Luan wrote:
> > On Fri, Apr 17, 2020 at 1:24 PM Eric Blake > <mailto:ebl...@redhat.com>> wrote:
> >
> > On 4/17/20 3:11 PM, John Snow wrote:
> >
On Fri, Apr 17, 2020 at 1:24 PM Eric Blake wrote:
> On 4/17/20 3:11 PM, John Snow wrote:
>
> >> +
> >> +if (s->sync_mode == MIRROR_SYNC_MODE_FULL &&
> >> + s->bcs->target->bs->drv != NULL &&
> >> + strncmp(s->bcs->target->bs->drv->format_name, "qcow2", 5) == 0
> &&
> >> +
On Fri, Apr 17, 2020 at 1:11 PM John Snow wrote:
>
>
> On 4/17/20 2:33 PM, Leo Luan wrote:
> > When doing a full backup from a single layer qcow2 disk file to a new
> > qcow2 file, the backup_run function does not unset unallocated parts in
> > the copy bit map. The
When doing a full backup from a single layer qcow2 disk file to a new qcow2
file, the backup_run function does not unset unallocated parts in the copy
bit map. The subsequent backup_loop call goes through these unallocated
clusters unnecessarily. In the case when the target and source reside in
e target file is a new empty qcow2 file without a backing
file? If so, maybe a
knob can be added to effect this behavior?
I guess the related code is changing in 5.0 and this issue may already
be adddressed.
Any updates/insights would be appreciated!
Thanks,
Leo
*From*: Eric Blake
*Subject
information do *not* use
EPYC-specific macros, like MAX_NODES_EPYC.
Leo.
> -Original Message-
> From: Moger, Babu
> Sent: Monday, May 21, 2018 7:41 PM
> To: m...@redhat.com; marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> r...@twiddle.net; ehabk...@redhat.com; mtosa...@redhat
On 05/24/2017 10:54 AM, Greg Kurz wrote:
> On Wed, 24 May 2017 00:59:29 +0200
> Leo Gaspard <l...@gaspard.io> wrote:
>
>> On 05/23/2017 04:32 PM, Greg Kurz wrote:
>>> v2: - posted patch for CVE-2017-7493 separately
>>> - other changes availa
ch larger attack surface than one internal to virtfs
mapped-file only. Then the question of what is reasonably possible to
forbid to the user arises, and that's not one I could answer.
Cheers & HTH,
Leo
signature.asc
Description: OpenPGP digital signature
On 05/23/2017 04:32 PM, Greg Kurz wrote:
> v2: - posted patch for CVE-2017-7493 separately
> - other changes available in each patch changelog
>
> Leo,
>
> If you find time to test this series, I'll gladly add your Tested-by: to
> it before merging.
Just tested
nk.
Thank you,
Leo
On 05/05/2017 04:36 PM, Greg Kurz wrote:
> This series fixes two issues in the local backend when using the mapped-file
> security mode:
> - allow chmod and chown to succeed on the virtfs root (patch 4)
> - completely hide the metadata files from the client (patch 5)
Public bug reported:
With
-virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
in the qemu command line,
shared2 on /mnt/testbis type 9p
(rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
in the guest mount points, and
tmpfs on /tmp type tmpfs
Hmm, actually it looks like a kernel in kernel panic always takes 100%
CPU (just got another unrelated one), so I guess it's not necessarily a
qemu bug but can arise from anywhere in the stack. I'm marking the bug
as invalid as a consequence.
** Changed in: qemu
Status: New => Invalid
--
Oh, I forgot to mention: it first worked for some time, then in the
middle of a shell session running over a screen
/var/lib/vm/consoles/nginx/screen from the outer VM (socat-linked to
/var/lib/vm/consoles/nginx/socket.unix to provide a predictable pty
link), the 9pfs stopped returning any data,
Public bug reported:
tl;dr: A virtfs read fails. The init being on this virtfs (mounted by
the initrd), the linux kernel guest is unable to boot, and kernel
panics. The fact that qemu still takes 100%cpu after the kernel panic
makes me think it's a qemu bug.
Here is the setup (some hashes
This has just happened to me. For some reason, all my machines had
machine='pc-i440fx-wily'.
After an update in yakkety, they stopped working.
$ qemu-system-x86_64 -enable-kvm -machine help | grep wily
So I updated the machine xml to a supported machine as Charles
suggested, and they work
xen code
(hw/block/xendisk.o), complaining that ioservid_t is declared twice,
first as 16bit and then as 32bit.
Output of make:
CChw/block/xen_disk.o
In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
from /home/leo/qemu/hw/block/xen_disk.c:39:
/h
variables.
Trying to compile the code, it stops when compiling the xen code
(hw/block/xendisk.o), complaining that ioservid_t is declared twice,
first as 16bit and then as 32bit.
Output of make:
CChw/block/xen_disk.o
In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0
Public bug reported:
I have Qemu Manager on my Windows 8.1 laptop and have a WXP iso and a
blank disk image (from here
http://www.mediafire.com/download/rtec86bwwmee00s/Blank_Disk.zip ) and
as soon as I try to open it I get a Runtime Error (
http://i.gyazo.com/bfebf7e1e7a670f8e52cc95c5923a67e.png
,
Am 02.07.2011 um 08:13 schrieb Leo Chen.:
qemu-system-mipsel -M mipssim -nographic -kernel bin/test.elf
or
qemu-system-mipsel -M malta -nographic -kernel bin/test.elf
The use of -kernel for a random ELF executable looks strange, even if it
happens to work on arm. Have you tried -bios
Hi, all
I am trying to run a standalone C program Hello World on qemu-system-mipsel,
but it failed to print the message via serial port.
What I have done now (step by step):
1. Successfully run a standalone C program Hello World on qemu-system-arm, by
following this guide:
Hi I would like to know the status of these issues in Qemu 0.13
1.I saw that as recently as this year there was work being done on
Completeing Big Real Mode Emulation which should help old OS to run such as
Windows1.01-Windows 98 so my question is is this support complete now do
these OS run on
A while back I know someone was working on PPC Support in Qemu to be able to
run Mac OS9-Mac OS X in Qemu on X86 PC's not sure about M68K support though
so is anybody still working on M68K support or PPC Support and how far is it
from being included in a stable Qemu release,I notice Power PC
c1 e0 08 66 81 e7 ff 00 66 09 f8
0Kernel panic - not syncing: Attempted to kill init!
Hope this helps someone!
Cheers
--
Leo Antunes
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http
51 matches
Mail list logo
