Re: [Qemu-devel] [Question] Question about ACPI table in qemu

On 11/09/2018 18:54, Li Qiang wrote: > Hi all, > > I noticed that both qemu and seabios create the ACPI table. > Once I think he bios' ACPI table will overwrite the qemu's if seabios > compiled with CONFIG_ACPI. Yes, SeaBIOS's ACPI tables are not used anymore, to remove the need to update QEMU

[Qemu-devel] [Question] Question about ACPI table in qemu

Hi all, I noticed that both qemu and seabios create the ACPI table. Once I think he bios' ACPI table will overwrite the qemu's if seabios compiled with CONFIG_ACPI. But after I read this --> https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg04555.html There say: "just have QEMU pass the

Re: [Qemu-devel] [Question] Question about the i440FX device

Thanks Paolo, Paolo Bonzini 于2018年9月10日周一 上午7:11写道： > On 07/09/2018 08:32, Li Qiang wrote: > > Hello all, > > > > I want to know why the i440FX in the following 'info qtree' information > is > > laid under the pci.0 bus. In the chip spec here: > >

Re: [Qemu-devel] [Question] Question about the i440FX device

On 07/09/2018 08:32, Li Qiang wrote: > Hello all, > > I want to know why the i440FX in the following 'info qtree' information is  > laid under the pci.0 bus.  In the chip spec here: > -->https://wiki.qemu.org/images/b/bb/29054901.pdf > I don't see this device. > > Can anyone give me some hints?

[Qemu-devel] [Question] Question about the i440FX device

Hello all, I want to know why the i440FX in the following 'info qtree' information is laid under the pci.0 bus. In the chip spec here: -->https://wiki.qemu.org/images/b/bb/29054901.pdf I don't see this device. Can anyone give me some hints? Thanks, Li Qiang bus: main-system-bus type System

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

On 12/25/2017 01:33 AM, He Junyan wrote: hi all: I am now focusing on snapshot optimization for Intel NVDimm kind memory. Different from the normal memory, the NVDimm may be 128G, 256G or even more for just one guest, and its speed is slower than the normal memory. So sometimes it may take

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

On 三, 2018-01-10 at 20:17 +, Stefan Hajnoczi wrote: > On Wed, Jan 10, 2018 at 8:15 PM, Dr. David Alan Gilbert > wrote: > > > > * Stefan Hajnoczi (stefa...@gmail.com) wrote: > > > > > > On Tue, Jan 9, 2018 at 7:55 PM, Dr. David Alan Gilbert > > >

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

On Wed, Jan 10, 2018 at 8:15 PM, Dr. David Alan Gilbert wrote: > * Stefan Hajnoczi (stefa...@gmail.com) wrote: >> On Tue, Jan 9, 2018 at 7:55 PM, Dr. David Alan Gilbert >> wrote: >> >> Certain guest operations like rebooting or zeroing memory will defeat

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

* Stefan Hajnoczi (stefa...@gmail.com) wrote: > On Tue, Jan 9, 2018 at 7:55 PM, Dr. David Alan Gilbert > wrote: > >> Certain guest operations like rebooting or zeroing memory will defeat > >> the incremental guest RAM snapshot feature. It's worth thinking about > >> these

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

On Tue, Jan 9, 2018 at 7:55 PM, Dr. David Alan Gilbert wrote: >> Certain guest operations like rebooting or zeroing memory will defeat >> the incremental guest RAM snapshot feature. It's worth thinking about >> these cases to make sure this feature would be worth it in real

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

* Stefan Hajnoczi (stefa...@gmail.com) wrote: > On Mon, Dec 25, 2017 at 07:54:00AM +, He, Junyan wrote: > > I am now focusing on snapshot optimization for Intel NVDimm kind memory. > > Different from the normal memory, the NVDimm may be 128G, 256G or even more > > for just one guest, and its

Re: [Qemu-devel] Some question about savem/qcow2 incremental snapshot

On Mon, Dec 25, 2017 at 07:54:00AM +, He, Junyan wrote: > I am now focusing on snapshot optimization for Intel NVDimm kind memory. > Different from the normal memory, the NVDimm may be 128G, 256G or even more > for just one guest, and its speed is slower than the normal memory. So >

Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.

Le 08/01/2018 à 20:56, Mark Cave-Ayland a écrit : Thanks for the patch! I'm afraid I don't really have any experience with LEON as my focus is sun4m/sun4u, however I'm happy to take patches Acked/Reviewed by Fabien as the current LEON maintainer I am waiting for Fabien feedback after my

Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.

On 02/01/18 11:13, Jean-Christophe DUBOIS wrote: Hi Mark, Artyom, I am wondering if the IRQMP code in hw/intc/grlib_irqmp.c is correct when it comes to acknowledging interrupts. With the actual code an interrupt can be lowered/acked only by an "ack" from the processor which means that the

Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.

Hi, So after trying my code on tsim, I can confirm that the software is indeed able to clear/ack the interrupt without requiring the ack from the processor. Things are a bit strange with tsim as the simulator doesn't seem to respect time delay when the processor is in sleep/idle mode and

Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.

Le 2018-01-02 19:58, Fabien Chouteau a écrit : Hello Jean-Christophe, I'm the original author of this patch and I add in copy my colleague Frederic. On 02/01/2018 12:13, Jean-Christophe DUBOIS wrote: I am wondering if the IRQMP code in hw/intc/grlib_irqmp.c is correct when it comes to

Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.

Hello Jean-Christophe, I'm the original author of this patch and I add in copy my colleague Frederic. On 02/01/2018 12:13, Jean-Christophe DUBOIS wrote: > I am wondering if the IRQMP code in hw/intc/grlib_irqmp.c is correct > when it comes to acknowledging interrupts. > > With the actual code an

[Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.

Hi Mark, Artyom, I am wondering if the IRQMP code in hw/intc/grlib_irqmp.c is correct when it comes to acknowledging interrupts. With the actual code an interrupt can be lowered/acked only by an "ack" from the processor which means that the trap handler related to this external interrupt

[Qemu-devel] Some question about savem/qcow2 incremental snapshot

hi all: I am now focusing on snapshot optimization for Intel NVDimm kind memory. Different from the normal memory, the NVDimm may be 128G, 256G or even more for just one guest, and its speed is slower than the normal memory. So sometimes it may take several minutes to complete just one snapshot

[Qemu-devel] Some question about savem/qcow2 incremental snapshot

hi all: I am now focusing on snapshot optimization for Intel NVDimm kind memory. Different from the normal memory, the NVDimm may be 128G, 256G or even more for just one guest, and its speed is slower than the normal memory. So sometimes it may take several minutes to complete just one

Re: [Qemu-devel] coroutine question, for NBD debugging

On 03/11/2017 21:03, Eric Blake wrote: > In include/qemu/coroutine.h, we have: > > /** > * Yield the coroutine for a given duration > * > * Behaves similarly to co_sleep_ns(), but the sleeping coroutine will be > * resumed when using aio_poll(). > */ > void coroutine_fn

Re: [Qemu-devel] coroutine question, for NBD debugging

On 11/03/2017 03:03 PM, Eric Blake wrote: > In include/qemu/coroutine.h, we have: > > /** > * Yield the coroutine for a given duration > * > * Behaves similarly to co_sleep_ns(), but the sleeping coroutine will be > * resumed when using aio_poll(). > */ > void coroutine_fn

[Qemu-devel] coroutine question, for NBD debugging

In include/qemu/coroutine.h, we have: /** * Yield the coroutine for a given duration * * Behaves similarly to co_sleep_ns(), but the sleeping coroutine will be * resumed when using aio_poll(). */ void coroutine_fn co_aio_sleep_ns(AioContext *ctx, QEMUClockType type, but there is no

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On Fri, Oct 20, 2017 at 15:04:57 +0200, David Hildenbrand wrote: > On 20.10.2017 14:50, Jiri Denemark wrote: > > The thing is libvirt calls query-cpu-model-expansion to check what the > > host CPU is. This 'host-model' CPU is replaced with the probed CPU model > > when a domain starts. The problem

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

> > I intend to put some brain-power in this too. Probably next week. > > My general impression is, that I have a at places different understanding > of how things should work compared to David. Especially when it comes > to this concept of persistent copying, and also an end-user-digestible >

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 10/20/2017 04:12 PM, Christian Borntraeger wrote: > > > On 10/20/2017 04:06 PM, David Hildenbrand wrote: >> On 20.10.2017 16:02, Christian Borntraeger wrote: >>> >>> >>> On 10/20/2017 03:51 PM, David Hildenbrand wrote: >>> [...] > The problem goes much further. > A fresh guest with

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 10/20/2017 04:06 PM, David Hildenbrand wrote: > On 20.10.2017 16:02, Christian Borntraeger wrote: >> >> >> On 10/20/2017 03:51 PM, David Hildenbrand wrote: >> [...] The problem goes much further. A fresh guest with hvm does not

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 20.10.2017 16:02, Christian Borntraeger wrote: > > > On 10/20/2017 03:51 PM, David Hildenbrand wrote: > [...] >>> The problem goes much further. >>> A fresh guest with >>> >>> >>> hvm >>> >>> >>> >>> does not start. No migration from an older system is necessary. >>> >> >>

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 10/20/2017 03:51 PM, David Hildenbrand wrote: [...] >> The problem goes much further. >> A fresh guest with >> >> >> hvm >> >> >> >> does not start. No migration from an older system is necessary. >> > > Yes, as stated in the documentation "copying host CPU definition from

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 20.10.2017 15:49, Christian Borntraeger wrote: > > > On 10/20/2017 03:43 PM, David Hildenbrand wrote: >> On 20.10.2017 15:36, Christian Borntraeger wrote: >>> >>> >>> On 10/20/2017 03:16 PM, David Hildenbrand wrote: > Hi all, > > we recently encountered the problem that the

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 10/20/2017 03:43 PM, David Hildenbrand wrote: > On 20.10.2017 15:36, Christian Borntraeger wrote: >> >> >> On 10/20/2017 03:16 PM, David Hildenbrand wrote: >>> Hi all, we recently encountered the problem that the 'host-model' [1] has to be related to the machine type of a

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 20.10.2017 15:36, Christian Borntraeger wrote: > > > On 10/20/2017 03:16 PM, David Hildenbrand wrote: >> >>> Hi all, >>> >>> we recently encountered the problem that the 'host-model' [1] has to be >>> related to the machine type of a domain. We have following problem: >>> >>>Let's assume

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 10/20/2017 03:16 PM, David Hildenbrand wrote: > >> Hi all, >> >> we recently encountered the problem that the 'host-model' [1] has to be >> related to the machine type of a domain. We have following problem: >> >>Let's assume we've a z13 system with a QEMU 2.9 and we define a >>

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

> Hi all, > > we recently encountered the problem that the 'host-model' [1] has to be > related to the machine type of a domain. We have following problem: > >Let's assume we've a z13 system with a QEMU 2.9 and we define a >domain using the default s390-virtio-ccw machine together with

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 20.10.2017 14:50, Jiri Denemark wrote: > On Fri, Oct 20, 2017 at 13:37:42 +0200, David Hildenbrand wrote: >> On 20.10.2017 13:09, Marc Hartmayer wrote: >>> we recently encountered the problem that the 'host-model' [1] has to be >>> related to the machine type of a domain. We have following

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On Fri, Oct 20, 2017 at 13:37:42 +0200, David Hildenbrand wrote: > On 20.10.2017 13:09, Marc Hartmayer wrote: > > we recently encountered the problem that the 'host-model' [1] has to be > > related to the machine type of a domain. We have following problem: > > > >Let's assume we've a z13

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On Fri, Oct 20, 2017 at 13:09:26 +0200, Marc Hartmayer wrote: > we recently encountered the problem that the 'host-model' [1] has to be > related to the machine type of a domain. We have following problem: > >Let's assume we've a z13 system with a QEMU 2.9 and we define a >domain using

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On 20.10.2017 13:09, Marc Hartmayer wrote: > On Thu, Oct 12, 2017 at 02:07 PM +0200, Jiri Denemark > wrote: >> On Mon, Oct 09, 2017 at 10:16:48 +0200, Marc Hartmayer wrote: >>> On Thu, Oct 05, 2017 at 02:11 PM +0200, Jiri Denemark >>> wrote: But

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

On Thu, Oct 12, 2017 at 02:07 PM +0200, Jiri Denemark wrote: > On Mon, Oct 09, 2017 at 10:16:48 +0200, Marc Hartmayer wrote: >> On Thu, Oct 05, 2017 at 02:11 PM +0200, Jiri Denemark >> wrote: >> > But it's going to be a bit complicated because we ask

Re: [Qemu-devel] HDMI Question

On Wed, Sep 27, 2017 at 5:31 AM, Ni, Xingrong wrote: > Hello, > > I am using qemu and hit a question and would like to ask here, can we > simulate a HDMI device in Qemu, if so, how to do it? Hello, I don't see any reason why you can't. We (Xilinx) have a display port

[Qemu-devel] HDMI Question

Hello, I am using qemu and hit a question and would like to ask here, can we simulate a HDMI device in Qemu, if so, how to do it? Thanks & Best Wishes! Rocky

Re: [Qemu-devel] question：a question about throttle and hot-unplug

On Thu 14 Sep 2017 11:41:40 AM CEST, WangJie (Captain) wrote: > the patch you commited: > https://github.com/qemu/qemu/commit/7ca7f0f6db1fedd28d490795d778cf23979a2aa7#diff-ea36ba0f79150cc299732696a069caba > > remove blk_io_limits_disable from blk_remove_bs > > Then, if a disk which configured

[Qemu-devel] question：a question about throttle and hot-unplug

Hi, Kevin the patch you commited: https://github.com/qemu/qemu/commit/7ca7f0f6db1fedd28d490795d778cf23979a2aa7#diff-ea36ba0f79150cc299732696a069caba remove blk_io_limits_disable from blk_remove_bs Then, if a disk which configured qos hot-unplug from VM, the backend of the disk reminds in

[Qemu-devel] [RESEND] Question about the userfaultfd write-protect support

(Add Zhanghailiang and Gonglei) Hi Andrea, We've implemented a demo of KVM live memory snapshot based on the userfaultfd write-protect series in your private tree(https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/log/). We did a little hack on that series to make the demo works.

Re: [Qemu-devel] slirp: question about using SMB on windows host with linux guest

am using qemu 2.9.0. Best Regards / Mit freundlichen Grüßen / 敬具, Mark. -Original Message- From: Michael Tokarev [mailto:m...@tls.msk.ru] Sent: Sunday, May 14, 2017 02:47 To: FONNEMANN Mark <mark.fonnem...@hexagon.com>; qemu-devel@nongnu.org Subject: Re: [Qemu-devel] slirp: qu

Re: [Qemu-devel] slirp: question about using SMB on windows host with linux guest

07.05.2017 00:30, FONNEMANN Mark write: > Hello- > > I am trying to shares files between Windows host and Linux guest using > slirp’s built-in SMB server. There's no such thing as "slirp built-in SMB Server". Qemu does not have an SMB server built-in, qemu uses samba to provide smb

Re: [Qemu-devel] slirp: question about using SMB on windows host with linux guest

>I am trying to shares files between Windows host and Linux guest using slirp’s >built-in SMB server. >I start QEMU 2.9.0 using the following: > >C:\Program Files\qemu>qemu-system-i386.exe -readconfig >\Users\mfonnemann\qemu.cfg -net nic -net user,smb=\Users\mfonnemann\smb > >I then try to mount

[Qemu-devel] slirp: question about using SMB on windows host with linux guest

Hello- I am trying to shares files between Windows host and Linux guest using slirp’s built-in SMB server. I start QEMU 2.9.0 using the following: C:\Program Files\qemu>qemu-system-i386.exe -readconfig \Users\mfonnemann\qemu.cfg -net nic -net user,smb=\Users\mfonnemann\smb I then try to mount

Re: [Qemu-devel] quick question about live VM migration

On Mon, Apr 10, 2017 at 01:07:14PM -0700, Vinod Chegu wrote: > Hello, > > A very basic question... > > In a vanilla KVM env. (i.e. non open stack etc) when a VM is live migrated > to another host does the MAC address of the vNICs and the DHCP IP address > for these interfaces remain the same ?

[Qemu-devel] quick question about live VM migration

Hello, A very basic question... In a vanilla KVM env. (i.e. non open stack etc) when a VM is live migrated to another host does the MAC address of the vNICs and the DHCP IP address for these interfaces remain the same ? Thought the answer was a yes as the goal is to minimize disruption to the

Re: [Qemu-devel] [libvirt] Question regarding Snapshots

On 02/27/2017 07:17 AM, Kashyap Chamarthy wrote: > On Mon, Feb 27, 2017 at 01:33:56PM +0100, Kashyap Chamarthy wrote: > > [...] > Can you make a snapshot, then go back to the base and ignore that snapshot like a closed branch, make another snapshot, and then go back and forth from

Re: [Qemu-devel] [libvirt] Question regarding Snapshots

On Mon, Feb 27, 2017 at 01:33:56PM +0100, Kashyap Chamarthy wrote: [...] > > > Can you make a snapshot, then go back to the base and ignore that snapshot > > > like a closed branch, make another snapshot, and then go back and forth > > > from each to each? > > If you edit the '--disk' element

Re: [Qemu-devel] A question about PCI device address spaces

On Mon, Dec 26, 2016 at 01:01:34PM +0200, Marcel Apfelbaum wrote: > On 12/22/2016 11:42 AM, Peter Xu wrote: > > Hello, > > > > Hi Peter, > > > Since this is a general topic, I picked it out from the VT-d > > discussion and put it here, just want to be more clear of it. > > > > The issue is,

Re: [Qemu-devel] A question about PCI device address spaces

On 12/22/2016 11:42 AM, Peter Xu wrote: Hello, Hi Peter, Since this is a general topic, I picked it out from the VT-d discussion and put it here, just want to be more clear of it. The issue is, whether we have exposed too much address spaces for emulated PCI devices? Now for each PCI

Re: [Qemu-devel] A question about PCI device address spaces

On Fri, Dec 23, 2016 at 11:21:53AM +, Peter Maydell wrote: > On 22 December 2016 at 09:42, Peter Xu wrote: > > Hello, > > > > Since this is a general topic, I picked it out from the VT-d > > discussion and put it here, just want to be more clear of it. > > > > The issue is,

Re: [Qemu-devel] A question about PCI device address spaces

On 22 December 2016 at 09:42, Peter Xu wrote: > Hello, > > Since this is a general topic, I picked it out from the VT-d > discussion and put it here, just want to be more clear of it. > > The issue is, whether we have exposed too much address spaces for > emulated PCI devices?

Re: [Qemu-devel] A question about PCI device address spaces

On Thu, Dec 22, 2016 at 05:42:40PM +0800, Peter Xu wrote: > Hello, > > Since this is a general topic, I picked it out from the VT-d > discussion and put it here, just want to be more clear of it. > > The issue is, whether we have exposed too much address spaces for > emulated PCI devices? > >

Re: [Qemu-devel] A question about PCI device address spaces

On 22/12/2016 10:42, Peter Xu wrote: > Hello, > > Since this is a general topic, I picked it out from the VT-d > discussion and put it here, just want to be more clear of it. > > The issue is, whether we have exposed too much address spaces for > emulated PCI devices? > > Now for each PCI

[Qemu-devel] A question about PCI device address spaces

Hello, Since this is a general topic, I picked it out from the VT-d discussion and put it here, just want to be more clear of it. The issue is, whether we have exposed too much address spaces for emulated PCI devices? Now for each PCI device, we are having PCIDevice::bus_master_as for the

Re: [Qemu-devel] virtIO question

On Mon, Nov 14, 2016 at 08:36:39PM +0800, zhun...@gmail.com wrote: > I have a question about qemu.is it a bug in qemu version 1.2? > in qemu version 1.2 ,it set avail event by the code : > if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) { > vring_avail_event(vq,

Re: [Qemu-devel] virtIO question

On Sat, Nov 12, 2016 at 04:43:21PM +0800, zhun...@gmail.com wrote: > Thanks,the expression is not the key problem,I just write it wrong,the key > problem is that what I get from the code is everytime dirver add a sg ,it > will call virtqueue_kick,such as network driver,in start_xmit function ,it

[Qemu-devel] virtIO question

I have a question about qemu.is it a bug in qemu version 1.2? in qemu version 1.2 ,it set avail event by the code : if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) { vring_avail_event(vq, vring_avail_idx(vq)); } and in version 2.7 the code is if

Re: [Qemu-devel] virtIO question

??is qemu handle buffer faster than driver add it?? thank you very much! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-11 20:03 To: zhun...@gmail.com CC: qemu Subject: Re: Re: [Qemu-devel] virtIO question On Thu, Nov 10, 2016 at 08:16:38PM +0800, zhun...@gmail.com wrote: > F

Re: [Qemu-devel] virtIO question

virtqueue_kick ,why it handle like this??can you explain it to me??thank you very much!!! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-11 20:03 To: zhun...@gmail.com CC: qemu Subject: Re: Re: [Qemu-devel] virtIO question On Thu, Nov 10, 2016 at 08:16:38PM +0800, zhun...@gmail.com

Re: [Qemu-devel] virtIO question

¼šzhun...@gmail.com 抄é€�：qemu <qemu-devel@nongnu.org> 主题：Re: Re: [Qemu-devel] virtIO question On Thu, Nov 10, 2016 at 08:16:38PM +0800, zhun...@gmail.com wrote: > From this point of view ,I think it make sense well, thank you very much! > but I have another que

Re: [Qemu-devel] virtIO question

On Thu, Nov 10, 2016 at 08:16:38PM +0800, zhun...@gmail.com wrote: > From this point of view ,I think it make sense well, thank you very much! > but I have another question about notify mechanism between virtIO driver and > qemu. > according the source code of Linux and qemu, > when driver add a

Re: [Qemu-devel] virtIO question

I describe it clearly.or can you give me an example to prove how it make sense!! thanks a lot! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-10 18:32 To: zhun...@gmail.com CC: jkhasdev; qemu Subject: Re: [Qemu-devel] virtIO question On Wed, Nov 09, 2016 at 06:58:16PM +0800, zhun...@g

Re: [Qemu-devel] virtIO question

On Wed, Nov 09, 2016 at 06:58:16PM +0800, zhun...@gmail.com wrote: > I want to ask a another question,why a virt_queue in virtio include in_sgs > and out_sgs,for example,send_queue of virtIO net driver have in_sgs and > out_sgs，when transmit data,It add buffer to out_sgs of send_queue,but how it

Re: [Qemu-devel] virtIO question

Date: 2016-11-05 23:41 To: Peter Maydell CC: zhun...@gmail.com; qemu-devel Subject: Re: [Qemu-devel] virtIO question Have you looked at the virtio specification? No. This describes the overall structure and communication mechanism, which QEMU and Linux each only implement one half of: http

Re: [Qemu-devel] virtIO question

m,qemu-devel <qemu-devel@nongnu.org> 主题：Re: [Qemu-devel] virtIO question Have you looked at the virtio specification? No.  This describes the overall structure and communication mechanism, which QEMU and Linux each only implement one half of: [1

Re: [Qemu-devel] virtIO question

> > Have you looked at the virtio specification? No. > This describes > the overall structure and communication mechanism, which > QEMU and Linux each only implement one half of: > http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html Thanks Peter. This doc looks me interesting.

Re: [Qemu-devel] virtIO question

On 5 November 2016 at 14:46, jitendra kumar khasdev wrote: > here is what I find difficulty in understanding the code, > > 1. Qemu virtio datastructures are not so clear. > 2. I didn't find any sort high level design with respective qemu for virtIO. > 3. How qemu virtIO and

Re: [Qemu-devel] virtIO question

Hi All, I am also exploring virtio implementation in qemu, I try to understand virtio in linux(guest) and qemu, but I am not able to understand I/O stack between linux to qemu. here is what I find difficulty in understanding the code, 1. Qemu virtio datastructures are not so clear. 2. I didn't

[Qemu-devel] virtIO question

who can explain the means of idx in VRingUsed and VRingAvail structure about virtIO?? thanks! zhun...@gmail.com

Re: [Qemu-devel] A question about virtual machine communication with Guest through serial device

On Mon, Oct 31, 2016 at 06:41:23AM +, Liu Pedroa wrote: > Hi Everyone. > > > I have a sample question. As the subset description. > > > Guest OS : Ubuntu OS > > QEMU : linux kernel 4.8 > > > so i want the virtual client OS can communication( can send and receive > messages

[Qemu-devel] A question about virtual machine communication with Guest through serial device

Hi Everyone. I have a sample question. As the subset description. Guest OS : Ubuntu OS QEMU : linux kernel 4.8 so i want the virtual client OS can communication( can send and receive messages through serial device) with Guest OS. what should i do?

Re: [Qemu-devel] A question about this commit "char: convert from GIOChannel to QIOChannel"

- Original Message - > From: "wangyunjian" > To: "Paolo Bonzini" > Cc: berra...@redhat.com, qemu-devel@nongnu.org, "caihe" > Sent: Monday, October 17, 2016 4:17:45 PM > Subject: RE: A question about this commit "char:

Re: [Qemu-devel] A question about this commit "char: convert from GIOChannel to QIOChannel"

In function tcp_chr_close, the s->sioc needs call object_unref() to be released ? About the below code: @@ -3205,10 +3205,13 @@ static void tcp_chr_close(CharDriverState *chr) s->listen_tag = 0; } if (s->listen_ioc) { object_unref(OBJECT(s->listen_ioc)); } +

[Qemu-devel] A question about this commit "char: convert from GIOChannel to QIOChannel"

Commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2 “char: convert from GIOChannel to QIOChannel”, about the below code segment： ・・・ ・・・ @@ -3107,22 +2965,16 @@ static void tcp_chr_close(CharDriverState *chr) s->reconnect_timer = 0; } qapi_free_SocketAddress(s->addr); -if

Re: [Qemu-devel] A question about this commit "char: convert from GIOChannel to QIOChannel"

- Original Message - > From: "wangyunjian" > To: berra...@redhat.com, pbonz...@redhat.com, qemu-devel@nongnu.org > Cc: "caihe" > Sent: Monday, October 17, 2016 3:02:32 PM > Subject: A question about this commit "char: convert from GIOChannel to

Re: [Qemu-devel] A question about postcopy safety

On Mon, Sep 05, 2016 at 02:52:14PM +0100, Dr. David Alan Gilbert wrote: > * liut...@yahoo.com (liut...@yahoo.com) wrote: > > Hi David, > > Hi Liutao, > > > I'm studying the process of postcopy migration, and I found that the memory > > pages migrated from source to destination are not

Re: [Qemu-devel] A question about postcopy safety

* liut...@yahoo.com (liut...@yahoo.com) wrote: > Hi David, Hi Liutao, > I'm studying the process of postcopy migration, and I found that the memory > pages migrated from source to destination are not encrypted. Does this make > the VM vulnerable if it's memory has been tampered with during

Re: [Qemu-devel] A question about postcopy safety

On Mon, Aug 29, 2016 at 12:51:20PM +, liut...@yahoo.com wrote: > Hi David,I'm studying the process of postcopy migration, and I found > that the memory pages migrated from source to destination are not > encrypted. Does this make the VM vulnerable if it's memory has been > tampered with during

Re: [Qemu-devel] a question

On 26 August 2016 at 10:31, Michael Rolnik wrote: > I want to partially implement AT STK500 board in order to run FreeRTOS AVR > / ATMegaAVR demo. > if you look into ATmega32 documentation you will see that, for example, > Timer/Countet1 registers are held together at memory

[Qemu-devel] a question

Hi all, I want to partially implement AT STK500 board in order to run FreeRTOS AVR / ATMegaAVR demo. if you look into ATmega32 documentation you will see

Re: [Qemu-devel] A question about this commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2

On Thu, Aug 25, 2016 at 01:21:47PM +, Gaohaifeng (A) wrote: > On Tue, Aug 23, 2016 at 08:57:44AM +, Gaohaifeng (A) wrote: > > Hi Daniel & Paolo, > > > > > > Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", about > > > > > > the below code segment: > > > > > > -static

Re: [Qemu-devel] A question about this commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2

On Tue, Aug 23, 2016 at 08:57:44AM +, Gaohaifeng (A) wrote: > Hi Daniel & Paolo, > > > > Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", about > > > > the below code segment: > > > > -static gboolean tcp_chr_read(GIOChannel *chan, GIOCondition cond, > > void *opaque) > >

Re: [Qemu-devel] A question about this commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2

On Tue, Aug 23, 2016 at 08:57:44AM +, Gaohaifeng (A) wrote: > Hi Daniel & Paolo, > > Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", about > > the below code segment: > > -static gboolean tcp_chr_read(GIOChannel *chan, GIOCondition cond, void > *opaque) > +static gboolean

[Qemu-devel] A question about this commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2

Hi Daniel & Paolo, Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", about the below code segment: -static gboolean tcp_chr_read(GIOChannel *chan, GIOCondition cond, void *opaque) +static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) {

Re: [Qemu-devel] A question about tb_next_offset[2]

On 26 July 2016 at 19:49, Kartik Ramkrishnan wrote: > Hello all, > >I am running an i386 binary in user mode using qemu. > >In the code, I am looking for the next location that the simulated > program counter jumps to when a TranslationBlock completes execution. This >

[Qemu-devel] A question about tb_next_offset[2]

Hello all, I am running an i386 binary in user mode using qemu. In the code, I am looking for the next location that the simulated program counter jumps to when a TranslationBlock completes execution. This address should be the guest address, not the address on the host. I found a

Re: [Qemu-devel] A question about 9894dc0cdcc397ee5b26370bc53da6d360a363c2

Hi, I got it, thanks for your quick reply :) Regards, -Gonglei > -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: Monday, July 18, 2016 5:07 PM > To: Gonglei (Arei) > Cc: Paolo Bonzini; Lilijun (Jerry); qemu-devel@nongnu.org > Subject: Re: A question

Re: [Qemu-devel] A question about 9894dc0cdcc397ee5b26370bc53da6d360a363c2

On Mon, Jul 18, 2016 at 08:41:32AM +, Gonglei (Arei) wrote: > Hi Daniel & Paolo, > > Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", > about the below code segment: > > static bool qemu_chr_open_socket_fd(CharDriverState *chr, Error **errp) > { > TCPCharDriver *s =

[Qemu-devel] A question about 9894dc0cdcc397ee5b26370bc53da6d360a363c2

Hi Daniel & Paolo, Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", about the below code segment: static bool qemu_chr_open_socket_fd(CharDriverState *chr, Error **errp) { TCPCharDriver *s = chr->opaque; -int fd; +QIOChannelSocket *sioc = qio_channel_socket_new();

Re: [Qemu-devel] [Nbd] question on ioctl NBD_SET_FLAGS

On 20 Apr 2016, at 17:18, Wouter Verhelst wrote: > Hi Eric, > > On Wed, Apr 20, 2016 at 09:42:02AM -0600, Eric Blake wrote: > [...] >> But in 3.9, the overlap bug was still present, and the set of global >> flags had grown to include NBD_FLAG_NO_ZEROS (commit 038e066), which >>

Re: [Qemu-devel] [Nbd] question on ioctl NBD_SET_FLAGS

Hi Eric, On Wed, Apr 20, 2016 at 09:42:02AM -0600, Eric Blake wrote: [...] > But in 3.9, the overlap bug was still present, and the set of global > flags had grown to include NBD_FLAG_NO_ZEROS (commit 038e066), which > overlaps with NBD_FLAG_READ_ONLY. Ouch. This means that a client > talking

Re: [Qemu-devel] TCG question reg. tcg_cpu_exec()

On 14/03/2016 16:26, Pranith Kumar wrote: > I am trying to understand what scenarios can result in no TBs > executing for that CPU. My understanding is that there is a pending > operation which needs to be handled before we can execute TBs from > this CPU(I/O?). For example the CPU could be

[Qemu-devel] TCG question reg. tcg_cpu_exec()

Hello Paolo, I have a question reg. tcg_cpu_exec(cpu) which is called from tcg_exec_all(). tcg_cpu_exec() is called for each cpu in a loop. I observed that this call does not always execute TBs on that particular CPU. It return because the exit_request is set. I am trying to understand what

Re: [Qemu-devel] Quick question on NVME on qemu

On Sat, 10 Oct 2015 00:39:43 -0700 sahlot arvind wrote: > Hello, > > Does qemu emulate a proper NVMe controller? Can someone please tell me how s far as I'm aware, QEMU doesn't emulate any NVMe controller yet. > can I use it to emulate a proper NVMe controller? Is there

Re: [Qemu-devel] Quick question on NVME on qemu

Am 12.10.2015 um 10:05 hat Igor Mammedov geschrieben: > On Sat, 10 Oct 2015 00:39:43 -0700 > sahlot arvind wrote: > > > Hello, > > > > Does qemu emulate a proper NVMe controller? Can someone please tell me how > s far as I'm aware, QEMU doesn't emulate any NVMe controller

  1   2   3   >