On 06/13/2018 02:55 AM, Alex Bennée wrote:
> Otherwise changes to reginfo don't cause the whole thing to be
> re-built causing much confusion when bisecting.
>
> Signed-off-by: Alex Bennée
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
On 06/13/2018 02:55 AM, Alex Bennée wrote:
> This is a simple aide-memoir as it can be tricky to determine this
> with a simple statically compiled binary.
>
> Signed-off-by: Alex Bennée
> ---
> risu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Eh, sure. Or we could simply
On 06/13/2018 02:55 AM, Alex Bennée wrote:
> This can cause much confusion when you have been building in your
> source tree. I've added a distclean so we don't unexpectedly drop the
> config for normal make clean invocations.
>
> Signed-off-by: Alex Bennée
> ---
> Makefile| 3 +++
>
On 06/13/2018 02:55 AM, Alex Bennée wrote:
> We won't actually want power, we want ppc64el for the 64 bit version.
> Also we will soon have m68k so include that as well.
>
> Signed-off-by: Alex Bennée
> ---
> build-all-archs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by:
On 06/13/2018 02:55 AM, Alex Bennée wrote:
> The compiler complains about implicit declarations otherwise.
>
> Signed-off-by: Alex Bennée
> ---
> comms.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Richard Henderson
r~
On 06/13/2018 02:55 AM, Alex Bennée wrote:
> Building with the Bionic Beaver cross compilers fails which probably
> means we were getting this as a side effect before. Include the
> correct header to get at these bits.
>
> Signed-off-by: Alex Bennée
> ---
> risu_reginfo_aarch64.c | 1 +
> 1
On 06/14/2018 06:41 AM, David Gibson wrote:
> PowerPCCPU contains an (Object *)intc used to point to the cpu's interrupt
> controller. Or more precisely to the "presentation" component of the
> interrupt controller relevant to this cpu.
>
> Really, this field is machine specific. The machines
Qspi dma has a burst length of 64 bytes, So limit transaction length to
64 max.
Signed-off-by: Sai Pavan Boddu
---
hw/ssi/xilinx_spips.c | 18 +++---
include/hw/ssi/xilinx_spips.h | 3 ++-
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/hw/ssi/xilinx_spips.c
On 06/14/2018 06:41 AM, David Gibson wrote:
> In pnv_core_realize() we call two functions with an Error * parameter in
> succession, which will go badly if they both cause errors. In fact, a
> failure in either of them indicates a qemu internal error, so we can just
> use _abort in both cases.
Qspi dma has a burst length of 64 bytes, So limit transaction length to
64 max.
Signed-off-by: Sai Pavan Boddu
---
hw/ssi/xilinx_spips.c | 18 +++---
include/hw/ssi/xilinx_spips.h | 3 ++-
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/hw/ssi/xilinx_spips.c
CPUPPCState currently contains a number of fields containing the state of
the VPA. The VPA is a PAPR specific concept covering several guest/host
shared memory areas used to communicate some information with the
hypervisor.
As a PAPR concept this is really machine specific information, although
It's moderately common for a machine type to need to keep track of
information that is specific to the platform it implements, but
per-cpu.
While it could keep such information inside the MachineState, this
makes lookup from the CPUState awkward. So, this series adds a
standard way to stash
pnv_cpu_init() is only called from the the pnv cpu core realize path, and
really only can be called from there. So fold it into its caller, which
we also rename for brevity.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
---
hw/ppc/pnv_core.c | 56
Currently we don't have any unrealize path for pnv cpu cores. We get away
with this because we don't yet support cpu hotplug for pnv.
However, we're going to want it eventually, and in the meantime, it makes
it non-obvious why there are a bunch of allocations on the realize() path
that don't
In pnv_core_realize() we call two functions with an Error * parameter in
succession, which will go badly if they both cause errors. In fact, a
failure in either of them indicates a qemu internal error, so we can just
use _abort in both cases.
Signed-off-by: David Gibson
---
hw/ppc/pnv_core.c |
spapr_cpu_init() and spapr_cpu_destroy() are only called from the spapr
cpu core realize/unrealize paths, and really can only be called from there.
Those are all short functions, so fold the pairs together for simplicity.
While we're there rename some functions and change some parameter types
for
PowerPCCPU contains an (Object *)intc used to point to the cpu's interrupt
controller. Or more precisely to the "presentation" component of the
interrupt controller relevant to this cpu.
Really, this field is machine specific. The machines which use it can
point it to different types of object
Currently, we allocate space for all the cpu objects within a single core
in one big block. This was copied from an older version of the spapr code
and requires some ugly pointer manipulation to extract the individual
objects.
This design was due to a misunderstanding of qemu lifetime
On Thu, Jun 14, 2018 at 11:04:39AM +1000, David Gibson wrote:
> It's moderately common for a machine type to need to keep track of
> information that is specific to the platform it implements, but
> per-cpu.
>
> While it could keep such information inside the MachineState, this
> makes lookup
On Wed, Jun 13, 2018 at 09:24:12AM +0200, Cédric Le Goater wrote:
> On 06/13/2018 06:22 AM, David Gibson wrote:
> > On Tue, Jun 05, 2018 at 08:41:13AM +0200, Cédric Le Goater wrote:
> >> On 06/05/2018 05:34 AM, David Gibson wrote:
> >>> On Mon, May 28, 2018 at 09:06:12AM +0200, Cédric Le Goater
On 06/14/2018 12:17 AM, Dr. David Alan Gilbert wrote:
* guangrong.x...@gmail.com (guangrong.x...@gmail.com) wrote:
From: Xiao Guangrong
It is used to slightly clean the code up, no logic is changed
Actually, there is a slight change; iterations_prev is always updated
when previously it
On 06/13/2018 11:51 PM, Dr. David Alan Gilbert wrote:
* guangrong.x...@gmail.com (guangrong.x...@gmail.com) wrote:
From: Xiao Guangrong
The compressed page is not normal page
Is this the right reason?
I think the 'normal' page shouldn't include the compressed
page and XBZRLE-ed page
Michael S. Tsirkin 于2018年6月13日周三 下午10:46写道：
>
> On Wed, Jun 13, 2018 at 04:23:40PM +0800, Zihan Yang wrote:
> > Michael S. Tsirkin 于2018年6月12日周二 下午9:43写道：
> > >
> > > On Tue, Jun 12, 2018 at 05:13:22PM +0800, Zihan Yang wrote:
> > > > The inner host bridge created by pxb-pcie is
On 06/13/2018 11:43 PM, Dr. David Alan Gilbert wrote:
* Peter Xu (pet...@redhat.com) wrote:
On Tue, Jun 12, 2018 at 10:42:25AM +0800, Xiao Guangrong wrote:
On 06/11/2018 03:39 PM, Peter Xu wrote:
On Mon, Jun 04, 2018 at 05:55:09PM +0800, guangrong.x...@gmail.com wrote:
From: Xiao
On Wed, Jun 13, 2018 at 03:30:05PM +0100, Stefan Hajnoczi wrote:
> On Tue, Jun 12, 2018 at 01:47:00PM +0800, Peter Xu wrote:
> > On Mon, Jun 11, 2018 at 05:45:49PM +0100, Stefan Hajnoczi wrote:
> > > On Fri, Jun 08, 2018 at 10:18:25AM +0200, Markus Armbruster wrote:
> > > > Stefan Hajnoczi
On Mon, May 07, 2018 at 03:48:54PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-04-27 at 22:17 +1000, David Gibson wrote:
> > On Fri, Apr 27, 2018 at 10:31:10AM +0200, Andrea Bolognani wrote:
> > > On Fri, 2018-04-27 at 12:14 +1000, David Gibson wrote:
> > > > Right.. note that with the draft
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> When writing registers that have read only bits we have to avoid
> changing these bits as they may have non zero values. Make sure we use
> the correct masks to mask out read only and reserved bits when
> changing registers.
>
>
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> PPC440 has two opcodes for icbt, add the missing one.
A document reference to confim this would be nice.
> Signed-off-by: BALATON Zoltan
> ---
> target/ppc/translate.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> The Sam460ex has an M41T80 serial RTC chip on I2C bus 0 at address 0x68.
>
> Signed-off-by: BALATON Zoltan
Reviewed-by: David Gibson
> ---
> hw/ppc/sam460ex.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> From: Sebastian Bauer
>
> Signed-off-by: Sebastian Bauer
> Signed-off-by: BALATON Zoltan
Commit message. Why is this necessary?
> ---
> hw/display/sm501.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
> of day is implemented. Setting time and RTC alarm are not supported.
>
> Signed-off-by: BALATON Zoltan
Acked-by: David Gibson
> ---
>
> Notes:
> v3:
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> Signed-off-by: BALATON Zoltan
Again needs a commit message expanding on what this is and why it's
useful.
[snip]
> static const VMStateDescription vmstate_sm501_sysbus = {
> .name = TYPE_SYSBUS_SM501,
> -.version_id =
On Wed, Jun 13, 2018 at 10:28:09AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 12:02:59PM +0800, Peter Xu wrote:
> > On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote:
> > > On 12 June 2018 at 07:24, Peter Xu wrote:
> > > > For example, I wanted to compile QEMU once and
On Wed, Jun 13, 2018 at 10:24 PM, Dr. David Alan Gilbert
wrote:
> * Lidong Chen (jemmy858...@gmail.com) wrote:
>> If the peer qemu is crashed, the qemu_rdma_wait_comp_channel function
>> maybe loop forever. so we should also poll the cm event fd, and when
>> receive RDMA_CM_EVENT_DISCONNECTED and
On Wed, Jun 13, 2018 at 09:18:22PM -0400, Babu Moger wrote:
> Enabling TOPOEXT feature might cause compatibility issues if
> older kernels does not set this feature. Lets set this feature
> unconditionally.
>
> Signed-off-by: Babu Moger
> ---
> target/i386/kvm.c | 6 ++
> 1 file changed, 6
On Wed, Jun 13, 2018 at 11:26:41AM +0100, Dr. David Alan Gilbert (git) wrote:
[...]
> @@ -2932,10 +2943,24 @@ static void *migration_thread(void *opaque)
>
> migration_update_counters(s, current_time);
>
> +urgent = false;
> if (qemu_file_rate_limit(s->to_dst_file))
On Wed, Jun 13, 2018 at 11:26:40AM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Limit the background transfer bandwidth during the postcopy
> phase to the value set on this new parameter. The default, 0,
> corresponds to the existing behaviour which is
After a discussion with Richard yesterday on IRC, I ran some numbers on the
performance impact of the guard pages added at the end of TCG regions.
These 4kB guard pages prevent the use of transparent huge pages for the
last 2MB of a region.
The benchmark I used is the bootup+shutdown of debian on
On Wed, Jun 13, 2018 at 04:20:34PM +0200, Auger Eric wrote:
> Hi Paolo,
>
> On 06/13/2018 03:53 PM, Paolo Bonzini wrote:
> > On 13/06/2018 15:44, Auger Eric wrote:
> >>> Queuing this patch. I'm not sure how I missed this, I have actually
> >>> tested it with SMMU.
> >> no problem. Strange also I
On Wed, Jun 13, 2018 at 04:13:57PM +0200, BALATON Zoltan wrote:
> On Wed, 13 Jun 2018, David Gibson wrote:
> > On Wed, Jun 13, 2018 at 10:50:59AM +0200, BALATON Zoltan wrote:
> > > On Wed, 13 Jun 2018, David Gibson wrote:
> > > > On Wed, Jun 06, 2018 at 07:35:28PM +0200, BALATON Zoltan wrote:
> >
On Wed, Jun 13, 2018 at 04:26:39PM +0200, Greg Kurz wrote:
> On Wed, 13 Jun 2018 22:05:02 +1000
> David Gibson wrote:
>
> > On Wed, Jun 13, 2018 at 10:19:15AM +0200, Greg Kurz wrote:
> > > On Wed, 13 Jun 2018 10:45:06 +1000
> > > David Gibson wrote:
> > >
> > > > On Tue, Jun 12, 2018 at
Remove generic non-intel check while validating hyperthreading support.
Certain AMD CPUs can support hyperthreading now.
CPU family with TOPOEXT feature can support hyperthreading now.
Signed-off-by: Babu Moger
Tested-by: Geoffrey McRae
Reviewed-by: Eduardo Habkost
---
target/i386/cpu.c | 17
Add new function topology_supports_topoext to verify
if we can support topoext feature. Will be used to enable/disable
topoext feature.
Signed-off-by: Babu Moger
---
accel/tcg/user-exec-stub.c | 5 +
cpus.c | 13 +
include/qom/cpu.h | 9 +
Disable the TOPOEXT feature if it cannot be supported.
We cannot support this feature with more than 2 nr_threads
or more than 32 cores in a socket.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git
Enabling TOPOEXT feature might cause compatibility issues if
older kernels does not set this feature. Lets set this feature
unconditionally.
Signed-off-by: Babu Moger
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index
This series enables the TOPOEXT feature for AMD CPUs. This is required to
support hyperthreading on kvm guests.
This addresses the issues reported in these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1481253
https://bugs.launchpad.net/qemu/+bug/1703506
v14:
Patches are based off of
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> Signed-off-by: BALATON Zoltan
But.. they are implemented. Albeit as an entirely software controlled
register.
I'm guessing that's not what they're supposed to do, which is why
you're removing them, but that needs to be explained
Enable TOPOEXT feature on EPYC CPU. This is required to support
hyperthreading on VM guests. Also extend xlevel to 0x801E.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
Disable TOPOEXT feature for older machines.
Signed-off-by: Babu Moger
---
include/hw/i386/pc.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 04d1f8c..ecccf6b 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -303,6
On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> Signed-off-by: BALATON Zoltan
Patch looks good, but it needs a commit message. What is the
directcntl register? Now does the bitbang interface play into that?
(Note that I know the answer to those questions right now, but it
CPUPPCState currently contains a number of fields containing the state of
the VPA. The VPA is a PAPR specific concept covering several guest/host
shared memory areas used to communicate some information with the
hypervisor.
As a PAPR concept this is really machine specific information, although
pnv_cpu_init() is only called from the the pnv cpu core realize path, and
really only can be called from there. So fold it into its caller, which
we also rename for brevity.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
---
hw/ppc/pnv_core.c | 56
PowerPCCPU contains an (Object *)intc used to point to the cpu's interrupt
controller. Or more precisely to the "presentation" component of the
interrupt controller relevant to this cpu.
Really, this field is machine specific. The machines which use it can
point it to different types of object
In pnv_core_realize() we call two functions with an Error * parameter in
succession, which will go badly if they both cause errors. In fact, a
failure in either of them indicates a qemu internal error, so we can just
use _abort in both cases.
Signed-off-by: David Gibson
---
hw/ppc/pnv_core.c |
spapr_cpu_init() and spapr_cpu_destroy() are only called from the spapr
cpu core realize/unrealize paths, and really can only be called from there.
Those are all short functions, so fold the pairs together for simplicity.
While we're there rename some functions and change some parameter types
for
Currently we don't have any unrealize path for pnv cpu cores. We get away
with this because we don't yet support cpu hotplug for pnv.
However, we're going to want it eventually, and in the meantime, it makes
it non-obvious why there are a bunch of allocations on the realize() path
that don't
It's moderately common for a machine type to need to keep track of
information that is specific to the platform it implements, but
per-cpu.
While it could keep such information inside the MachineState, this
makes lookup from the CPUState awkward. So, this series adds a
standard way to stash
Currently, we allocate space for all the cpu objects within a single core
in one big block. This was copied from an older version of the spapr code
and requires some ugly pointer manipulation to extract the individual
objects.
This design was due to a misunderstanding of qemu lifetime
On Tue, Jun 12, 2018 at 5:08 PM, Samudrala, Sridhar
wrote:
> On 6/12/2018 4:34 AM, Michael S. Tsirkin wrote:
>>
>> On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote:
>>>
>>> On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote:
On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason
On Wed, Jun 13, 2018 at 07:53:29PM +1000, David Gibson wrote:
> On Wed, Jun 13, 2018 at 11:42:07AM +0200, Greg Kurz wrote:
> > On Wed, 13 Jun 2018 11:14:57 +0200
> > Cédric Le Goater wrote:
> >
> > > >> index 13ad7d9e04..efb68226bb 100644
> > > >> --- a/hw/ppc/pnv_core.c
> > > >> +++
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Wednesday, June 13, 2018 1:49 PM
> To: Moger, Babu
> Cc: m...@redhat.com; marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> r...@twiddle.net; mtosa...@redhat.com; qemu-devel@nongnu.org;
>
On Tue, Jun 12, 2018 at 4:47 AM, Michael S. Tsirkin wrote:
> On Tue, Jun 05, 2018 at 03:09:26PM -0700, Siwei Liu wrote:
>> The thing is cloud service provider might prefer sticking to the same
>> level of service agreement (SLA) of keeping VF over migration,
>
> That requirement is trivially
Signed-off-by: BALATON Zoltan
---
default-configs/ppc-softmmu.mak| 1 +
default-configs/ppcemb-softmmu.mak | 1 +
hw/i2c/ppc4xx_i2c.c| 13 -
include/hw/i2c/ppc4xx_i2c.h| 4
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git
Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
of day is implemented. Setting time and RTC alarm are not supported.
Signed-off-by: BALATON Zoltan
---
Notes:
v3: Fixed \n-s in log messages
MAINTAINERS | 1 +
default-configs/ppc-softmmu.mak |
Signed-off-by: BALATON Zoltan
---
default-configs/ppc-softmmu.mak| 1 +
default-configs/ppcemb-softmmu.mak | 1 +
default-configs/sh4-softmmu.mak| 1 +
default-configs/sh4eb-softmmu.mak | 1 +
hw/display/sm501.c | 136 +++--
5
This is v3 of sam460ex improvements addressing review comments and
adding two additional patches that allow AmigaOS to progress further
(does not boot fully yet).
BALATON Zoltan (8):
ppc4xx_i2c: Remove unimplemented sdata and intr registers
ppc4xx_i2c: Implement directcntl register
Rewrite to make it closer to how real device works so that guest OS
drivers can access I2C devices. Previously this was only a hack to
allow U-Boot to get past accessing SPD EEPROMs but to support other
I2C devices and allow guests to access them we need to model real
device more properly.
From: Sebastian Bauer
Signed-off-by: Sebastian Bauer
Signed-off-by: BALATON Zoltan
---
hw/display/sm501.c | 8
1 file changed, 8 insertions(+)
diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index 0625cf5..a2ee6e3 100644
--- a/hw/display/sm501.c
+++ b/hw/display/sm501.c
@@
Signed-off-by: BALATON Zoltan
---
hw/i2c/ppc4xx_i2c.c | 16 +---
include/hw/i2c/ppc4xx_i2c.h | 4 +---
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/hw/i2c/ppc4xx_i2c.c b/hw/i2c/ppc4xx_i2c.c
index d1936db..4e0aaae 100644
--- a/hw/i2c/ppc4xx_i2c.c
+++
PPC440 has two opcodes for icbt, add the missing one.
Signed-off-by: BALATON Zoltan
---
target/ppc/translate.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 5fe1ba6..3a215a1 100644
--- a/target/ppc/translate.c
+++
When writing registers that have read only bits we have to avoid
changing these bits as they may have non zero values. Make sure we use
the correct masks to mask out read only and reserved bits when
changing registers.
Also remove extra spaces from dram_control and arbitration_control
The Sam460ex has an M41T80 serial RTC chip on I2C bus 0 at address 0x68.
Signed-off-by: BALATON Zoltan
---
hw/ppc/sam460ex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index bdc53d2..dc730cc 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@
In appears the input keymap for osx was forgotten in the commit that
converted the gtk frontend to keycodemapdb. Add it.
Fixes: 2ec78706 ("ui: convert GTK and SDL1 frontends to keycodemapdb")
CC: Daniel P. Berrange
Signed-off-by: Keno Fischer
---
Makefile | 1 +
include/ui/input.h |
On Wed, Jun 13, 2018 at 07:34:53PM -0300, Marcelo Tosatti wrote:
> On Tue, Jun 12, 2018 at 09:47:11PM +0300, Michael S. Tsirkin wrote:
> > This adds ability to expose host CPU power management capabilities to
> > guests. For intel guests, this is sufficient for guest to enable
> > low power CPU
On Wed, Jun 13, 2018 at 01:50:47PM -0600, Alex Williamson wrote:
> On Wed, 13 Jun 2018 10:41:49 +0200
> Gerd Hoffmann wrote:
>
> > So we have a boot display when using a vgpu as primary display.
> >
> > Use vfio-pci-ramfb instead of vfio-pci to enable it.
>
> Using a different device here
On Tue, Jun 12, 2018 at 09:47:11PM +0300, Michael S. Tsirkin wrote:
> This adds ability to expose host CPU power management capabilities to
> guests. For intel guests, this is sufficient for guest to enable
> low power CPU power management. For AMD guests it isn't sufficient,
> deeper C-states are
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180613131045.17379-1-arm...@redhat.com
Subject: [Qemu-devel] [PULL 0/3] Miscellaneous patches for 2018-06-13
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
On Wed, Jun 13, 2018 at 09:37:54PM +0200, David Hildenbrand wrote:
> >>> [ ... specific to machine_foo wiring ...]
> >>>
> >>> virtio_mem_plug() {
> >>> [... some machine specific wiring ...]
> >>>
> >>> bus_hotplug_ctrl = qdev_get_bus_hotplug_handler()
> >>>
On Wed, Jun 13, 2018 at 06:00:22PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 12, 2018 at 09:47:11PM +0300, Michael S. Tsirkin wrote:
> > With this flag, kvm allows guest to control host CPU power state. This
> > increases latency for other processes using same host CPU in an
> > unpredictable
On Fri, Jun 01, 2018 at 11:38:07AM -0400, Konrad Rzeszutek Wilk wrote:
> Hi!
>
>
> I was reading the AMD whitepaper on SSBD and noticed that they have added
> two new bits in the 8000_0008 CPUID. EBX:
> 1) Bit[26] - similar to Intel's SSB_NO not needed anymore.
> 2) Bit[24] - use SPEC_CTRL MSR
On Wed, Jun 13, 2018 at 04:03:35PM +0200, David Hildenbrand wrote:
> On 13.06.2018 14:56, Igor Mammedov wrote:
> > On Mon, 11 Jun 2018 14:16:50 +0200
> > David Hildenbrand wrote:
> >
> >> "size" should not be queried before the device was realized. Let' make
> >> that explicit.
> >>
> >>
On Tue, Jun 12, 2018 at 09:47:13PM +0300, Michael S. Tsirkin wrote:
> When guest CPU PM is enabled, and with -cpu host, expose the host CPU
> MWAIT leaf in the CPUID so guest can make good PM decisions.
>
> Note: the result is 100% CPU utilization reported by host as host
> no longer knows that
On 06/13/18 10:48, Eric Auger wrote:
> PATCH: merge of ECAM and VCPU extension
> - Laszlo reviewed the ECAM changes but I dropped his R-b
> due to the squash
Was there any particular reason why the previous patch set (with only
the ECAM enlargement) couldn't be merged first? To be honest I'm
Public bug reported:
Versions:
Arch Linux (kernel 4.16.13)
Qemu 2.12
libvirt 4.3.0
Windows 10 1803 latest updates installed under libvirt management
Spice tools 0.132
QXL DOD driver 0.18 (from redhat server)
Steps to reproduce:
1. Boot Windows (xml is attached)
2. Save VM state through libvirt
** Attachment added: "minidump of the bluescreen on resume"
https://bugs.launchpad.net/qemu/+bug/1776760/+attachment/5152236/+files/MEMORY.DMP
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Tue, Jun 12, 2018 at 09:47:11PM +0300, Michael S. Tsirkin wrote:
> With this flag, kvm allows guest to control host CPU power state. This
> increases latency for other processes using same host CPU in an
> unpredictable way, but if decreases idle entry/exit times for the
> running VCPU.
>
>
Oughtta be fixed in current master, will be fixed in 2.12.1 and 3.0.
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189
Title:
Read the crypto services and algorithm masks which provides
information about the services and algorithms supported by
virtio-crypto backend.
Signed-off-by: Farhan Ali
Acked-by: Gonglei
---
drivers/crypto/virtio/virtio_crypto_common.h | 14 ++
Hi,
Currently the Linux virtio-crypto driver registers the crypto
algorithm without verifying if the backend actually supports the
algorithm.
This kernel patch series adds support for registering algorithm
with Linux crypto layer, only if the algorithm is supported by
the backend device. This
From: Farhan Ali
Register a crypto algo with the Linux crypto layer only if
the algorithm is supported by the backend virtio-crypto
device.
Also route crypto requests to a virtio-crypto
device, only if it can support the requested service and
algorithm.
Signed-off-by: Farhan Ali
Acked-by:
On Tue, Jun 12, 2018 at 09:47:11PM +0300, Michael S. Tsirkin wrote:
> With this flag, kvm allows guest to control host CPU power state. This
> increases latency for other processes using same host CPU in an
> unpredictable way, but if decreases idle entry/exit times for the
> running VCPU.
>
>
Hi Arei
On 06/12/2018 08:57 PM, Gonglei (Arei) wrote:
-Original Message-
From: Farhan Ali [mailto:al...@linux.ibm.com]
Sent: Wednesday, June 13, 2018 3:49 AM
To: qemu-devel@nongnu.org
Cc: m...@redhat.com; Gonglei (Arei) ; longpeng
; pa...@linux.ibm.com; borntrae...@de.ibm.com;
On Tue, Jun 12, 2018 at 02:34:37PM -0300, Philippe Mathieu-Daudé wrote:
> Currently to run Avocado acceptance tests in an out-of-tree
> build directory, we need to use the full path to the test:
>
> build_dir$ avocado run
> /full/path/to/sources/qemu/tests/acceptance/boot_linux_console.py
>
>
On Tue, Jun 12, 2018 at 01:38:08PM +, Junyan He wrote:
> He have pmem_persist and pmem_memcpy_persist stub functions.
>
> If no libpmem and user really specify pmem=on, we just do nothing or just
> memcpy.
>
> Real persistent memory always require libpmem support its load/save.
>
> If
On 06/13/2018 04:31 PM, Richard Henderson wrote:
> On 06/13/2018 02:13 AM, Eric Blake wrote:
>> Or spell it UINT64_C(1) if you don't want a cast.
>
> Not unsigned is what I want most.
I used both of your suggestions, but now new format string errors
appeared due to ram_addr_t being unsigned, so
On 06/10/2018 10:14 PM, Philippe Mathieu-Daudé wrote:
> This fixes:
>
> ERROR: "foo * bar" should be "foo *bar"
> #310: FILE: hw/ppc/ppc440_uc.c:564:
> +size = 8 * MiB * sh;
> total: 1 errors, 0 warnings, 433 lines checked
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
On Wed, 13 Jun 2018 10:41:49 +0200
Gerd Hoffmann wrote:
> So we have a boot display when using a vgpu as primary display.
>
> Use vfio-pci-ramfb instead of vfio-pci to enable it.
Using a different device here seems like it almost guarantees a very
complicated path to support under libvirt.
>>> [ ... specific to machine_foo wiring ...]
>>>
>>> virtio_mem_plug() {
>>> [... some machine specific wiring ...]
>>>
>>> bus_hotplug_ctrl = qdev_get_bus_hotplug_handler()
>>> bus_hotplug_ctrl->plug(bus_hotplug_ctrl, dev)
>>>
>>> [... some more
On 06/13/2018 02:13 AM, Eric Blake wrote:
> Or spell it UINT64_C(1) if you don't want a cast.
Not unsigned is what I want most.
r~
On Wed, Jun 13, 2018 at 06:21:58PM +, Moger, Babu wrote:
>
>
> > -Original Message-
> > From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> > Sent: Wednesday, June 13, 2018 1:18 PM
> > To: Moger, Babu
> > Cc: m...@redhat.com; marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> >
1 - 100 of 435 matches
Mail list logo
