Hi,
So, the first ramfb bits should be ready for merge. This series
includes the ramfb core support bits, the ramfb standalone device
and vfio-pci-ramfb device for vgpu boot display support.
If you want play with it I recommend getting the bits from
On 05/06/2018 21:07, w...@redhat.com wrote:
> From: Wei Xu
>
> Mostly reuse memory cache with 1.0 except for the offset calculation.
>
> Signed-off-by: Wei Xu
> ---
> hw/virtio/virtio.c | 29 -
> 1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git
On 06/13/2018 12:05 AM, Thomas Huth wrote:
We've got a separate option to configure the accelerator nowadays.
Use it in the source and examples to demonstrate that this is the
preferred way of setting this option now.
Is it worth bike-shedding the preferred spelling as '--accel xyz', to
match
On 06/12/2018 04:10 PM, Richard Henderson wrote:
So there's tradeoffs either way, and you at least need to document in your
commit messages what auditing you have done that any type changes introduced by
your changes are safe.
I'm more concerned about unnecessary or unintended signed vs
>>> On 6/13/2018 at 5:46 AM, Anthony PERARD wrote:
> On Tue, Jun 12, 2018 at 05:51:02PM ‑0600, Bruce Rogers wrote:
>> Provide monitor naming of xen disks, including associating an
>> attached dev_id for a BlockBackend which has legacy_dev set.
>> Currently, only xen disks have legacy_dev set to
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 07:04:15PM +0200, Greg Kurz wrote:
> > > Bits set in the PCR disable features of the processor. TCG currently
> > > doesn't implement that, ie, we
Daniel P. Berrangé writes:
> When configure fails in CI systems we must be able to see the contents
> of the config.log file to diagnose the root cause.
>
> Signed-off-by: Daniel P. Berrangé
queued thanks.
--
Alex Bennée
The ASPEED SoCs contain a single register that returns random data when
read. This models that register so that guests can use it.
The random number data register has a corresponding control register,
however it returns data regardless of the state of the enabled bit, so
the model follows this
On Tue, Jun 12, 2018 at 05:51:02PM -0600, Bruce Rogers wrote:
> Provide monitor naming of xen disks, including associating an
> attached dev_id for a BlockBackend which has legacy_dev set.
> Currently, only xen disks have legacy_dev set to true.
>
> Signed-off-by: Bruce Rogers
> ---
>
Anton Nefedov writes:
> On 8/6/2018 8:29 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> On 06/07/2018 10:23 AM, Anton Nefedov wrote:
>> If we introduce BlockdevDriver as a discriminator as Markus suggests
>> above, we need some way to define its value.
>> I guess one
Greg Kurz writes:
> On Wed, 13 Jun 2018 07:42:57 +0200
> Markus Armbruster wrote:
>
>> Keno Fischer writes:
>>
>> > strchrnul is a GNU extension and thus unavailable on a number of targets.
>> > In the review for a commit removing strchrnul from 9p, I was asked to
>> > create a qemu_strchrnul
On 06/12/2018 10:50 PM, Emilio G. Cota wrote:
On Tue, Jun 12, 2018 at 23:15:49 -0400, Yaowei Bai wrote:
Signed-off-by: Yaowei Bai
---
docs/devel/tracing.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/devel/tracing.txt b/docs/devel/tracing.txt
index
On 13/06/2018 12:36, Mark Cave-Ayland wrote:
> Check out hw/dma/sparc32_dma.c for some ugly examples:
> espdma_memory_read()/espdma_memory_write() update the DMA address
> pointer register after each read/write, and
> ledma_memory_read()/ledma_memory_write() need to determine if the pcnet
> card
On 13.06.2018 13:01, Igor Mammedov wrote:
> On Mon, 11 Jun 2018 14:16:49 +0200
> David Hildenbrand wrote:
>
>> This might look like a step backwards, but it is not. get_memory_region()
>> should not be called on uninititalized devices. In general, only
>> properties should be access, but no
On 13.06.2018 12:56, Viktor VM Mihajlovski wrote:
> On 12.06.2018 08:17, Thomas Huth wrote:
>> On 11.06.2018 14:03, Viktor VM Mihajlovski wrote:
> [...]
>>
>> If you have the time to look at the traffic, could you please also check
>> the TFTP block size option that is negotiated at the beginning
On Mon, 11 Jun 2018 14:16:49 +0200
David Hildenbrand wrote:
> This might look like a step backwards, but it is not. get_memory_region()
> should not be called on uninititalized devices. In general, only
> properties should be access, but no "derived" satte like the memory
> region.
>
> 1. We
On 08.06.2018 17:12, Michael S. Tsirkin wrote:
> On Fri, Jun 08, 2018 at 03:07:53PM +0200, David Hildenbrand wrote:
>> On 08.06.2018 14:55, Michael S. Tsirkin wrote:
>>> On Fri, Jun 08, 2018 at 02:32:09PM +0200, David Hildenbrand wrote:
>>> if (TYPE_PC_DIMM) {
>>> pc_dimm_plug()
On 12.06.2018 08:17, Thomas Huth wrote:
> On 11.06.2018 14:03, Viktor VM Mihajlovski wrote:
[...]
>
> If you have the time to look at the traffic, could you please also check
> the TFTP block size option that is negotiated at the beginning of the
> TFTP transfer? If this other client is
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 unlimited bandwidth.
Signed-off-by: Dr. David Alan Gilbert
---
hmp.c | 7
On 13/06/18 11:06, Paolo Bonzini wrote:
On 13/06/2018 11:47, Mark Cave-Ayland wrote:
+dev = qdev_create(NULL, TYPE_ESP);
+sysbus_esp = ESP_STATE(dev);
+esp = _esp->esp;
+esp->dma_memory_read = rc4030_dma_read;
+esp->dma_memory_write = rc4030_dma_write;
+esp->dma_opaque
On 8/6/2018 8:29 AM, Markus Armbruster wrote:
Eric Blake writes:
On 06/07/2018 10:23 AM, Anton Nefedov wrote:
If we introduce BlockdevDriver as a discriminator as Markus suggests
above, we need some way to define its value.
I guess one would be to check blk->bs->drv->format_name but it
On 13.06.2018 10:18, Christian Borntraeger wrote:
> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
> the cpu type differs (3906 vs. 3907)
>
> Signed-off-by: Christian Borntraeger
> ---
> target/s390x/cpu_models.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 13.06.2018 07:24, Thomas Huth wrote:
> These files can not be executed on the host, so they should not be
> marked as executable.
Or can not be executed at all :)
Reviewed-by: David Hildenbrand
>
> Signed-off-by: Thomas Huth
> ---
> block/blkreplay.c | 0
>
On Mon, May 14, 2018 at 04:56:54PM +0100, Peter Maydell wrote:
> On 4 May 2018 at 19:37, Jonathan Marler wrote:
> > Signed-off-by: Jonathan Marler
>
> Hi; thanks for this patch.
>
> > ---
> > device_tree.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git
From: "Dr. David Alan Gilbert"
Hi,
Postcopy currently turns off bandwidth limits during the postcopy
phase to make sure the urgent postcopy requests aren't delayed.
This causes problems for larger clusters which share networking
between the migration stream and other critical services.
From: "Dr. David Alan Gilbert"
Use the 'urgent request' mechanism added in the previous patch
for entries added to the postcopy request queue for RAM. Ignore
the rate limiting while we have requests.
Signed-off-by: Dr. David Alan Gilbert
---
migration/ram.c | 9 -
1 file changed, 8
From: "Dr. David Alan Gilbert"
Rate limiting sleeps the migration thread for a while when it runs
out of bandwidth; but sometimes we want to wake up to get on with
something more urgent (like a postcopy request). Here we use
a semaphore with a timedwait instead of a simple sleep; Incrementing
On 13.06.2018 11:42, Christian Borntraeger wrote:
>
>
> On 06/13/2018 11:00 AM, David Hildenbrand wrote:
>> On 13.06.2018 10:18, Christian Borntraeger wrote:
>>> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
>>> the cpu type differs (3906 vs. 3907)
>>>
>>>
On Mon, Jun 04, 2018 at 04:22:05PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 04, 2018 at 05:07:01PM -0300, Eduardo Habkost wrote:
> > On Fri, Jun 01, 2018 at 11:38:08AM -0400, Konrad Rzeszutek Wilk wrote:
> > > AMD future CPUs expose _two_ ways to utilize the Intel equivalant
> > > of the
On Wed, 13 Jun 2018 16:57:07 +1000
David Gibson wrote:
> 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
On Wed, Jun 13, 2018 at 12:11:12PM +0200, Greg Kurz wrote:
> On Wed, 13 Jun 2018 16:57:06 +1000
> 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
On Mon, 11 Jun 2018 14:16:48 +0200
David Hildenbrand wrote:
> Unused, so let's remove it.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Igor Mammedov
> ---
> backends/hostmem.c | 3 +--
> hw/mem/nvdimm.c | 4 ++--
> hw/mem/pc-dimm.c | 4 ++--
> hw/misc/ivshmem.c
On Wed, 13 Jun 2018 16:57:06 +1000
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.
On Mon, 11 Jun 2018 14:16:47 +0200
David Hildenbrand wrote:
> We can perform these checks before the device is actually realized.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Igor Mammedov
> ---
> hw/i386/pc.c | 44 ++--
> 1 file changed, 26
On 13/06/2018 11:47, Mark Cave-Ayland wrote:
> +dev = qdev_create(NULL, TYPE_ESP);
> +sysbus_esp = ESP_STATE(dev);
> +esp = _esp->esp;
> +esp->dma_memory_read = rc4030_dma_read;
> +esp->dma_memory_write = rc4030_dma_write;
> +esp->dma_opaque = dmas[0];
Poking at the
On Wed, Jun 13, 2018 at 10:56:59AM +0200, BALATON Zoltan wrote:
> On Wed, 13 Jun 2018, David Gibson wrote:
> > On Fri, Jun 08, 2018 at 11:20:50AM +0200, BALATON Zoltan wrote:
> > > On Fri, 8 Jun 2018, David Gibson wrote:
> > > > On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> > >
On Wed, Jun 13, 2018 at 10:54:22AM +0200, BALATON Zoltan wrote:
> On Wed, 13 Jun 2018, David Gibson wrote:
> > On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> > > Signed-off-by: BALATON Zoltan
> > > ---
> > > default-configs/ppc-softmmu.mak| 1 +
> > >
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, 6 Jun 2018, Philippe Mathieu-Daudé wrote:
> > > > On 06/06/2018 10:31 AM, BALATON Zoltan wrote:
> > > > >
On Wed, Jun 13, 2018 at 10:19 AM, Dima Stepanov wrote:
> The qemu_memfd_alloc_check() routine allocates the fd variable on stack.
> This variable is initialized inside the qemu_memfd_alloc() function.
> There are several cases when *fd will be left unintialized which can
> lead to the unexpected
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
> > >> +++ b/hw/ppc/pnv_core.c
> > >> @@ -173,6 +173,9 @@ static void pnv_core_realize(DeviceState
On 06/13/2018 11:00 AM, David Hildenbrand wrote:
> On 13.06.2018 10:18, Christian Borntraeger wrote:
>> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
>> the cpu type differs (3906 vs. 3907)
>>
>> Signed-off-by: Christian Borntraeger
>> ---
>>
On 12/06/2018 21:05, Eric Auger wrote:
> When an IOMMUMemoryRegion is in front of a virtio device,
> address_space_cache_init does not set cache->ptr as the memory
> region is not RAM. However when the device performs an access,
> we end up in glue() which performs the translation and then uses
>
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180613084149.14523-1-kra...@redhat.com
Subject: [Qemu-devel] [PATCH v4 0/3] ramfb: simple boot framebuffer
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git
Remove the legacy esp_init() function now that there are no more remaining
users.
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 30 --
include/hw/scsi/esp.h | 5 -
2 files changed, 35 deletions(-)
diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index
Something else that came out of reviewing Laurent's q800 patchset: after my
SPARC cleanups last year, MIPS Jazz is the last remaining user of the legacy
esp_init() function.
Patch 1 switches mips_jazz_init() over to create the ESP device directly
via qdev. Please note that I do not have any MIPS
MIPS jazz is the last user of the legacy esp_init() function so move creation
of the ESP device over to use qdev.
Note that the esp_reset and dma_enable qemu_irqs are currently unused and so
we do not wire these up and instead remove the variables to prevent the
compiler emitting unused variable
On Wed, Jun 13, 2018 at 10:46:02AM +0200, Cédric Le Goater wrote:
> On 06/13/2018 08:57 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
On Wed, Jun 13, 2018 at 11:14:57AM +0200, Cédric Le Goater wrote:
> >> index 13ad7d9e04..efb68226bb 100644
> >> --- a/hw/ppc/pnv_core.c
> >> +++ b/hw/ppc/pnv_core.c
> >> @@ -173,6 +173,9 @@ static void pnv_core_realize(DeviceState *dev, Error
> >> **errp)
> >>
> >> snprintf(name,
On Wed, 13 Jun 2018 11:14:57 +0200
Cédric Le Goater wrote:
> >> index 13ad7d9e04..efb68226bb 100644
> >> --- a/hw/ppc/pnv_core.c
> >> +++ b/hw/ppc/pnv_core.c
> >> @@ -173,6 +173,9 @@ static void pnv_core_realize(DeviceState *dev, Error
> >> **errp)
> >>
> >> snprintf(name,
On 06/13/2018 11:00 AM, David Hildenbrand wrote:
> On 13.06.2018 10:18, Christian Borntraeger wrote:
>> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
>> the cpu type differs (3906 vs. 3907)
>>
>> Signed-off-by: Christian Borntraeger
>> ---
>>
On Wed, Jun 13, 2018 at 11:46:57AM +0530, P J P wrote:
> From: Prasad J Pandit
>
> While reading file content via 'guest-file-read' command,
> 'qmp_guest_file_read' routine allocates buffer of count+1
> bytes. It could overflow for large values of 'count'.
> Add check to avoid it.
No objection
On Mon, 11 Jun 2018 14:16:46 +0200
David Hildenbrand wrote:
> Our parent class (PC_DIMM) provides exactly the same function.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Igor Mammedov
> ---
> hw/mem/nvdimm.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git
On Tue, Jun 12, 2018 at 03:48:34PM -0400, Farhan Ali wrote:
> The virtio-crypto driver currently propagates to the guest
> all the cipher algorithms that the backend cryptodev can
> support. But in certain cases where the guest has more
> performant mechanism to handle some algorithms, it would be
Hi,
On 06/13/2018 10:05 AM, Markus Armbruster wrote:
> Peter Xu writes:
>
>> Replace existing trace_vtd_err() with error_report_once() then stderr
>> will capture something if any of the error happens, meanwhile we don't
>> suffer from any DDOS. Then remove the trace point. Since at it,
>>
On Wed, Jun 13, 2018 at 09:30:12AM +0100, Mark Cave-Ayland wrote:
> Whilst testing a conversion of Laurent's q800 patchset over to use mos6522
> I discovered some issues which prevented IRQs being generated from inputs to
> external port pins.
>
> This is a requirement for the q800 patchset which
On Wed, Jun 13, 2018 at 10:15:09AM +0200, Cédric Le Goater wrote:
> On 06/13/2018 08:57 AM, David Gibson wrote:
> > In pnv_core_realize() we call two functions with an Error * parameter in
> > succession, which means if they both cause errors we'll lose the first one.
> > Add an extra test/escape
On Wed, Jun 13, 2018 at 10:11:45AM +0200, Cédric Le Goater wrote:
> On 06/13/2018 08:57 AM, David Gibson wrote:
> > 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
On Wed, Jun 13, 2018 at 10:20:43AM +0200, Cédric Le Goater wrote:
> On 06/13/2018 08:57 AM, David Gibson wrote:
> > 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.
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 install it on multiple
> > > systems. What would be the suggested way to
On Mon, 11 Jun 2018 14:16:45 +0200
David Hildenbrand wrote:
> Not needed anymore, let's drop it.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Igor Mammedov
> ---
> hw/mem/pc-dimm.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
>
On Wed, 13 Jun 2018 16:57:05 +1000
David Gibson wrote:
> 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
On Wed, 06/13 10:06, Kevin Wolf wrote:
> Am 13.06.2018 um 09:46 hat Fam Zheng geschrieben:
> > Similar to the host_device's implementation, we check the requested
> > length against the namespace size.
> >
> > Truncation is necessary to make qcow2 creation work.
> >
> > Signed-off-by: Fam Zheng
On Wed, 13 Jun 2018 16:57:04 +1000
David Gibson wrote:
> 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: Greg
>> index 13ad7d9e04..efb68226bb 100644
>> --- a/hw/ppc/pnv_core.c
>> +++ b/hw/ppc/pnv_core.c
>> @@ -173,6 +173,9 @@ static void pnv_core_realize(DeviceState *dev, Error
>> **errp)
>>
>> snprintf(name, sizeof(name), "thread[%d]", i);
>> object_property_add_child(OBJECT(pc),
On Wed, 13 Jun 2018 16:57:03 +1000
David Gibson wrote:
> 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.
>
>
On Wed, 13 Jun 2018 16:57:02 +1000
David Gibson wrote:
> In pnv_core_realize() we call two functions with an Error * parameter in
> succession, which means if they both cause errors we'll lose the first one.
Not exactly. The error code doesn't allow that and QEMU will abort.
static void
On Wed, Jun 13, 2018 at 10:01:22AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > There are many error_report()s that can be used in frequently called
> > functions, especially on IO paths. That can be unideal in that
> > malicious guest can try to trigger the error tons of time which
On Wed, 13 Jun 2018 10:11:45 +0200
Cédric Le Goater wrote:
> On 06/13/2018 08:57 AM, David Gibson wrote:
> > 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
On 13.06.2018 10:18, Christian Borntraeger wrote:
> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
> the cpu type differs (3906 vs. 3907)
>
> Signed-off-by: Christian Borntraeger
> ---
> target/s390x/cpu_models.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Wed, 13 Jun 2018, David Gibson wrote:
On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
Signed-off-by: BALATON Zoltan
---
default-configs/ppc-softmmu.mak| 1 +
default-configs/ppcemb-softmmu.mak | 1 +
hw/i2c/ppc4xx_i2c.c| 14 +-
3 files
This machine type supports two new features:
- highmem 256MB ECAM (default). This feature is disabled for
earlier machine types and if highmem is off.
- max_cpus set to 512 vcpus (255 before)
The high 256MB ECAM region is chosen instead of the legacy
16MB one if the machine type allows it, if
On Wed, 13 Jun 2018, David Gibson wrote:
On Fri, Jun 08, 2018 at 11:20:50AM +0200, BALATON Zoltan wrote:
On Fri, 8 Jun 2018, David Gibson wrote:
On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
Signed-off-by: BALATON Zoltan
It's not clear to me why this is preferable to
On Wed, 13 Jun 2018, David Gibson wrote:
On Wed, Jun 06, 2018 at 07:35:28PM +0200, BALATON Zoltan wrote:
On Wed, 6 Jun 2018, Philippe Mathieu-Daudé wrote:
On 06/06/2018 10:31 AM, BALATON Zoltan wrote:
Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
of day is
With a VGICv3 KVM device, if the number of vcpus exceeds the
capacity of the legacy redistributor region (123 redistributors),
we now attempt to register a second redistributor region. Up to
512 redistributors can fit in this latter on top of the 123 allowed
by the legacy redistributor region.
On Tue, 12 Jun 2018 11:49:22 -0300
Eduardo Habkost wrote:
> On Tue, Jun 12, 2018 at 03:58:03PM +0200, Igor Mammedov wrote:
> [...]
> > > > > +if (xcc->host_cpuid_required && enable_cpu_pm) {
> > > > > +host_cpuid(5, 0, >mwait.eax, >mwait.ebx,
> > > > > + >mwait.ecx,
This patch allows the creation of a GICv3 node with 1 or 2
redistributor regions depending on the number of smu_cpus.
The second redistributor region is located just after the
existing RAM region, at 256GB and contains up to up to 512 vcpus.
Please refer to kernel documentation for further node
To prepare for multiple redistributor regions, we introduce
an array of uint32_t properties that stores the redistributor
count of each redistributor region.
Non accelerated VGICv3 only supports a single redistributor region.
The capacity of all redist regions is checked against the number of
commit b357bf6023a948cf6a9472f07a1b0caac0e4f8e8
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Signed-off-by: Eric Auger
---
include/standard-headers/linux/pci_regs.h| 8
include/standard-headers/linux/virtio_gpu.h | 1 +
Depending on the number of smp_cpus we now register one or two
GICR structures.
Signed-off-by: Eric Auger
---
hw/arm/virt-acpi-build.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 74f5744..eefd1d4 100644
---
for KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute, the attribute
data pointed to by kvm_device_attr.addr is a OR of the
redistributor region address and other fields such as the index
of the redistributor region and the number of redistributors the
region can contain.
The existing machine init
Let's check if KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION is supported.
If not, we check the number of redist region is equal to 1 and use the
legacy KVM_VGIC_V3_ADDR_TYPE_REDIST attribute. Otherwise we use
the new attribute and allow to register multiple regions to the
KVM device.
Signed-off-by: Eric
This patch defines a new ECAM region located after the 256GB limit.
The virt machine state is augmented with a new highmem_ecam field
which guards the usage of this new ECAM region instead of the legacy
16MB one. With the highmem ECAM region, up to 256 PCIe buses can be
used.
Signed-off-by: Eric
On Tue, 12 Jun 2018 17:19:23 -0500
Michael Roth wrote:
> Also add a few more details regarding normal master->stable patch
> flow.
>
> Cc: Cornelia Huck
> Signed-off-by: Michael Roth
> ---
> docs/devel/stable-process.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff
This series increases the number of vcpus usable in accelerated mode
along with GICv3 and allows up to 256 PCIe busses.
It is a combination of 2 series:
[1] [RFC v3 0/8] KVM/ARM: Relax the max 123 vcpus limitation along
with KVM GICv3
[2] [PATCH 0/2] ARM virt: Support up to 256 PCIe buses
On 06/13/2018 08:57 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.
yes and that made sense in terms of modeling because you
On Tue, Jun 12, 2018 at 11:50:30PM -0400, Emilio G. Cota wrote:
> On Tue, Jun 12, 2018 at 23:15:49 -0400, Yaowei Bai wrote:
> > Signed-off-by: Yaowei Bai
> > ---
> > docs/devel/tracing.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/docs/devel/tracing.txt
Hi,
So, the first ramfb bits should be ready for merge. This series
includes the ramfb core support bits, the ramfb standalone device
and vfio-pci-ramfb device for vgpu boot display support.
If you want play with it I recommend getting the bits from
So we have a boot display when using a vgpu as primary display.
Use vfio-pci-ramfb instead of vfio-pci to enable it.
Signed-off-by: Gerd Hoffmann
---
include/hw/vfio/vfio-common.h | 2 ++
hw/vfio/display.c | 10 ++
hw/vfio/pci.c | 15 +++
3
The boot framebuffer is expected to be configured by the firmware, so it
uses fw_cfg as interface. Initialization goes as follows:
(1) Check whenever etc/ramfb is present.
(2) Allocate framebuffer from RAM.
(3) Fill struct RAMFBCfg, write it to etc/ramfb.
Done. You can write stuff to the
Signed-off-by: Gerd Hoffmann
---
include/hw/display/ramfb.h| 3 +++
hw/arm/sysbus-fdt.c | 7 +
hw/arm/virt.c | 2 ++
hw/display/ramfb-standalone.c | 62 +++
hw/i386/pc_piix.c | 2 ++
hw/i386/pc_q35.c
On Wed, 13 Jun 2018 16:57:01 +1000
David Gibson wrote:
> 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
The datasheet indicates that the interrupt is generated by ANDing the
interrupt flags register (IFR) with the interrupt enable register (IER)
but currently there is an extra filter for the SR and timer interrupts.
Remove this extra filter to allow interrupts to be generated by external
inputs on
According to the 6522 datasheet the shift register (SR) interrupt flag is
cleared upon write with no mention of any other interrupt flags.
Signed-off-by: Mark Cave-Ayland
---
hw/misc/mos6522.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/misc/mos6522.c
In the case where we have an interrupt generated externally from inputs to
bits 1 and 2 of port A and/or port B, it is necessary to expose
mos6522_update_irq() so it can be called by the interrupt source.
Signed-off-by: Mark Cave-Ayland
---
hw/misc/mos6522.c | 1 +
Whilst testing a conversion of Laurent's q800 patchset over to use mos6522
I discovered some issues which prevented IRQs being generated from inputs to
external port pins.
This is a requirement for the q800 patchset which uses external clocks to
generate periodic interrupts.
Signed-off-by: Mark
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 TYPE_PXB_PCI_HOST by default,
> > add a new type TYPE_PXB_PCIE_HOST to better utilize the ECAM of PCIe
> >
> > Signed-off-by: Zihan Yang
>
>
During the development process we used scan-build as static analyzer to
check the changes. There are some issues found. The patch set below is
to resolve issues found.
Changes v2:
- remove one patch, since it was resolved by: 7eb24009
Dima Stepanov (2):
memfd: fix possible usage of the
On Tue, 12 Jun 2018 14:59:33 +0200
Christian Borntraeger wrote:
> Right now the IPL device always starts from address 0x1 (the usual
> Linux entry point). To run other guests (e.g. test programs) it is
> useful to use the IPL PSW from address 0. We can use the Linux magic
> at 0x10008 to
In the memory_region_do_invalidate_mmio_ptr() routine the section
variable is intialized by the memory_region_find() call. The section.mr
field can be set to NULL.
Add the check for NULL before trying to drop a section.
Signed-off-by: Dima Stepanov
---
memory.c | 2 +-
1 file changed, 1
On Wed, 13 Jun 2018 10:45:06 +1000
David Gibson wrote:
> On Tue, Jun 12, 2018 at 07:04:15PM +0200, Greg Kurz wrote:
> > Bits set in the PCR disable features of the processor. TCG currently
> > doesn't implement that, ie, we always act like if PCR is all zeros.
> >
> > But it is still possible
301 - 400 of 435 matches
Mail list logo
