On Tue, Nov 15, 2016 at 10:38 PM, ashish mittal wrote:
> On Wed, Sep 28, 2016 at 2:45 PM, Stefan Hajnoczi wrote:
>> On Tue, Sep 27, 2016 at 09:09:49PM -0700, Ashish Mittal wrote:
>> 5.
>> I don't see any endianness handling or portable alignment of struct
>> fields in the network protocol code.
On Mon, 11/14 16:29, Paolo Bonzini wrote:
>
>
> On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> > On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> >> QEMU_AIO_POLL_MAX_NS IOPs
> >>unset31,383
> >>146,860
> >>246,
> On 16 Nov 2016, at 04:05, Alexey Kardashevskiy wrote:
>
> On 11/11/16 01:45, Christian Borntraeger wrote:
>> On 11/09/2016 01:44 PM, Felipe Franciosi wrote:
>>> Following the recent refactor of virtio notfiers [1], more specifically
>>> the patch that uses virtio_bus_set_host_notifier [2] by d
The ppc64 postcopy test does not work with KVM-PR, and it is also
causing annoying warning messages when run on a x86 host. So let's
use KVM here only if we know that we're running with KVM-HV (which
automatically also means that we're running on a ppc64 host), and
fall back to TCG otherwise.
Sign
ashish mittal writes:
> Thanks for concluding on this.
>
> I will rearrange the qnio_api.h header accordingly as follows:
>
> +#include "qemu/osdep.h"
Headers should not include osdep.h.
> +#include<=== after osdep.h
> +#include "block/block_int.h"
Including block_int.h in a header is prob
On 16/11/2016 09:39, Thomas Huth wrote:
> The ppc64 postcopy test does not work with KVM-PR, and it is also
> causing annoying warning messages when run on a x86 host. So let's
> use KVM here only if we know that we're running with KVM-HV (which
> automatically also means that we're running on a
Eric Blake writes:
> On 11/15/2016 02:29 PM, Stefan Hajnoczi wrote:
>> It was not obvious to me why "qemu/osdep.h" must be the first #include.
>> This documents the rationale and the overall #include order.
>>
>> Cc: Fam Zheng
>> Cc: Markus Armbruster
>> Cc: Eric Blake
>> Signed-off-by: Stefa
On 16.11.2016 10:19, Laurent Vivier wrote:
>
>
> On 16/11/2016 09:39, Thomas Huth wrote:
>> The ppc64 postcopy test does not work with KVM-PR, and it is also
>> causing annoying warning messages when run on a x86 host. So let's
>> use KVM here only if we know that we're running with KVM-HV (which
On Wed, 11/16 10:04, Markus Armbruster wrote:
> ashish mittal writes:
>
> > Thanks for concluding on this.
> >
> > I will rearrange the qnio_api.h header accordingly as follows:
> >
> > +#include "qemu/osdep.h"
>
> Headers should not include osdep.h.
This is about including "osdep.h" _and_ "qni
Kevin,
> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Am 28.09.2016 um 11:32 hat Pavel Dovgalyuk geschrieben:
> > > > From: Kevin Wolf [mailto:kw...@redhat.com]
> > > > Am 27.09.2016 um 16:06 hat Pavel Dovgalyuk geschrieben:
> > > > > > From:
Hi Michael,
May I should convert all __virtio32/64 to le32/64 in virtio_crypto.h ?
> +#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
> +
> +struct virtio_crypto_ctrl_header {
> +#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CR
The ppc64 postcopy test does not work with KVM-PR, and it is also
causing annoying warning messages when run on a x86 host. So let's
use KVM here only if we know that we're running with KVM-HV (which
automatically also means that we're running on a ppc64 host), and
use TCG otherwise.
Signed-off-by
On 16/11/2016 11:14, Thomas Huth wrote:
> The ppc64 postcopy test does not work with KVM-PR, and it is also
> causing annoying warning messages when run on a x86 host. So let's
> use KVM here only if we know that we're running with KVM-HV (which
> automatically also means that we're running on a
On 16.11.2016 11:18, Laurent Vivier wrote:
>
>
> On 16/11/2016 11:14, Thomas Huth wrote:
>> The ppc64 postcopy test does not work with KVM-PR, and it is also
>> causing annoying warning messages when run on a x86 host. So let's
>> use KVM here only if we know that we're running with KVM-HV (which
On 16/11/2016 11:26, Thomas Huth wrote:
> On 16.11.2016 11:18, Laurent Vivier wrote:
>>
>>
>> On 16/11/2016 11:14, Thomas Huth wrote:
>>> The ppc64 postcopy test does not work with KVM-PR, and it is also
>>> causing annoying warning messages when run on a x86 host. So let's
>>> use KVM here only
On 16/11/2016 09:39, Thomas Huth wrote:
> The ppc64 postcopy test does not work with KVM-PR, and it is also
> causing annoying warning messages when run on a x86 host. So let's
> use KVM here only if we know that we're running with KVM-HV (which
> automatically also means that we're running on a
Hi Richard,
On Tue, Nov 15, 2016 at 10:37:41PM +0100, Richard Henderson wrote:
> On 11/14/2016 10:33 AM, Jin Guojie wrote:
> > I want listen to your advice. Should I test your v2 patch on Loongson
> > and use it? Or whether it is worth modifying my patch and resubmit it
> > according to your revie
On Wed, Nov 16, 2016 at 9:49 AM, Fam Zheng wrote:
> On Wed, 11/16 10:04, Markus Armbruster wrote:
>> ashish mittal writes:
>>
>> > Thanks for concluding on this.
>> >
>> > I will rearrange the qnio_api.h header accordingly as follows:
>> >
>> > +#include "qemu/osdep.h"
>>
>> Headers should not in
> Not sure how independent ERST is from ACPI and other specs. It looks
> like referencing UEFI spec at least.
It is just the format of error records that comes from the UEFI spec
(include/linux/cper.h) but you can ignore it, I think. It should be
handled by tools on the host side. For you, the
On Wed, 16 Nov 2016 09:39:31 +0100
Thomas Huth wrote:
> The ppc64 postcopy test does not work with KVM-PR, and it is also
> causing annoying warning messages when run on a x86 host. So let's
> use KVM here only if we know that we're running with KVM-HV (which
> automatically also means that we're
> I've investigated this issue.
> This command line works ok:
> -drive
>
> driver=blkreplay,if=none,image.driver=file,image.filename=testdisk.qcow,id=img-blkreplay
> -device ide-hd,drive=img-blkreplay
>
> And this does not:
> -drive
> driver=blkreplay,if=none,image.driver=qcow2,image.file.d
Hi Rick,
On 21/10/2016 03:22, Rick Song wrote:
> The platform device class has become abstract. This
> patch introduces a hisilicon hnsvf device that derives
> from it.
in https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03401.html
we discussed the relevance to get the platform device non
Am 16.11.2016 um 10:49 hat Pavel Dovgalyuk geschrieben:
> > From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
> > > From: Kevin Wolf [mailto:kw...@redhat.com]
> > > My command line was assuming a raw image. It looks like you're using a
> > > qcow (hopefully qcow2?) image. If so, then you need to in
Hi,
On 21/10/2016 03:22, Rick Song wrote:
> This patch allows the instantiation of the vfio-hisi-hnsvf device
> from the QEMU command line (-device vfio-hisi-hnsvf,host="").
> A specialized device tree node is created for the guest, containing
> compat, dma-coherent, reg and interrupts properties.
On Tue, 15 Nov 2016 15:34:45 -0200
Eduardo Habkost wrote:
> On Tue, Nov 15, 2016 at 01:17:16PM +0100, Igor Mammedov wrote:
> [...]
> > @@ -1265,6 +1267,8 @@ void pc_machine_done(Notifier *notifier, void *data)
> > if (pcms->fw_cfg) {
> > pc_build_smbios(pcms->fw_cfg);
> > p
* Greg Kurz (gr...@kaod.org) wrote:
> On Wed, 16 Nov 2016 09:39:31 +0100
> Thomas Huth wrote:
>
> > The ppc64 postcopy test does not work with KVM-PR, and it is also
> > causing annoying warning messages when run on a x86 host. So let's
> > use KVM here only if we know that we're running with KVM
On Wed, Nov 16, 2016 at 9:39 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> On 11/15/2016 02:29 PM, Stefan Hajnoczi wrote:
>>> It was not obvious to me why "qemu/osdep.h" must be the first #include.
>>> This documents the rationale and the overall #include order.
>>>
>>> Cc: Fam Zheng
>>
On Wed, 16 Nov 2016 12:24:50 +
"Dr. David Alan Gilbert" wrote:
> * Greg Kurz (gr...@kaod.org) wrote:
> > On Wed, 16 Nov 2016 09:39:31 +0100
> > Thomas Huth wrote:
> >
> > > The ppc64 postcopy test does not work with KVM-PR, and it is also
> > > causing annoying warning messages when run o
On Wed, Nov 16, 2016 at 01:24:11PM +0100, Igor Mammedov wrote:
> On Tue, 15 Nov 2016 15:34:45 -0200
> Eduardo Habkost wrote:
>
> > On Tue, Nov 15, 2016 at 01:17:16PM +0100, Igor Mammedov wrote:
> > [...]
> > > @@ -1265,6 +1267,8 @@ void pc_machine_done(Notifier *notifier, void *data)
> > > i
> If the consensus is that the patch is a QEMU bugfix (as opposed to a
> feature) and that it is eligible for the currently supported upstream
> stable branches, that's the best, no doubt.
The currently supported upstream stable branches is just 2.7. :)
I'm okay with bending the rules and includ
On Tue, Nov 15, 2016 at 04:50:53PM -0600, Wei Huang wrote:
>
>
> On 11/14/2016 09:12 AM, Christopher Covington wrote:
> > Hi Drew, Wei,
> >
> > On 11/14/2016 05:05 AM, Andrew Jones wrote:
> >> On Fri, Nov 11, 2016 at 01:55:49PM -0600, Wei Huang wrote:
> >>>
> >>>
> >>> On 11/11/2016 01:43 AM, An
On Wed, 16 Nov 2016 10:39:33 -0200
Eduardo Habkost wrote:
> On Wed, Nov 16, 2016 at 01:24:11PM +0100, Igor Mammedov wrote:
> > On Tue, 15 Nov 2016 15:34:45 -0200
> > Eduardo Habkost wrote:
> >
> > > On Tue, Nov 15, 2016 at 01:17:16PM +0100, Igor Mammedov wrote:
> > > [...]
> > > > @@ -1265,
Signed-off-by: Igor Mammedov
---
v3:
- Update FW_CFG_NB_CPUS on CPU hot(un)plug to avoid
hang in BIOS on reboot if number of CPUs is over 256
(Eduardo)
---
include/hw/i386/pc.h | 2 ++
hw/i386/pc.c | 44 +++-
2 files changed, 29 insertion
On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote:
> CCing qemu-devel.
>
> CCing Markus, in case he has any insights about the interface
> introspection.
>
> On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
> > On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrot
On 16.11.2016 13:37, Greg Kurz wrote:
> On Wed, 16 Nov 2016 12:24:50 +
> "Dr. David Alan Gilbert" wrote:
>
>> * Greg Kurz (gr...@kaod.org) wrote:
>>> On Wed, 16 Nov 2016 09:39:31 +0100
>>> Thomas Huth wrote:
>>>
The ppc64 postcopy test does not work with KVM-PR, and it is also
c
On Wed, Nov 16, 2016 at 07:47:42AM -0500, Paolo Bonzini wrote:
>
> > If the consensus is that the patch is a QEMU bugfix (as opposed to a
> > feature) and that it is eligible for the currently supported upstream
> > stable branches, that's the best, no doubt.
>
> The currently supported upstream
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> > I've investigated this issue.
> > This command line works ok:
> > -drive
> >
> > driver=blkreplay,if=none,image.driver=file,image.filename=testdisk.qcow,id=img-blkreplay
> > -device ide-hd,drive=img-blkreplay
> >
> > And this does not:
> >
On Thu, Nov 10, 2016 at 12:44:47PM -0700, Alex Williamson wrote:
> On Thu, 10 Nov 2016 21:20:36 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Nov 10, 2016 at 09:04:13AM -0700, Alex Williamson wrote:
> > > On Thu, 10 Nov 2016 17:54:35 +0200
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > O
On 16/11/2016 14:18, Michael S. Tsirkin wrote:
> > - we could have another magic 0xB2 value, which is implemented directly
> > in QEMU and sets 0xB3 to a magic value. Then OVMF can invoke it
> > after SMBASE relocation and SMM IPL (so as not to crash on old QEMUs)
> > to detect the new feature.
On Wed, Nov 16, 2016 at 02:15:02PM +0100, Jiri Denemark wrote:
> On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote:
> > CCing qemu-devel.
> >
> > CCing Markus, in case he has any insights about the interface
> > introspection.
> >
> > On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Den
On Wed, Nov 16, 2016 at 02:04:41PM +0100, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov
Reviewed-by: Eduardo Habkost
--
Eduardo
Hi
On Tue, Oct 18, 2016 at 11:46 AM P J P wrote:
> From: Prasad J Pandit
>
> In Cirrus CLGD 54xx VGA Emulator, if cirrus graphics mode is VGA,
> 'cirrus_get_bpp' returns zero(0), which could lead to a divide
> by zero error in while copying pixel data. The same could occur
> via blit pitch valu
From: Igor Mammedov
PC will use this field in other way, so move it outside the common
code so PC could set a different value, i.e. all CPUs
regardless of where they are coming from (-smp X | -device cpu...).
It's quick and dirty hack as it could be implemented in more generic
way in MashineClas
From: Igor Mammedov
This reverts commit 080ac219cc7d9c55adf925c3545b7450055ad625.
Legacy FW_CFG_NB_CPUS will be reused instead of 'etc/boot-cpus'
fw_cfg file since it does the same and there is no point
to maintaing duplicate guest ABI, if it can be helped.
Signed-off-by: Igor Mammedov
Message
On Wed, 16 Nov 2016 14:17:47 +0100
Thomas Huth wrote:
> On 16.11.2016 13:37, Greg Kurz wrote:
> > On Wed, 16 Nov 2016 12:24:50 +
> > "Dr. David Alan Gilbert" wrote:
> >
> >> * Greg Kurz (gr...@kaod.org) wrote:
> >>> On Wed, 16 Nov 2016 09:39:31 +0100
> >>> Thomas Huth wrote:
> >>>
From: Igor Mammedov
Signed-off-by: Igor Mammedov
Message-Id: <1479301481-197333-1-git-send-email-imamm...@redhat.com>
Reviewed-by: Eduardo Habkost
Signed-off-by: Eduardo Habkost
---
hw/i386/pc.c | 44 +++-
include/hw/i386/pc.h | 2 ++
2 files c
Unfortunately not in time for -rc0, but we still want to remove
"etc/boot-cpus" before 2.8.0 is released.
The following changes since commit b0bcc86d2a87456f5a276f941dc775b265b309cf:
Update version for v2.8.0-rc0 release (2016-11-15 20:55:12 +)
are available in the git repository at:
gi
On Wed, 16 Nov 2016 09:39:31 +0100
Thomas Huth wrote:
> The ppc64 postcopy test does not work with KVM-PR, and it is also
> causing annoying warning messages when run on a x86 host. So let's
> use KVM here only if we know that we're running with KVM-HV (which
> automatically also means that we're
Hey Guys,
I want to get a qmp event when the qemu does a shutdown due to the
-no-reboot flag. Looking at the code I realized that the -no-reboot flag
just changes any reset request to a shutdown request.
Does anybody already patched qemu to emit some kind of reboot event to
the qmp socket?
I
It was not obvious to me why "qemu/osdep.h" must be the first #include.
This documents the rationale and the overall #include order.
Cc: Fam Zheng
Cc: Markus Armbruster
Cc: Eric Blake
Signed-off-by: Stefan Hajnoczi
---
HACKING | 18 ++
1 file changed, 18 insertions(+)
diff --
On 11/16/2016 08:39 AM, Stefan Hajnoczi wrote:
> It was not obvious to me why "qemu/osdep.h" must be the first #include.
> This documents the rationale and the overall #include order.
>
> Cc: Fam Zheng
> Cc: Markus Armbruster
> Cc: Eric Blake
> Signed-off-by: Stefan Hajnoczi
> ---
> HACKING |
On 11/16/2016 7:59 AM, Dong Jia Shi wrote:
> * Kirti Wankhede [2016-11-15 20:59:45 +0530]:
>
> Hi Kirti,
>
>> vfio_mdev driver registers with mdev core driver.
>> mdev core driver creates mediated device and calls probe routine of
>> vfio_mdev driver for each device.
>> Probe routine of vfio_m
On 11/16/2016 11:36 AM, Dong Jia Shi wrote:
> * Kirti Wankhede [2016-11-15 20:59:52 +0530]:
>
> Hi Kirti,
>
> [...]
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>
>> @@ -331,13 +338,16 @@ static long vfio_pin_pages_remote(unsigned long vaddr,
>> long npage
On 11/16/2016 8:33 AM, Dong Jia Shi wrote:
> * Kirti Wankhede [2016-11-15 20:59:48 +0530]:
>
> Hi Kirti,
>
>> Added APIs for pining and unpining set of pages. These call back into
>> backend iommu module to actually pin and unpin pages.
>> Added two new callback functions to struct vfio_iommu_
On 11/16/2016 12:07 PM, Dong Jia Shi wrote:
> * Kirti Wankhede [2016-11-15 20:59:55 +0530]:
>
> Hi Kirti,
>
> [...]
>
>> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
>> index ffc36758cb84..4fc63db38829 100644
>> --- a/drivers/vfio/mdev/vfio_mdev.c
>> +++ b/driver
On 11/16/2016 10:06 AM, Alex Williamson wrote:
> On Wed, 16 Nov 2016 09:46:20 +0530
> Kirti Wankhede wrote:
>
>> On 11/16/2016 9:28 AM, Alex Williamson wrote:
>>> On Wed, 16 Nov 2016 09:13:37 +0530
>>> Kirti Wankhede wrote:
>>>
On 11/16/2016 8:55 AM, Alex Williamson wrote:
> On T
On Wed, 16 Nov 2016 15:54:56 +0200
"Michael S. Tsirkin" wrote:
> On Thu, Nov 10, 2016 at 12:44:47PM -0700, Alex Williamson wrote:
> > On Thu, 10 Nov 2016 21:20:36 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Nov 10, 2016 at 09:04:13AM -0700, Alex Williamson wrote:
> > > > On Thu,
Unconditionally enable locking checks in debug builds so that we get
wider testing. Using tcg_debug_assert() allows us to remove
DEBUG_LOCKING define.
Signed-off-by: Pranith Kumar
---
translate-all.c | 50 +-
1 file changed, 17 insertions(+), 33 de
Just crossed my mind that we're missing isb's.
On Tue, Nov 08, 2016 at 12:17:14PM -0600, Wei Huang wrote:
> From: Christopher Covington
>
> Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
> even for the smallest delta of two subsequent reads.
>
> Signed-off-by: Christopher C
On Tue, Nov 08, 2016 at 12:17:15PM -0600, Wei Huang wrote:
> From: Christopher Covington
>
> Calculate the numbers of cycles per instruction (CPI) implied by ARM
> PMU cycle counter values. The code includes a strict checking facility
> intended for the -icount option in TCG mode in the configura
Pranith Kumar writes:
> Unconditionally enable locking checks in debug builds so that we get
> wider testing. Using tcg_debug_assert() allows us to remove
> DEBUG_LOCKING define.
Interesting. The other option would be to add a debug build to
.travis.yml that define this (and others) with -DFOO_
On Thu 10 Nov 2016 06:19:04 PM CET, Kevin Wolf wrote:
> +typedef struct QuorumCo {
> +QuorumAIOCB *acb;
> int i;
Maybe 'i' could rename to something a bit more descriptive ('idx', I
don't know).
> +} QuorumCo;
> +
> +static void read_quorum_children_entry(void *opaque)
> +{
> +Quoru
On 11/16/2016 09:05 AM, Eduardo Habkost wrote:
On Wed, Nov 16, 2016 at 02:15:02PM +0100, Jiri Denemark wrote:
On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote:
CCing qemu-devel.
CCing Markus, in case he has any insights about the interface
introspection.
On Tue, Nov 15, 2016 at 0
so it won't impose an additional limits on max_cpus limits
supported by different targets.
It removes global MAX_CPUMASK_BITS constant and need to
bump it up whenever max_cpus is being increased for
a target above MAX_CPUMASK_BITS value.
Use runtime max_cpus value instead to allocate sufficiently
This series removes global MAX_CPUMASK_BITS constant
so that it won't inderectly influence maximum CPUs count
supported by different targets.
It replaces statically allocated bitmasks with dynamically
allocated ones using '-smp maxcpus' value for setting
bitmasks size.
That would allocate just eno
On 11/16/2016 08:01 AM, Andrew Jones wrote:
> On Tue, Nov 15, 2016 at 04:50:53PM -0600, Wei Huang wrote:
>>
>>
>> On 11/14/2016 09:12 AM, Christopher Covington wrote:
>>> Hi Drew, Wei,
>>>
>>> On 11/14/2016 05:05 AM, Andrew Jones wrote:
On Fri, Nov 11, 2016 at 01:55:49PM -0600, Wei Huang wrote
it will be used for freeing bitmaps allocated with bitmap_[try]_new()
Signed-off-by: Igor Mammedov
---
include/qemu/bitmap.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/qemu/bitmap.h b/include/qemu/bitmap.h
index 63ea2d0..0289836 100644
--- a/include/qemu/bitmap.h
+++ b/incl
On Wed, Nov 16, 2016 at 11:08:42AM -0500, Christopher Covington wrote:
> On 11/16/2016 08:01 AM, Andrew Jones wrote:
> > On Tue, Nov 15, 2016 at 04:50:53PM -0600, Wei Huang wrote:
> >>
> >>
> >> On 11/14/2016 09:12 AM, Christopher Covington wrote:
> >>> Hi Drew, Wei,
> >>>
> >>> On 11/14/2016 05:05
On 11/16/2016 09:01 AM, Dirk Braunschweiger wrote:
Hey Guys,
I want to get a qmp event when the qemu does a shutdown due to the
-no-reboot flag. Looking at the code I realized that the -no-reboot flag
just changes any reset request to a shutdown request.
Does anybody already patched qemu to em
On 11/16/2016 11:25 AM, Andrew Jones wrote:
> On Wed, Nov 16, 2016 at 11:08:42AM -0500, Christopher Covington wrote:
>> On 11/16/2016 08:01 AM, Andrew Jones wrote:
>>> On Tue, Nov 15, 2016 at 04:50:53PM -0600, Wei Huang wrote:
On 11/14/2016 09:12 AM, Christopher Covington wrote:
On Sat, Nov 05, 2016 at 06:46:34PM +0200, Marcel Apfelbaum wrote:
> On 11/03/2016 09:40 PM, Michael S. Tsirkin wrote:
> > On Thu, Nov 03, 2016 at 01:05:44PM +0200, Marcel Apfelbaum wrote:
> > > On 11/03/2016 06:18 AM, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 02, 2016 at 05:16:42PM +0200, Marce
On 11/16/2016 06:44 PM, Andrew Jones wrote:
On Sat, Nov 05, 2016 at 06:46:34PM +0200, Marcel Apfelbaum wrote:
On 11/03/2016 09:40 PM, Michael S. Tsirkin wrote:
On Thu, Nov 03, 2016 at 01:05:44PM +0200, Marcel Apfelbaum wrote:
On 11/03/2016 06:18 AM, Michael S. Tsirkin wrote:
On Wed, Nov 02, 2
On Wed, Nov 16, 2016 at 05:02:55PM +0100, Igor Mammedov wrote:
> it will be used for freeing bitmaps allocated with bitmap_[try]_new()
>
> Signed-off-by: Igor Mammedov
We need to change all code using g_free() for bitmaps to use
bitmap_free(), as people in the future might assume that changing
b
On Wed, Nov 16, 2016 at 3:27 AM, Stefan Hajnoczi wrote:
> On Wed, Nov 16, 2016 at 9:49 AM, Fam Zheng wrote:
>> On Wed, 11/16 10:04, Markus Armbruster wrote:
>>> ashish mittal writes:
>>>
>>> > Thanks for concluding on this.
>>> >
>>> > I will rearrange the qnio_api.h header accordingly as follow
On Wed, Nov 16, 2016 at 05:02:56PM +0100, Igor Mammedov wrote:
> so it won't impose an additional limits on max_cpus limits
> supported by different targets.
>
> It removes global MAX_CPUMASK_BITS constant and need to
> bump it up whenever max_cpus is being increased for
> a target above MAX_CPUMA
On 11/16/16 13:47, Paolo Bonzini wrote:
>
>> If the consensus is that the patch is a QEMU bugfix (as opposed to a
>> feature) and that it is eligible for the currently supported upstream
>> stable branches, that's the best, no doubt.
>
> The currently supported upstream stable branches is just 2.
v2:
* Uninitialized node->deleted gone [Fam]
* Removed 1024 polling loop iteration qemu_clock_get_ns() optimization which
created a weird step pattern [Fam]
* Unified with AioHandler, dropped AioPollHandler struct [Paolo]
(actually I think Paolo had more in mind but this is the first step)
The new AioPollFn io_poll() argument to aio_set_fd_handler() and
aio_set_event_handler() is used in the next patch.
Keep this code change separate due to the number of files it touches.
Signed-off-by: Stefan Hajnoczi
---
aio-posix.c | 8 +---
async.c |
The Linux AIO userspace ABI includes a ring that is shared with the
kernel. This allows userspace programs to process completions without
system calls.
Add an AioContext poll handler to check for completions in the ring.
Signed-off-by: Stefan Hajnoczi
---
block/linux-aio.c | 17 +++
The AioContext event loop uses ppoll(2) or epoll_wait(2) to monitor file
descriptors or until a timer expires. In cases like virtqueues, Linux
AIO, and ThreadPool it is technically possible to wait for events via
polling (i.e. continuously checking for events without blocking).
Polling can be fas
On 11/16/16 14:18, Michael S. Tsirkin wrote:
> On Wed, Nov 16, 2016 at 07:47:42AM -0500, Paolo Bonzini wrote:
>>
>>> If the consensus is that the patch is a QEMU bugfix (as opposed to a
>>> feature) and that it is eligible for the currently supported upstream
>>> stable branches, that's the best, n
Add an AioContext poll handler to detect new virtqueue buffers without
waiting for a guest->host notification.
Signed-off-by: Stefan Hajnoczi
---
hw/virtio/virtio.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index
On 11/16/16 15:05, Paolo Bonzini wrote:
>
>
> On 16/11/2016 14:18, Michael S. Tsirkin wrote:
>>> - we could have another magic 0xB2 value, which is implemented directly
>>> in QEMU and sets 0xB3 to a magic value. Then OVMF can invoke it
>>> after SMBASE relocation and SMM IPL (so as not to crash
This will be needed once dataplane will be able to set it outside
the big QEMU lock.
Signed-off-by: Paolo Bonzini
---
v1->v2: squash syntax error fix from patch 3 [Christian]
hw/virtio/virtio-mmio.c | 6 +++---
hw/virtio/virtio-pci.c | 9 +++--
hw/virtio/virtio.c | 18 ++
Following the recent refactoring of virtio notifiers [1], more specifically
the patch ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to
start/stop ioeventfd") that uses virtio_bus_set_host_notifier [2]
by default, core virtio code requires 'ioeventfd_started' to be set
to true/false when the
> I guess that's what the next paragraph is about:
>
> > - we could have another magic 0xB2 value, which is implemented directly
> > in QEMU and sets 0xB3 to a magic value. Then OVMF can invoke it
> > after SMBASE relocation and SMM IPL (so as not to crash on old QEMUs)
> > to detect the new feat
On 11/11/2016 10:23 AM, Gonglei wrote:
> The virtio crypto device is a virtual crypto device (ie. hardware
> crypto accelerator card). Currently, the virtio crypto device provides
> the following crypto services: CIPHER, MAC, HASH, and AEAD.
>
> In this patch, CIPHER, MAC, HASH, AEAD services ar
On 16/11/2016 18:47, Stefan Hajnoczi wrote:
> The AioContext event loop uses ppoll(2) or epoll_wait(2) to monitor file
> descriptors or until a timer expires. In cases like virtqueues, Linux
> AIO, and ThreadPool it is technically possible to wait for events via
> polling (i.e. continuously chec
Dataplane has been omitting forever the step of setting ISR when
an interrupt is raised. This caused little breakage, because the
specification actually says that ISR may not be updated in MSI mode.
Some versions of the Windows drivers however didn't clear MSI mode
correctly, and proceeded using
Patch 1 fixes vhost, patches 2-3 fix Windows hibernation.
Paolo
v1->v2: more comments [Cornelia]
squash syntax error fix from patch 3 into patch 2 [Christian]
Paolo Bonzini (3):
virtio: introduce grab/release_ioeventfd to fix vhost
virtio: access ISR atomically
virtio: set ISR on d
The new typename attribute on query-cpu-definitions will be used
to help management software use device-list-properties to check
which properties can be set using -cpu or -global for the CPU
model.
Signed-off-by: Eduardo Habkost
---
qapi-schema.json| 4 +++-
target-arm/helper.c
On 16/11/2016 18:47, Stefan Hajnoczi wrote:
> +if (max_ns && run_poll_handlers(ctx, max_ns)) {
> +atomic_sub(&ctx->notify_me, 2);
> +blocking = false; /* poll again, don't block */
You don't need to poll---you only need to run bottom halves and timers.
Paolo
> +
Hi,
Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Type: series
Subject: [Qemu-devel] [PATCH v2 0/4] aio: experimental virtio-blk polling mode
Message-id: 1479318422-10979-1-git
On 11/16/2016 12:21 PM, Eduardo Habkost wrote:
> The new typename attribute on query-cpu-definitions will be used
> to help management software use device-list-properties to check
> which properties can be set using -cpu or -global for the CPU
> model.
>
> Signed-off-by: Eduardo Habkost
> ---
>
On 11/16/16 19:04, Paolo Bonzini wrote:
>> I guess that's what the next paragraph is about:
>>
>>> - we could have another magic 0xB2 value, which is implemented directly
>>> in QEMU and sets 0xB3 to a magic value. Then OVMF can invoke it
>>> after SMBASE relocation and SMM IPL (so as not to crash
Hi,
Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Type: series
Subject: [Qemu-devel] [PATCH v2 for-2.8 0/3] virtio fixes
Message-id: 20161116180551.9611-1-pbonz...@redhat.com
While working on the qdev class properteis series, I've noticed
that the release function for class properties is never called,
and have unclear semantics (should it be called when the object
is destroyed, or when the class is destroyed?). Patch 1/1 removes
the unused feature.
Patch 2/2 changes th
The release functions are never called for class properties, and
their semantics aren't even defined clearly (should the release
function be called when an instance is destroyed, or when a class
is destroyed?). Remove the unused functionality.
Signed-off-by: Eduardo Habkost
---
backends/hostmem.
Change the function signature to make implementations simpler and
safer. No void pointers and Object->DeviceState casts inside each
release function.
Signed-off-by: Eduardo Habkost
---
hw/core/qdev-properties-system.c | 8 ++--
hw/core/qdev-properties.c| 10 +-
hw/core/qdev.
On Thu, Nov 10, 2016 at 9:20 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 10, 2016 at 09:04:13AM -0700, Alex Williamson wrote:
> > On Thu, 10 Nov 2016 17:54:35 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Nov 10, 2016 at 08:30:21AM -0700, Alex Williamson wrote:
> > > > On Thu, 10 Nov 2
1 - 100 of 268 matches
Mail list logo
