On 29/10/18 15:48, Peter Maydell wrote:
> On 29 October 2018 at 15:40, Marc Zyngier wrote:
>> My temptation would be not to expose it at all when running on a v7
>> core, and return an error rather than zero.
>>
>> The other issue is that we currently don't support running 32bit KVM on
>> any ARMv
Last lot of patches for arm before softfreeze tomorrow...
thanks
-- PMM
The following changes since commit ef3a6af5e789ff078d1fef880f9dfb6adf18e8f1:
Merge remote-tracking branch 'remotes/kraxel/tags/vga-20181029-pull-request'
into staging (2018-10-29 12:59:15 +)
are available
In addition to providing the core with the current ASID, this minimizes
both the number of flushes due to non-changing ASID as well as the set
of mmu_idx that are affected by each flush.
In particular, updates to the secure mode registers flushes only the
relevant secure mode mmu_idx's, and simila
From: Julia Suvorova via Qemu-devel
Not implemented: CTS/NCTS, PSEL*.
Signed-off-by: Julia Suvorova
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Peter Maydell
---
hw/char/Makefile.objs| 1 +
include/hw/char/nrf51_uart.h | 78 +
hw/char/nrf51_uart.c | 330 +++
The VMID is the ASID for the 2nd stage page lookup.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index f767467dcf..4b14f2c05b 100644
--- a/target
From: "Edgar E. Iglesias"
Add a virtual Xilinx Versal board.
This board is based on the Xilinx Versal SoC. The exact
details of what peripherals are attached to this board
will remain in control of QEMU. QEMU will generate an
FDT on the fly for Linux and other software to auto-discover
periphera
Emilio G. Cota writes:
> On Sat, Oct 27, 2018 at 10:14:47 +0100, Alex Bennée wrote:
>>
>> Emilio G. Cota writes:
>>
>> > [I forgot to add the cover letter to git send-email; here it is]
>> >
>> > v3: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg04179.html
>> >
>> > "Why is this an
Alistair has been contributing to the RISC-V QEMU port for a while now
so I'd like him to be officially listed as a maintainer. I've checked
with the other RISC-V mainatiners and there are no objectics, and I've
also checked with Alistair so he knows I'm volunteering him.
Signed-off-by: Palmer Da
Collin will take over the maintainership from Yi Min. Let us add a
separate s390 pci section.
Signed-off-by: Christian Borntraeger
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb23555..e63cfa2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Halil does all the work anyway.
Signed-off-by: Christian Borntraeger
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 10045b6..cb23555 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1262,7 +1262,7 @@ T: git git://github.com/stefa
We make the ARM virt ACPI code use the now shared build_rsdp() API from
aml-build.c. By doing so we fix a bug where the ARM implementation was
missing adding both the legacy and extended checksums, which was
building an invalid RSDP table.
Signed-off-by: Samuel Ortiz
---
hw/arm/virt-acpi-build.c
This is going to be needed by the Hardware-reduced ACPI routines.
Signed-off-by: Samuel Ortiz
---
hw/acpi/aml-build.c | 8
hw/i386/acpi-build.c| 8
include/hw/acpi/aml-build.h | 2 ++
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/acpi/aml-bu
On 10/29/18 2:58 PM, Peter Maydell wrote:
> I think I would prefer it if we expanded the id_isar* fields
> in the ARMISARegisters struct to uint64_t. If you dislike
> that, I think we should make this code fail a bit more gracefully
> in the presence of an unexpected extension into the high bits
>
From: Yang Zhong
Make it more flexible by having it parsing a PCI host paths array
instead of open coding those paths deep down into the code logic itself.
This will be needed for PCI machine types that are neither emulatiing the
ich9 nor the i440fx chipsets.
Signed-off-by: Yang Zhong
---
hw/i
From: Yang Zhong
The _OSC AML table is almost identical between the i386 Q35 and arm virt
machine types. We can make it slightly more generic and share it across
all PCIe architectures.
Signed-off-by: Yang Zhong
---
hw/acpi/aml-build.c | 84 +++--
hw/arm
This is less complex than the LPAE case, but still we now avoid the
flush in case it is only the PROCID field that is changing.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/target
From: Yang Zhong
Most of the AML build routines under acpi-build are not even
architecture specific. They can be moved to the more generic hw/acpi
folder where they could be shared across machine types and
architectures.
Signed-off-by: Yang Zhong
---
hw/acpi/aml-build.c | 498 +
The hardware-reduced API will need to build RSDP as well, so we should
export this routine. While doing so, we also slightly change the
function prototype. Since no caller needs it, and to make it more
consistent with the rest of the AML build API, the function no longer
returns its RSDP table.
Si
On 10/29/2018 04:42 PM, Christian Borntraeger wrote:
> Halil does all the work anyway.
>
> Signed-off-by: Christian Borntraeger
Acked-by: Halil Pasic
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10045b6..cb2
Emilio G. Cota writes:
> The few direct users of &cpu->lock will be converted soon.
>
> Signed-off-by: Emilio G. Cota
> ---
> include/qom/cpu.h | 33 +++
> cpus.c | 48 +++--
> stubs/cpu-lock.c| 20
From: Yang Zhong
The SRAT ACPI table is not x86 specific and will be needed for the
Hardware-reduced ACPI implementation. So we should export it through the
architecture independent hw/acpi folder.
Also, now that the generic build_srat() API is exported, we have to
rename the ARM static one in o
From: Yang Zhong
The ACPI MCFG getter is not x86 specific and could be called from
anywhere within generic ACPI API, so let's export it.
Signed-off-by: Yang Zhong
---
hw/acpi/aml-build.c | 24
hw/i386/acpi-build.c| 22 --
include/hw/
From: Sebastien Boeuf
The ACPI hotplug support for PCI devices APIs are not x86 or even
machine type specific. In order for future machine types to be able to
re-use that code, we export it through the architecture agnostic
hw/acpi folder.
Signed-off-by: Sebastien Boeuf
Signed-off-by: Jing Liu
From: Sebastien Boeuf
Instead of using the machine type specific method find_i440fx() to
retrieve the PCI bus, this commit aims to rely on the fact that the
PCI bus is known by the structure AcpiPciHpState.
When the structure is initialized through acpi_pcihp_init() call,
it saves the PCI bus, w
This property is currently defined under i386/pc while it only describes
a region size that's eventually fetched from the AML ACPI code.
We can make it more generic and shareable across machine types by moving
it to memory-device.h instead.
Signed-off-by: Samuel Ortiz
---
hw/i386/acpi-build.c
This patch set provides an ACPI code reorganization in preparation for
adding hardware-reduced support to QEMU.
The changes are coming from the NEMU [1] project where we're defining
a new x86 machine type: i386/virt. This is an EFI only, ACPI
hardware-reduced platform and as such we had to impleme
All PC machine type derivatives will use the same ACPI table build
methods. But with that change in place, any new x86 machine type will be
able to re-use the acpi-build API and customize part of it by defining
its own ACPI table build methods.
Cc: "Michael S. Tsirkin"
Cc: Igor Mammedov
Cc: Marc
It is going to be used by the PC machine type as the MADT table builder
method and thus needs to be exported outside of acpi-build.c
Also, now that the generic build_madt() API is exported, we have to
rename the ARM static one in order to avoid build time conflicts.
Signed-off-by: Samuel Ortiz
-
CPU and memory ACPI hotplug are not necessarily handled through SCI
events. For example, with Hardware-reduced ACPI, the GED device will
manage ACPI hotplug entirely.
As a consequence, we make the CPU and memory specific events AML
generation optional. The code will only be added when the method na
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
Description Table). RSDT only allow for 32-bit addressses and have thus
been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and
no longer RSDTs, although RSDTs are still supported for backward
compatibility.
Since ver
On 29.10.18 11:51, Peter Maydell wrote:
> Hi; could somebody who understands the block layer refcounting have
> a look at Coverity issues CID 1395870 and 1395871, please?
Don't forget 1395869.
> In both
> cases, Coverity reports a use-after-free because it thinks that a
> sequence where a code pa
On 29/10/18 17:16, Palmer Dabbelt wrote:
Alistair has been contributing to the RISC-V QEMU port for a while now
so I'd like him to be officially listed as a maintainer. I've checked
with the other RISC-V mainatiners and there are no objectics, and I've
"maintainers" "objections"
also checked
From: Yang Zhong
When using the generated memory hotplug AML, the iasl
compiler would give the following error:
dsdt.dsl 266: Return (MOST (_UID, Arg0, Arg1, Arg2))
Error 6080 - Called method returns no value ^
Signed-off-by: Yang Zhong
---
hw/acpi/memory_hotplug.c | 10 +-
1 file cha
ACPI tables are platform and machine type and even architecture
agnostic, and as such we want to provide an internal ACPI API that
only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently
from the PC or Q35 machine types, we are moving a
From: Yang Zhong
The AML build routines for the PCI host bridge and the corresponding
DSDT addition are neither x86 nor PC machine type specific.
We can move them to the architecture agnostic hw/acpi folder, and by
carrying all the needed information through a new AcpiPciBus structure,
we can mak
On 10/29/2018 11:42 AM, Christian Borntraeger wrote:
Eric and Farhan will help with maintaining vfio-ccw.
Signed-off-by: Christian Borntraeger
Acked-by: Eric Farman
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d794bd7..10045b6
On Mon, Oct 29, 2018 at 13:59:03 +0300, Pavel Dovgalyuk wrote:
> > From: Emilio G. Cota [mailto:c...@braap.org]
> > Signed-off-by: Emilio G. Cota
(snip)
> Thanks for the series.
> Can you provide more plugin examples for better understanding of
> double-translate idea?
> E.g., plugins that hook s
On Mon, Oct 29, 2018 at 12:48:05 +0300, Pavel Dovgalyuk wrote:
> > From: Emilio G. Cota [mailto:c...@braap.org]
> > - 2-pass translation. Once a "TB translation" callback is called,
> > the plugin must know the span of the TB. We should not
> > force plugins to guess where the TB will end; that
In order to decouple ACPI APIs from specific machine types, we are
creating an ACPI builder interface that each ACPI platform can choose to
implement.
This way, a new machine type can re-use the high level ACPI APIs and
define some custom table build methods, without having to duplicate most
of the
Please discard that serie as I forgot to Cc the proper maintainers in
many of those patches. Apologies for that, I'm going to send a v3 in a
few minutes.
Cheers,
Samuel.
On Mon, Oct 29, 2018 at 05:24:22PM +0100, Samuel Ortiz wrote:
> This patch set provides an ACPI code reorganization in preparat
On Mon, Oct 29, 2018 at 9:44 AM Philippe Mathieu-Daudé
wrote:
>
> On 29/10/18 17:16, Palmer Dabbelt wrote:
> > Alistair has been contributing to the RISC-V QEMU port for a while now
> > so I'd like him to be officially listed as a maintainer. I've checked
> > with the other RISC-V mainatiners and
Emilio G. Cota writes:
> We don't pass a pointer to qemu_global_mutex anymore.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: Emilio G. Cota
As discussed on IRC I don't fundamentally object to this being in
cpus-common given we have the other work queue stuff there. However
given it now
* zly371549296 (zly371549...@163.com) wrote:
> Hello, I would like to consult different versions of qemu virtual
> machine. If I am doing hot migration, my current environment is cloudstack+
> KVM +ceph. One host has qemu version 2.9 and another has qemu version 2.6.I
> tried low versio
Emilio G. Cota writes:
> This completes the conversion to cpu_mutex_lock/unlock in the file.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: Emilio G. Cota
Reviewed-by: Alex Bennée
> ---
> cpus-common.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> dif
This is going to be needed by the Hardware-reduced ACPI routines.
Signed-off-by: Samuel Ortiz
---
hw/acpi/aml-build.c | 8
hw/i386/acpi-build.c| 8
include/hw/acpi/aml-build.h | 2 ++
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/acpi/aml-bu
This patch set provides an ACPI code reorganization in preparation for
adding hardware-reduced support to QEMU.
The changes are coming from the NEMU [1] project where we're defining
a new x86 machine type: i386/virt. This is an EFI only, ACPI
hardware-reduced platform and as such we had to impleme
From: Yang Zhong
Make it more flexible by having it parsing a PCI host paths array
instead of open coding those paths deep down into the code logic itself.
This will be needed for PCI machine types that are neither emulatiing the
ich9 nor the i440fx chipsets.
Signed-off-by: Yang Zhong
---
hw/i
The hardware-reduced API will need to build RSDP as well, so we should
export this routine. While doing so, we also slightly change the
function prototype. Since no caller needs it, and to make it more
consistent with the rest of the AML build API, the function no longer
returns its RSDP table.
Si
ACPI tables are platform and machine type and even architecture
agnostic, and as such we want to provide an internal ACPI API that
only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently
from the PC or Q35 machine types, we are moving a
We make the ARM virt ACPI code use the now shared build_rsdp() API from
aml-build.c. By doing so we fix a bug where the ARM implementation was
missing adding both the legacy and extended checksums, which was
building an invalid RSDP table.
Signed-off-by: Samuel Ortiz
---
hw/arm/virt-acpi-build.c
From: Yang Zhong
When using the generated memory hotplug AML, the iasl
compiler would give the following error:
dsdt.dsl 266: Return (MOST (_UID, Arg0, Arg1, Arg2))
Error 6080 - Called method returns no value ^
Signed-off-by: Yang Zhong
---
hw/acpi/memory_hotplug.c | 10 +-
1 file cha
This property is currently defined under i386/pc while it only describes
a region size that's eventually fetched from the AML ACPI code.
We can make it more generic and shareable across machine types by moving
it to memory-device.h instead.
Signed-off-by: Samuel Ortiz
---
hw/i386/acpi-build.c
From: Yang Zhong
Most of the AML build routines under acpi-build are not even
architecture specific. They can be moved to the more generic hw/acpi
folder where they could be shared across machine types and
architectures.
Signed-off-by: Yang Zhong
---
hw/acpi/aml-build.c | 498 +
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
Description Table). RSDT only allow for 32-bit addressses and have thus
been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and
no longer RSDTs, although RSDTs are still supported for backward
compatibility.
Since ver
It is going to be used by the PC machine type as the MADT table builder
method and thus needs to be exported outside of acpi-build.c
Also, now that the generic build_madt() API is exported, we have to
rename the ARM static one in order to avoid build time conflicts.
Signed-off-by: Samuel Ortiz
-
All PC machine type derivatives will use the same ACPI table build
methods. But with that change in place, any new x86 machine type will be
able to re-use the acpi-build API and customize part of it by defining
its own ACPI table build methods.
Signed-off-by: Samuel Ortiz
---
hw/i386/acpi-build.
CPU and memory ACPI hotplug are not necessarily handled through SCI
events. For example, with Hardware-reduced ACPI, the GED device will
manage ACPI hotplug entirely.
As a consequence, we make the CPU and memory specific events AML
generation optional. The code will only be added when the method na
From: Yang Zhong
The _OSC AML table is almost identical between the i386 Q35 and arm virt
machine types. We can make it slightly more generic and share it across
all PCIe architectures.
Signed-off-by: Yang Zhong
---
hw/acpi/aml-build.c | 84 +++--
hw/arm
On Mon, 29 Oct 2018 09:30:54 PDT (-0700), phi...@redhat.com wrote:
On 29/10/18 17:16, Palmer Dabbelt wrote:
Alistair has been contributing to the RISC-V QEMU port for a while now
so I'd like him to be officially listed as a maintainer. I've checked
with the other RISC-V mainatiners and there ar
From: Yang Zhong
The ACPI MCFG getter is not x86 specific and could be called from
anywhere within generic ACPI API, so let's export it.
Signed-off-by: Yang Zhong
---
hw/acpi/aml-build.c | 24
hw/i386/acpi-build.c| 22 --
include/hw/
ble in the git repository at:
>
> git://git.kraxel.org/qemu tags/audio-20181029-pull-request
>
> for you to fetch changes up to d436d4e7a50a7c4fddc0569c2107fe5eaf0e1fbc:
>
> audio: use TYPE_MV88W8618_AUDIO instead of
On Mon, 29 Oct 2018 09:48:30 PDT (-0700), alistai...@gmail.com wrote:
On Mon, Oct 29, 2018 at 9:44 AM Philippe Mathieu-Daudé
wrote:
On 29/10/18 17:16, Palmer Dabbelt wrote:
> Alistair has been contributing to the RISC-V QEMU port for a while now
> so I'd like him to be officially listed as a m
From: Yang Zhong
The AML build routines for the PCI host bridge and the corresponding
DSDT addition are neither x86 nor PC machine type specific.
We can move them to the architecture agnostic hw/acpi folder, and by
carrying all the needed information through a new AcpiPciBus structure,
we can mak
From: Sebastien Boeuf
The ACPI hotplug support for PCI devices APIs are not x86 or even
machine type specific. In order for future machine types to be able to
re-use that code, we export it through the architecture agnostic
hw/acpi folder.
Signed-off-by: Sebastien Boeuf
Signed-off-by: Jing Liu
From: Sebastien Boeuf
Instead of using the machine type specific method find_i440fx() to
retrieve the PCI bus, this commit aims to rely on the fact that the
PCI bus is known by the structure AcpiPciHpState.
When the structure is initialized through acpi_pcihp_init() call,
it saves the PCI bus, w
In order to decouple ACPI APIs from specific machine types, we are
creating an ACPI builder interface that each ACPI platform can choose to
implement.
This way, a new machine type can re-use the high level ACPI APIs and
define some custom table build methods, without having to duplicate most
of the
From: Yang Zhong
The SRAT ACPI table is not x86 specific and will be needed for the
Hardware-reduced ACPI implementation. So we should export it through the
architecture independent hw/acpi folder.
Also, now that the generic build_srat() API is exported, we have to
rename the ARM static one in o
On Mon, Oct 29, 2018 at 10:14 AM Palmer Dabbelt wrote:
>
> On Mon, 29 Oct 2018 09:48:30 PDT (-0700), alistai...@gmail.com wrote:
> > On Mon, Oct 29, 2018 at 9:44 AM Philippe Mathieu-Daudé
> > wrote:
> >>
> >> On 29/10/18 17:16, Palmer Dabbelt wrote:
> >> > Alistair has been contributing to the RI
On 29/10/2018 18:01, Samuel Ortiz wrote:
> @@ -1556,6 +1557,7 @@ void acpi_build(AcpiBuildTables *tables,
> GArray *tables_blob = tables->table_data;
> AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
> Object *vmgenid_dev;
> +AcpiBuilder *ab = ACPI_BUILDER(machine);
>
You neglected to cc: maintainers. I'm doing that for you now.
scripts/get_maintainer.pl can help you finding maintainers.
Samuel Ortiz writes:
> This patch set provides an ACPI code reorganization in preparation for
> adding hardware-reduced support to QEMU.
>
> The changes are coming from the
scsi-generic (pass through) devices are able to inject an artificial Block
Limits VPD page in order to communicate host HBA limits to the guest.
However, Max Reitz found a few issues with the implementation of this
feature; this series should fix them all.
Paolo
Paolo Bonzini (4):
scsi-generic:
Block limits emulation is just placing 0xb0 as the final byte of the
VPD pages list. However, VPD page numbers must be sorted, so change
that to an in-place insert. Since I couldn't find any disk that triggered
the loop more than once, this was tested by adding manually 0xb1
at the end of the lis
A device can report an excessive number of VPD pages when asked for a
list; this can cause an out-of-bounds access to buf in
scsi_generic_set_vpd_bl_emulation. It should not happen, but
it is technically not incorrect so handle it: do not check any byte
past the allocation length that was sent to
Emulation of the block limits VPD page called back into scsi-disk.c,
which however expected the request to be for a SCSIDiskState and
accessed a scsi-generic device outside the bounds of its struct
(namely to retrieve s->max_unmap_size and s->max_io_size).
To avoid this, move the emulation code to
Pass other sense, such as UNIT_ATTENTION or BUSY, directly to the
guest.
Reported-by: Max Reitz
Signed-off-by: Paolo Bonzini
---
hw/scsi/scsi-generic.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
index 8fc74ef0bd..b
On 10/29/2018 11:42 AM, Christian Borntraeger wrote:
> Collin will take over the maintainership from Yi Min. Let us add a
> separate s390 pci section.
>
> Signed-off-by: Christian Borntraeger
Acked-by: Collin Walling
> ---
> MAINTAINERS | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff
ping2
Hi, what about this finally? Looks like everyone see a lot of comments
and thing, that there should be a new version, but actually, there is
almost unrelated discussion and/or answered questions. Only rephrasing
by Eric in patch 2 may be applied, to change something.
The series fix the bu
On 26/10/2018 22:55, Peter Maydell wrote:
>> +assert(len <= LSI_MAX_MSGIN_LEN);
>> pci_dma_write(PCI_DEVICE(s), s->dnad, s->msg, len);
>> /* Linux drivers rely on the last byte being in the SIDL. */
>> s->sidl = s->msg[len - 1];
> Is it possible to get here with len == 0 ?
No,
On 29 October 2018 at 17:14, Palmer Dabbelt wrote:
> I don't think we have anything ready to go right now: your PCIe patches
> still have some outstanding feedback (on interrupt stuff), and Bastian's
> decodetree stuff has some patches from Richard Henderson that should be
> merged in. I was hopi
On 29/10/2018 18:56, Paolo Bonzini wrote:
> On 26/10/2018 22:55, Peter Maydell wrote:
>>> +assert(len <= LSI_MAX_MSGIN_LEN);
>>> pci_dma_write(PCI_DEVICE(s), s->dnad, s->msg, len);
>>> /* Linux drivers rely on the last byte being in the SIDL. */
>>> s->sidl = s->msg[len - 1];
>>
On 10/29/2018 01:52 PM, Vladimir Sementsov-Ogievskiy wrote:
> ping2
>
> Hi, what about this finally? Looks like everyone see a lot of comments
> and thing, that there should be a new version, but actually, there is
> almost unrelated discussion and/or answered questions. Only rephrasing
> by
On 29 October 2018 at 13:56, Stefan Hajnoczi wrote:
> The following changes since commit 285278ca785f5fa9a570927e1c0958a2ca2b2150:
>
> Merge remote-tracking branch 'remotes/famz/tags/testing-pull-request' into
> staging (2018-10-27 19:55:08 +0100)
>
> are available in the Git repository at:
>
>
On Mon, 29 Oct 2018 10:59:47 PDT (-0700), Peter Maydell wrote:
On 29 October 2018 at 17:14, Palmer Dabbelt wrote:
I don't think we have anything ready to go right now: your PCIe patches
still have some outstanding feedback (on interrupt stuff), and Bastian's
decodetree stuff has some patches fr
Hi Samuel,
On 29/10/18 18:01, Samuel Ortiz wrote:
The hardware-reduced API will need to build RSDP as well, so we should
export this routine. While doing so, we also slightly change the
function prototype. Since no caller needs it, and to make it more
consistent with the rest of the AML build AP
On 29/10/18 18:01, Samuel Ortiz wrote:
This is going to be needed by the Hardware-reduced ACPI routines.
Signed-off-by: Samuel Ortiz
---
hw/acpi/aml-build.c | 8
hw/i386/acpi-build.c| 8
include/hw/acpi/aml-build.h | 2 ++
3 files changed, 10 insertions(+)
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Yang Zhong
Most of the AML build routines under acpi-build are not even
architecture specific. They can be moved to the more generic hw/acpi
folder where they could be shared across machine types and
architectures.
Signed-off-by: Yang Zhong
---
h
Hi, Cameron.
The step "Start QEMU and boot Mac OS X 10.4.11" is not clear to me. Is
there a location where one could download such image and boot?
I wonder how one without access to a Mac image can reproduce this issue.
Cheers
Murilo
--
You received this bug notification because you are a mem
Hi Yang, Samuel.
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Yang Zhong
Make it more flexible by having it parsing a PCI host paths array
instead of open coding those paths deep down into the code logic itself.
This will be needed for PCI machine types that are neither emulatiing the
ich9 nor
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Yang Zhong
The AML build routines for the PCI host bridge and the corresponding
DSDT addition are neither x86 nor PC machine type specific.
We can move them to the architecture agnostic hw/acpi folder, and by
carrying all the needed information throu
On 10/29/2018 11:42 AM, Christian Borntraeger wrote:
Eric and Farhan will help with maintaining vfio-ccw.
Signed-off-by: Christian Borntraeger
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d794bd7..10045b6 100644
--- a/MAINTAINERS
++
On 29/10/18 20:23, Philippe Mathieu-Daudé wrote:
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Yang Zhong
The AML build routines for the PCI host bridge and the corresponding
DSDT addition are neither x86 nor PC machine type specific.
We can move them to the architecture agnostic hw/acpi folder
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Yang Zhong
The ACPI MCFG getter is not x86 specific and could be called from
anywhere within generic ACPI API, so let's export it.
Signed-off-by: Yang Zhong
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
hw/acpi/a
On 29/10/18 18:01, Samuel Ortiz wrote:
CPU and memory ACPI hotplug are not necessarily handled through SCI
events. For example, with Hardware-reduced ACPI, the GED device will
manage ACPI hotplug entirely.
As a consequence, we make the CPU and memory specific events AML
generation optional. The c
On 29/10/18 18:01, Samuel Ortiz wrote:
This property is currently defined under i386/pc while it only describes
a region size that's eventually fetched from the AML ACPI code.
We can make it more generic and shareable across machine types by moving
it to memory-device.h instead.
It makes sens
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Yang Zhong
The SRAT ACPI table is not x86 specific and will be needed for the
Hardware-reduced ACPI implementation. So we should export it through the
architecture independent hw/acpi folder.
Also, now that the generic build_srat() API is exported,
Microbit programs are typically in Intel HEX (.hex) format. The generic
loader supports .hex files but it doesn't work as expected:
$ qemu-system-arm -M microbit -device loader,file=microbit.hex
Guest image must be specified (using -kernel)
This error comes from armv7m_load_kernel(). Don't
On 29/10/18 18:01, Samuel Ortiz wrote:
From: Sebastien Boeuf
The ACPI hotplug support for PCI devices APIs are not x86 or even
machine type specific. In order for future machine types to be able to
re-use that code, we export it through the architecture agnostic
hw/acpi folder.
Signed-off-by:
Hi Samuel,
On 29/10/18 18:01, Samuel Ortiz wrote:
ACPI tables are platform and machine type and even architecture
agnostic, and as such we want to provide an internal ACPI API that
only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independent
Shannon Zhao's email at Huawei is bouncing: remove it.
X-Failed-Recipients: zhaoshengl...@huawei.com
** Address not found **
Your message wasn't delivered to zhaoshengl...@huawei.com because the
address couldn't be found, or is unable to receive mail.
Note that the section still cont
On Sat, 27 Oct 2018 01:42:02 PDT (-0700), alistai...@gmail.com wrote:
On Fri, Oct 26, 2018 at 7:14 PM Dayeol Lee wrote:
Hi,
I submitted the patch, but just found this has been already fixed by
Michael Clark
and pushed to riscv/riscv-qemu https://github.com/riscv/riscv-qemu/pull/166
but not in
201 - 300 of 391 matches
Mail list logo
