On Thu, 21 Oct 2021, Michael S. Tsirkin wrote:
> On Thu, Oct 21, 2021 at 07:18:43AM +0530, Ani Sinha wrote:
> >
> >
> > On Wed, Oct 20, 2021 at 2:09 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Oct 07, 2021 at 07:27:47PM +0530, Ani Sinha wrote:
> > > changelist:
> > > v3: removed "
On Thu, Oct 21, 2021 at 4:34 AM Jason Wang wrote:
>
> On Wed, Oct 20, 2021 at 8:07 PM Eugenio Perez Martin
> wrote:
> >
> > On Wed, Oct 20, 2021 at 11:01 AM Jason Wang wrote:
> > >
> > > On Wed, Oct 20, 2021 at 3:54 PM Eugenio Perez Martin
> > > wrote:
> > > >
> > > > On Tue, Oct 19, 2021 at 11
Hi Yanan,
On 10/20/21 4:21 PM, Yanan Wang wrote:
> Run ./tests/data/acpi/rebuild-expected-aml.sh from build directory
> to update PPTT binary. Also empty bios-tables-test-allowed-diff.h.
>
> Disassembled output of the updated new file:
>
> /*
> * Intel ACPI Component Architecture
> * AML/ASL+
Hi Yanan,
On 10/20/21 4:21 PM, Yanan Wang wrote:
> From: Andrew Jones
>
> Add the Processor Properties Topology Table (PPTT) used to
> describe CPU topology information to ACPI guests.
>
> Note, a DT-boot Linux guest with a non-flat CPU topology will
> see socket and core IDs being sequential i
> Yes I should follow this up, thanks for asking.
>
> Though after Markus and Igor pointed out to me that it's much more than types
> of device and objects to order, I don't have a good way to fix the ordering
> issue for good on all the problems; obviously current solution only applies to
> devic
On Wed, Oct 20, 2021 at 04:02:41PM +0200, Paolo Bonzini wrote:
An updated version of the patch at
https://patchew.org/QEMU/ywm6jbou9fuib...@os.inf.tu-dresden.de/,
which includes the necessary glue for compatibility with older
machine types. When fw_cfg DMA is disabled, the existing ROM
is used i
On 21/10/2021 08.48, Christophe Leroy wrote:
Le 20/10/2021 à 15:16, Christophe Leroy a écrit :
Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
On 10/20/21 13:42, BALATON Zoltan wrote:
On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
On 10/5/21 14:29, Thomas Huth wrote:
On 05/10/2021
On [2021 Oct 18] Mon 15:26:05, Cédric Le Goater wrote:
> On the AST2600, the 2nd watchdog timer can be controlled through the
> FMC controller to disable the alternate boot function. Next changes
> will map the WDT2 registers in the AST2600 FMC memory region. Add a
> container on top of the registe
On [2021 Oct 18] Mon 15:26:06, Cédric Le Goater wrote:
> Next changes will map the WDT2 registers in the AST2600 FMC memory
> region. Make sure the MemoryRegion pointers are correctly initialized
> before setting the object links.
>
> Do the same in the Aspeed AST2400 and AST2500 SoC models for
>
On Mon, Oct 18, 2021 at 10:38 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Update the OpenTitan machine model to match the latest OpenTitan FPGA
> design.
>
> Signed-off-by: Alistair Francis
> ---
> include/hw/riscv/opentitan.h | 6 +++---
> hw/riscv/opentitan.c | 22 +
On [2021 Oct 18] Mon 15:26:08, Cédric Le Goater wrote:
> Because AddressSpaces must not be sysbus-mapped, commit e9c568dbc225
> ("hw/arm/aspeed: Do not sysbus-map mmio flash region directly, use
> alias") introduced an alias for the flash mmio region.
>
> Using a container is cleaner.
>
> Cc: Phi
On Mon, Oct 18, 2021 at 10:39 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> The Ibex PLIC is now spec complient. Let's remove the Ibex PLIC and
typo: compliant
> instead use the SiFive PLIC.
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/ibex_plic.c | 307
On Mon, Oct 18, 2021 at 10:39 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 45 +++
> 1 file changed, 24 insertions(+), 21 deletions(-)
>
Reviewed-by: Bin Meng
On Mon, Oct 18, 2021 at 10:39 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
Reviewed-by: Bin Meng
On Mon, Oct 18, 2021 at 10:39 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
Reviewed-by: Bin Meng
On Mon, Oct 18, 2021 at 10:40 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/hw/intc/sifive_plic.c b/hw/intc/sifive_plic.c
> index 877e76877c..5444368
On 2021/10/21 14:24, Song Gao wrote:
> Hi, Xuerui
>
> On 10/18/2021 11:49 PM, WANG Xuerui wrote:
>> Hi Song,
>>
>> On 10/18/21 20:47, Song Gao wrote:
>>> Signed-off-by: Song Gao
>>> Signed-off-by: Xiaojuan Yang
>>> Reviewed-by: Richard Henderson
>>> ---
>>> scripts/qemu-binfmt-conf.sh | 6
Hi
We are hitting this bug. We have specialist hardwares including hi-
memory hypervisors to run HPC workload on virtualised environment. This
bug is affecting us at the machines which has more than 1TB of memory.
--
You received this bug notification because you are a member of qemu-
devel-ml,
(In reply to sir...@gmail.com from comment #1)
> Hi
>
> We are hitting this bug. We have specialist hardwares including hi-memory
> hypervisors to run HPC workload on virtualised environment. This bug is
> affecting us at the machines which has more than 1TB of memory.
This bz# is not a bug, but
Hello.
Recently I had to deal with a VM with ~2.7 TB of RAM. The [open]SUSE
QEMU package carries a patch for bumping the default maximum virtual
address bits to 42 (from 40). Now, the last entry of the VM's e820 was
this one:
BIOS-e820: [mem 0x0001-0x02b57fff] usable
Whic
Kevin Wolf writes:
> Am 09.10.2021 um 14:09 hat Markus Armbruster geschrieben:
>> The next commit will add feature flags to enum members. There's a
>> problem, though: query-qmp-schema shows an enum type's members as an
>> array of member names (SchemaInfoEnum member @values). If it showed
>> a
On Thu, Oct 21, 2021 at 09:17:57AM +0200, David Hildenbrand wrote:
> I know, whenever someone proposes a way to tackle part of a challenging
> problem, everybody discovers their hopes and dreams and suddenly you
> have to go all the way to solve the complete problem. The end result is
> that there
Le 21/10/2021 à 09:25, Thomas Huth a écrit :
On 21/10/2021 08.48, Christophe Leroy wrote:
Le 20/10/2021 à 15:16, Christophe Leroy a écrit :
Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
On 10/20/21 13:42, BALATON Zoltan wrote:
On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
On
This bug tracker is not used anymore. Please open new tickets here:
https://gitlab.com/qemu-project/qemu/-/issues
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
On Thu, Oct 21, 2021 at 3:03 PM Eugenio Perez Martin
wrote:
>
> On Thu, Oct 21, 2021 at 4:34 AM Jason Wang wrote:
> >
> > On Wed, Oct 20, 2021 at 8:07 PM Eugenio Perez Martin
> > wrote:
> > >
> > > On Wed, Oct 20, 2021 at 11:01 AM Jason Wang wrote:
> > > >
> > > > On Wed, Oct 20, 2021 at 3:54 P
Am 20.10.2021 um 20:02 hat Markus Armbruster geschrieben:
> The error message claims the parameter is invalid:
>
> $ qemu-system-x86_64 -object qom-type=nonexistent
> qemu-system-x86_64: -object qom-type=nonexistent: Invalid parameter
> 'nonexistent'
>
> What's wrong is actually the *val
On 10/21/21 7:05 AM, Markus Armbruster wrote:
Stefan Reiter writes:
It is possible to specify more than one VNC server on the command line,
either with an explicit ID or the auto-generated ones à la "default",
"vnc2", "vnc3", ...
It is not possible to change the password on one of these extra
On Wed, 20 Oct 2021 09:41:10 +0800
Bin Meng wrote:
> Using memory_region_init_ram(), which can't possibly handle vhost-user,
> and can't work as expected with '-numa node,memdev' options.
>
> Use MachineState::ram instead of manually initializing RAM memory
> region, as well as by providing Mach
On Wed, 20 Oct 2021 09:41:08 +0800
Bin Meng wrote:
> Using memory_region_init_ram(), which can't possibly handle vhost-user,
> and can't work as expected with '-numa node,memdev' options.
>
> Use MachineState::ram instead of manually initializing RAM memory
> region, as well as by providing Mach
On 10/14/21 10:09, Pierre Morel wrote:
On 10/13/21 11:11, Thomas Huth wrote:
On 13/10/2021 09.55, Pierre Morel wrote:
On 10/13/21 09:25, Thomas Huth wrote:
On 16/09/2021 15.50, Pierre Morel wrote:
When the host supports the CPU topology facility, the PTF
instruction with function code
On Wed, 20 Oct 2021 09:41:07 +0800
Bin Meng wrote:
> Using memory_region_init_ram(), which can't possibly handle vhost-user,
> and can't work as expected with '-numa node,memdev' options.
>
> Use MachineState::ram instead of manually initializing RAM memory
> region, as well as by providing Mach
Kevin Wolf writes:
> Am 09.10.2021 um 14:09 hat Markus Armbruster geschrieben:
>> This is quite similar to commit 84ab008687 "qapi: Add feature flags to
>> struct members", only for enums instead of structs.
>>
>> Special feature flag 'deprecated' is silently ignored there. This is
>> okay only
On 29/09/2021 16:43, Laurent Vivier wrote:
As the guest OS is paused, we will never receive the unplug event
from the kernel and the migration cannot continue.
The first patch is optional, it provides the error message to display
to migration_cancel() rather than to have to call migrate_set_erro
On Mon, Oct 18, 2021 at 10:40 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 82 +--
> 1 file changed, 33 insertions(+), 49 deletions(-)
>
Reviewed-by: Bin Meng
On Mon, Oct 18, 2021 at 10:40 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 55 +--
> 1 file changed, 11 insertions(+), 44 deletions(-)
>
Reviewed-by: Bin Meng
On Mon, Oct 18, 2021 at 10:40 AM Alistair Francis
wrote:
>
> From: Alistair Francis
>
This one needs some commit messages as it consolidates two functions
into one which is not straight forward.
> Signed-off-by: Alistair Francis
> ---
> hw/intc/sifive_plic.c | 109 +---
On 10/20/21 7:27 PM, Jean-Philippe Brucker wrote:
> Create empty data files and allow updates for the upcoming VIOT tests.
>
> Signed-off-by: Jean-Philippe Brucker
Reviewed-by: Eric Auger
Eric
> ---
> tests/qtest/bios-tables-test-allowed-diff.h | 3 +++
> tests/data/acpi/q35/DSDT.viot
Hi Jean,
On 10/20/21 7:27 PM, Jean-Philippe Brucker wrote:
> Add two test cases for VIOT, one on the q35 machine and the other on
> virt. To test complex topologies the q35 test has two PCIe buses that
> bypass the IOMMU (and are therefore not described by VIOT), and two
> buses that are translate
Hi Jean,
On 10/20/21 7:27 PM, Jean-Philippe Brucker wrote:
> To generate the IOMMU ACPI table, acpi-build.c can use base QEMU types
> instead of a special IommuType value.
>
> Signed-off-by: Jean-Philippe Brucker
Reviewed-by: Eric Auger
Looks good to me
Thanks
Eric
> ---
> include/hw/i386/x
On 10/20/21 7:27 PM, Jean-Philippe Brucker wrote:
> We're about to support a third vIOMMU for x86, virtio-iommu which
> doesn't inherit X86IOMMUState. Move the IOMMU singleton into
> PCMachineState, so it can be shared between all three vIOMMUs.
>
> The x86_iommu_get_default() helper is still ne
Hi Jean,
On 10/20/21 7:27 PM, Jean-Philippe Brucker wrote:
> Add two test cases for VIOT, one on the q35 machine and the other on
> virt. To test complex topologies the q35 test has two PCIe buses that
> bypass the IOMMU (and are therefore not described by VIOT), and two
> buses that are translate
On Wed, Oct 20, 2021 at 08:53:00PM +0800, wangyanan (Y) wrote:
> > > > > > Table 5-149 of 6.2 spec (6.2 May 2017) tells the rev shall be 1. Or
> > > > > > is
> > > > > > it an erratum somewhere I did miss?
> > > > > Yes, the revision in 6.2 spec is 1. And it's 2 in spec 6.3.
> > > > > So just to b
On 2021/10/21 17:08, Andrew Jones wrote:
On Wed, Oct 20, 2021 at 08:53:00PM +0800, wangyanan (Y) wrote:
Table 5-149 of 6.2 spec (6.2 May 2017) tells the rev shall be 1. Or is
it an erratum somewhere I did miss?
Yes, the revision in 6.2 spec is 1. And it's 2 in spec 6.3.
So just to be sure, sh
Stefan Reiter writes:
> On 10/21/21 7:05 AM, Markus Armbruster wrote:
>> Stefan Reiter writes:
>>
>>> It is possible to specify more than one VNC server on the command line,
>>> either with an explicit ID or the auto-generated ones à la "default",
>>> "vnc2", "vnc3", ...
>>>
>>> It is not possi
Eric Blake writes:
> On Sat, Oct 09, 2021 at 02:09:43PM +0200, Markus Armbruster wrote:
>> This copies the code implementing the policy from qapi/qmp-dispatch.c
>> to qapi/qobject-input-visitor.c. Tolerable, but if we acquire more
>> copes, we should look into factoring them out.
>
> copies
Fix
Kevin Wolf writes:
> Am 11.10.2021 um 20:58 hat Eric Blake geschrieben:
>> On Sat, Oct 09, 2021 at 02:09:44PM +0200, Markus Armbruster wrote:
>> > Several moons ago, Vladimir posted
>> >
>> > Subject: [PATCH v2 3/3] qapi: deprecate drive-backup
>> > Date: Wed, 5 May 2021 16:58:03 +0300
Hello!
I'm regularly building debian-installer packages for Debian's unofficial ports
which includes sh4 among others. The kernel package and therefore the installer
package contains a kernel for the SH7751R machine which is emulated by QEMU when
choosing the "r2d" type.
Unfortunately, I have not
It is possible to specify more than one VNC server on the command line,
either with an explicit ID or the auto-generated ones à la "default",
"vnc2", "vnc3", ...
It is not possible to change the password on one of these extra VNC
displays though. Fix this by adding a "display" parameter to the
"se
Adds support for the "-xV" parameter type, where "-x" denotes a flag
name and the "V" suffix indicates that this flag is supposed to take an
arbitrary string parameter.
These parameters are always optional, the entry in the qdict will be
omitted if the flag is not given.
Signed-off-by: Stefan Rei
Since the removal of the generic 'qmp_change' command, one can no longer replace
the 'default' VNC display listen address at runtime (AFAIK). For our users who
need to set up a secondary VNC access port, this means configuring a second VNC
display (in addition to our standard one for web-access), b
VNC only supports 'keep' here, enforce this via a seperate
SetPasswordActionVnc enum and mark the option 'deprecated' (as it is
useless with only one value possible).
Also add a deprecation note to docs.
Suggested-by: Eric Blake
Reviewed-by: Markus Armbruster
Signed-off-by: Stefan Reiter
---
'protocol' and 'connected' are better suited as enums than as strings,
make use of that. No functional change intended.
Suggested-by: Markus Armbruster
Reviewed-by: Markus Armbruster
Signed-off-by: Stefan Reiter
---
monitor/hmp-cmds.c | 29 +++--
monitor/qmp-cmds.c | 37
With new option qemu-img compare will not stop at first mismatch, but
instead calculate statistics: how many clusters with different data,
how many clusters with equal data, how many clusters were unallocated
but become data and so on.
We compare images chunk by chunk. Chunk size depends on what
b
Allow compare only top images of backing chains. This is useful to
compare images with same backing file or to compare incremental images
from the chain of incremental backups with "--stat" option.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
docs/tools/qemu-img.rst | 9 -
qemu-img.c
Hi all!
v2: allow using --shallow without --stat
Recently we faced the following task:
Customer comes and say: incremental backup images are too fat. Does you
incremental backup works correct?
What to answer? We should check something. At least check that
incremental images doesn't store same d
Let's detect block-size automatically if not specified by user:
If both files define cluster-size, use minimum to be more precise.
If both files don't specify cluster-size, use default of 64K
If only one file specify cluster-size, just use it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Test new feature qemu-img compare --stat.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
.../qemu-iotests/tests/qemu-img-compare-stat | 88 +++
.../tests/qemu-img-compare-stat.out | 106 ++
2 files changed, 194 insertions(+)
create mode 100755 tests/qemu
The next commit needs to access compat policy from the generic visitor
core. Move it there from qobject input and output visitor.
Signed-off-by: Markus Armbruster
Reviewed-by: Eric Blake
---
include/qapi/qobject-input-visitor.h | 4
include/qapi/qobject-output-visitor.h | 4
inclu
PATCH 1+2 add feature flags to enum members. Awkward due to an
introspection design mistake; see PATCH 1 for details.
PATCH 3+4 implement policy deprecated-input={reject,crash} for enum
values.
Policy deprecated-output=hide is not implemented, because we can't
hide a value without hiding the ent
This copies the code implementing the policy from qapi/qmp-dispatch.c
to qapi/qobject-input-visitor.c. Tolerable, but if we acquire more
copies, we should look into factoring them out.
Signed-off-by: Markus Armbruster
Reviewed-by: Eric Blake
Tested-by: Peter Krempa
Acked-by: Peter Krempa
---
Several moons ago, Vladimir posted
Subject: [PATCH v2 3/3] qapi: deprecate drive-backup
Date: Wed, 5 May 2021 16:58:03 +0300
Message-Id: <20210505135803.67896-4-vsement...@virtuozzo.com>
https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg01394.html
with this
TODO: We a
This is quite similar to commit 84ab008687 "qapi: Add feature flags to
struct members", only for enums instead of structs.
Special feature flag 'deprecated' is silently ignored there. This is
okay only because it will be implemented shortly.
Signed-off-by: Markus Armbruster
Reviewed-by: Eric Bl
The next commit will add feature flags to enum members. There's a
problem, though: query-qmp-schema shows an enum type's members as an
array of member names (SchemaInfoEnum member @values). If it showed
an array of objects with a name member, we could simply add more
members to these objects. Si
Stefan Reiter writes:
> It is possible to specify more than one VNC server on the command line,
> either with an explicit ID or the auto-generated ones à la "default",
> "vnc2", "vnc3", ...
>
> It is not possible to change the password on one of these extra VNC
> displays though. Fix this by addi
NDNF writes:
> This patch adds helper functions to the drcov plugin.
> Which provide information about:
> - start_code.
> - end_code.
> - entry.
> - path to the executable binary.
>
> Signed-off-by: Ivanov Arkady
> ---
> include/qemu/qemu-plugin.h |5 +
> plugins/api.c
I'm done reviewing. David, care to have another look at the HMP part?
This series overrides one previous patchset:
https://lore.kernel.org/qemu-devel/20210818194217.110451-1-pet...@redhat.com/
I started from v1 because obviously it's completely different way of doing the
same thing, hence versioning upon it would be weird.
Patches 1-7 are majorly cleanups for curr
It's used in quite a few places of pci.c and also in the rest of the code base.
Define such a hook so that it doesn't need to be defined all over the places.
Signed-off-by: Peter Xu
---
hw/pci/pci.c | 14 --
include/hw/pci/pci.h | 7 ---
2 files changed, 8 insertions(+),
They're actually more commonly used than the helper without _under_bus, because
most callers do have the pci bus on hand. After exporting we can switch a lot
of the call sites to use these two helpers.
Signed-off-by: Peter Xu
---
hw/pci/pci.c | 10 +-
include/hw/pci/pci.h | 5 +
Replace all the call sites of existing pci_for_each_device*() where the bus
number is calculated from a PCIBus* already. It should avoid the lookup of the
PCIBus again.
Signed-off-by: Peter Xu
---
hw/i386/acpi-build.c | 5 ++---
hw/pci/pcie.c | 4 +---
hw/ppc/spapr_pci.c
The pci_bus_fn is similar to pci_bus_dev_fn that only takes a PCIBus* and an
opaque. The pci_bus_ret_fn is similar to pci_bus_fn but it allows to return a
void* pointer.
Use them where proper in pci.[ch], and to be used elsewhere.
Signed-off-by: Peter Xu
---
hw/pci/pci.c | 6 ++
i
With all the prepared infrastructures, we can easily add one helper now to loop
over all the existing PCI devices across the whole system.
Signed-off-by: Peter Xu
---
hw/pci/pci.c | 25 +
include/hw/pci/pci.h | 2 ++
2 files changed, 27 insertions(+)
diff --git
On Thu, Oct 21, 2021 at 06:42:59PM +0800, Peter Xu wrote:
> Scan the pci bus to make sure there's no vfio-pci device attached before
> vIOMMU
> is realized.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Peter Xu
> ---
> hw/i386/x86-iommu.c | 18 ++
> 1 file changed, 18 inser
Add a helper to loop over each root bus of the system, either the default root
bus or extended buses like pxb-pcie.
Signed-off-by: Peter Xu
---
hw/pci/pci.c | 26 ++
include/hw/pci/pci.h | 2 ++
2 files changed, 28 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pc
NDNF writes:
> This patch adds the ability to generate files in drcov format.
> Primary goal this script is to have coverage
> logfiles thatwork in Lighthouse.
>
> Signed-off-by: Ivanov Arkady
> ---
> contrib/plugins/Makefile |1
> contrib/plugins/drcov.c | 148
> +
There're three places that can be rewritten with the pci_for_each_root_bus()
helper that we just introduced. De-dup the code.
Signed-off-by: Peter Xu
---
hw/arm/virt-acpi-build.c | 31 +++
hw/i386/acpi-build.c | 38 ++
2 files
On 10.09.2021 17:41, Richard Henderson wrote:
On 9/10/21 3:46 PM, David Hildenbrand wrote:
On 10.09.21 15:34, Richard Henderson wrote:
On 9/10/21 1:15 PM, David Hildenbrand wrote:
On 07.09.21 13:30, Pavel Dovgalyuk wrote:
Watchpoint processing code restores vCPU state twice:
in tb_check_watch
On 21.10.21 12:42, Peter Xu wrote:
> They're actually more commonly used than the helper without _under_bus,
> because
> most callers do have the pci bus on hand. After exporting we can switch a lot
> of the call sites to use these two helpers.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c
On Thu, Oct 21, 2021 at 06:42:58PM +0800, Peter Xu wrote:
> With all the prepared infrastructures, we can easily add one helper now to
> loop
> over all the existing PCI devices across the whole system.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c | 25 +
> i
Scan the pci bus to make sure there's no vfio-pci device attached before vIOMMU
is realized.
Suggested-by: Igor Mammedov
Signed-off-by: Peter Xu
---
hw/i386/x86-iommu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 86ad03
On 21.10.21 12:42, Peter Xu wrote:
> The pci_bus_fn is similar to pci_bus_dev_fn that only takes a PCIBus* and an
> opaque. The pci_bus_ret_fn is similar to pci_bus_fn but it allows to return a
> void* pointer.
>
> Use them where proper in pci.[ch], and to be used elsewhere.
>
> Signed-off-by: P
On 21.10.21 12:42, Peter Xu wrote:
> It's used in quite a few places of pci.c and also in the rest of the code
> base.
> Define such a hook so that it doesn't need to be defined all over the places.
>
> Signed-off-by: Peter Xu
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 21.10.21 12:42, Peter Xu wrote:
> Add a helper to loop over each root bus of the system, either the default root
> bus or extended buses like pxb-pcie.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c | 26 ++
> include/hw/pci/pci.h | 2 ++
> 2 files changed,
On 21.10.21 12:42, Peter Xu wrote:
> Replace all the call sites of existing pci_for_each_device*() where the bus
> number is calculated from a PCIBus* already. It should avoid the lookup of
> the
> PCIBus again.
>
> Signed-off-by: Peter Xu
> ---
> hw/i386/acpi-build.c | 5 ++---
> hw/pc
On 21.10.21 12:42, Peter Xu wrote:
> There're three places that can be rewritten with the pci_for_each_root_bus()
> helper that we just introduced. De-dup the code.
>
> Signed-off-by: Peter Xu
> ---
> hw/arm/virt-acpi-build.c | 31 +++
> hw/i386/acpi-build.c | 38
Le 21/10/2021 à 01:09, Richard Henderson a écrit :
> On 10/19/21 2:48 AM, Frédéric Pétrot wrote:
>> Support for a 128-bit satp. This is a bit more involved than necessary
>> because we took the opportunity to increase the page size to 16kB, and
>> change the page table geometry, which makes the pag
Hi Peter,
On 10/21/21 12:42 PM, Peter Xu wrote:
> It's used in quite a few places of pci.c and also in the rest of the code
> base.
> Define such a hook so that it doesn't need to be defined all over the places.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c | 14 --
> inc
On 10/21/21 12:42 PM, Peter Xu wrote:
> They're actually more commonly used than the helper without _under_bus,
> because
> most callers do have the pci bus on hand. After exporting we can switch a lot
> of the call sites to use these two helpers.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/p
Hi Peter,
On 10/21/21 12:42 PM, Peter Xu wrote:
> Replace all the call sites of existing pci_for_each_device*() where the bus
> number is calculated from a PCIBus* already. It should avoid the lookup of
> the
> PCIBus again.
>
> Signed-off-by: Peter Xu
> ---
> hw/i386/acpi-build.c | 5 ++
On 10/21/21 12:42, Peter Xu wrote:
> It's used in quite a few places of pci.c and also in the rest of the code
> base.
> Define such a hook so that it doesn't need to be defined all over the places.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c | 14 --
> include/hw/pci/p
On 10/21/21 12:42 PM, Peter Xu wrote:
> The pci_bus_fn is similar to pci_bus_dev_fn that only takes a PCIBus* and an
> opaque. The pci_bus_ret_fn is similar to pci_bus_fn but it allows to return a
> void* pointer.
>
> Use them where proper in pci.[ch], and to be used elsewhere.
>
> Signed-off-b
On 10/21/21 12:42, Peter Xu wrote:
> They're actually more commonly used than the helper without _under_bus,
> because
> most callers do have the pci bus on hand. After exporting we can switch a lot
> of the call sites to use these two helpers.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c
On 10/21/21 12:42, Peter Xu wrote:
> The pci_bus_fn is similar to pci_bus_dev_fn that only takes a PCIBus* and an
> opaque. The pci_bus_ret_fn is similar to pci_bus_fn but it allows to return a
> void* pointer.
>
> Use them where proper in pci.[ch], and to be used elsewhere.
>
> Signed-off-by: P
Hello,
On Thu, 21 Oct 2021, John Paul Adrian Glaubitz wrote:
I'm regularly building debian-installer packages for Debian's unofficial ports
which includes sh4 among others. The kernel package and therefore the installer
package contains a kernel for the SH7751R machine which is emulated by QEMU
Hi Peter,
On 10/21/21 12:42 PM, Peter Xu wrote:
> Add a helper to loop over each root bus of the system, either the default root
> bus or extended buses like pxb-pcie.
>
> Signed-off-by: Peter Xu
> ---
> hw/pci/pci.c | 26 ++
> include/hw/pci/pci.h | 2 ++
> 2 fi
Hi Peter,
On 10/21/21 12:42 PM, Peter Xu wrote:
> There're three places that can be rewritten with the pci_for_each_root_bus()
> helper that we just introduced. De-dup the code.
>
> Signed-off-by: Peter Xu
Reviewed-by: Eric Auger
Eric
> ---
> hw/arm/virt-acpi-build.c | 31 +++-
Aaron Lindsay writes:
> On Oct 20 18:54, Alex Bennée wrote:
>> Have you got a test case you are using so I can try and replicate the
>> failure you are seeing? So far by inspection everything looks OK to me.
>
> I took some time today to put together a minimal(ish) reproducer using
> usermode.
Currently when I attach a debugger (lldb) to my qemu session all of the output
goes to the shell running qemu not to the debugger. Fixing this meant that I
needed to point the semi-hosting output to the gdb chardev. I started qemu
like this:
-s -S -semihosting-config target=auto,chardev=ch0 -
Hi Peter,
On 10/21/21 12:42 PM, Peter Xu wrote:
> Scan the pci bus to make sure there's no vfio-pci device attached before
> vIOMMU
> is realized.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Peter Xu
> ---
> hw/i386/x86-iommu.c | 18 ++
> 1 file changed, 18 insertions(+)
>
Hi Zoltan!
On 10/21/21 14:12, BALATON Zoltan wrote:
> Adding -d in_asm shows it seems to loop early in the kernel but not sure
> where.
> Maybe try to compare addresses with System.map to find out where it's getting
> stuck (but System.map was not included in your installer image).
Here is the S
1 - 100 of 332 matches
Mail list logo
