** Changed in: qemu
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1877706
Title:
[Feature request] qemu does not support for Octeon MIPS64 on X86
Status in QE
Cédric Le Goater writes:
> On 5/27/20 3:36 PM, Markus Armbruster wrote:
>> Cédric Le Goater writes:
>>
>>> The number of MACs supported by an Aspeed SoC is defined by "macs_num"
>>> under the SoC model, that is two for the AST2400 and AST2500 and four
>>> for the AST2600. The model initializes
On 27.05.2020 17:53, Philippe Mathieu-Daudé wrote:
On 5/27/20 12:31 PM, Pavel Dovgalyuk wrote:
This patch adds a test for record/replay an execution of x86_64 machine.
Execution scenario includes simple kernel boot, which allows testing
basic hardware interaction in RR mode.
Signed-off-by: Pa
Hi,
> > (1) we loose a bit of memory.
> it's probably not a big enough to care about, we do similar ovarlay
> mapping on pc/q35
> at the beginning of RAM
Yes, shouldn't be too much.
> > (2) we loose a gigabyte page.
> I'm not sure waht exactly we loose in thi
Hi,
> But why use 2G split instead of 3G? There's only very little MMIO and
> no PCI hole (including no huge MMCONFIG BAR) on microvm.
Yes, we can go for 3G, we are indeed not short on address space ;)
take care,
Gerd
On 27.05.2020 18:20, Alex Bennée wrote:
Pavel Dovgalyuk writes:
This patch adds a base for testing kernel boot recording and replaying.
Each test has the phase of recording and phase of replaying.
Virtual machines just boot the kernel and do not interact with
the network.
Structure and image
On Thu, May 21, 2020 at 09:39:44PM +0200, BALATON Zoltan wrote:
> Second try of clean ups and changes to hopefully improve 2D engine
> performance and fix a security bug in it. This one actually works with
> AmigaOS handling overlapping blits, fixes the overflow checks and adds
> Reviewed-by tags.
> -Original Message-
> From: Roman Kagan
> Sent: 27 May 2020 13:45
> To: qemu-devel@nongnu.org
> Cc: Kevin Wolf ; xen-de...@lists.xenproject.org; Gerd
> Hoffmann ;
> Daniel P. Berrangé ; Paolo Bonzini
> ; Anthony Perard
> ; Laurent Vivier ; Max Reitz
> ; qemu-
> bl...@nongnu.org; Philip
On Wed, 27 May 2020 at 12:44, Cédric Le Goater wrote:
>
> The number of MACs supported by an Aspeed SoC is defined by "macs_num"
> under the SoC model, that is two for the AST2400 and AST2500 and four
> for the AST2600. The model initializes the maximum number of supported
> MACs but the number of
On 27.05.2020 19:20, Alex Bennée wrote:
Alex Bennée writes:
Pavel Dovgalyuk writes:
This patch adds a test for record/replay an execution of x86_64 machine.
Execution scenario includes simple kernel boot, which allows testing
basic hardware interaction in RR mode.
Signed-off-by: Pavel Do
> > > This is my understanding of the protocol as well, when the device is
> > > running, pending_bytes might drop to zero if no internal state has
> > > changed and may be non-zero on the next iteration due to device
> > > activity. When the device is not running, pending_bytes reporting zero
> >
When building with clang version 10.0.0-4ubuntu1, we get:
CC lm32-softmmu/fpu/softfloat.o
fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did
you mean logical negation? [-Werror,-Wbool-operation]
absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven );
Pavel Dovgalyuk writes:
> On 27.05.2020 18:20, Alex Bennée wrote:
>> Pavel Dovgalyuk writes:
>>
>>> This patch adds a base for testing kernel boot recording and replaying.
>>> Each test has the phase of recording and phase of replaying.
>>> Virtual machines just boot the kernel and do not inte
Thomas Huth writes:
> On 27/05/2020 18.36, Alex Bennée wrote:
>>
>> Thomas Huth writes:
>>
>>> On 27/05/2020 16.44, Laurent Vivier wrote:
Le 25/05/2020 à 15:18, Thomas Huth a écrit :
> From: Alex Bennée
>
> Newer clangs rightly spot that you can never exceed the full addres
casmac <1482995...@qq.com> writes:
> Hi,
> Thank you for forwarding my question to developers and sharing
> the C6x implementation.
> Perhaps I should follow up with another problem I encountered.
> The senerio is the emulator keeps running eventhough the program it
> emulates has alre
On 5/28/20 9:12 AM, Pavel Dovgalyuk wrote:
>
> On 27.05.2020 17:53, Philippe Mathieu-Daudé wrote:
>> On 5/27/20 12:31 PM, Pavel Dovgalyuk wrote:
>>> This patch adds a test for record/replay an execution of x86_64 machine.
>>> Execution scenario includes simple kernel boot, which allows testing
>>>
Thomas Huth writes:
> Currently all pipelines of the gitlab CI are failing, except for the
> "build-user" pipeline. There is an issue with the default container
> image (likely Debian stable) where they imported something bad in one
> of the system headers:
>
> /usr/include/linux/swab.h: In fu
Thomas Huth writes:
> Some people might want to run the gitlab CI pipelines in an environment
> where multiple CPUs are available to the runners, so let's rather get
> the number for "-j" from the "nproc" program (increased by 1 to compensate
> for jobs that wait for I/O) instead of hard-coding
When building with clang version 10.0.0-4ubuntu1, we get:
CC lm32-softmmu/fpu/softfloat.o
fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did
you mean logical negation? [-Werror,-Wbool-operation]
absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEv
Chris Hoy writes:
> Hello all,
>
> I am proud to see that I have my barebones implementation of qemu finally
> working. After starting earlier this year, I have slowly made progress to
> fully integrate my kernel hardware into a gpu-passthrough vm. I went
> through many settings and templates f
On Wed, May 27, 2020 at 11:38:17AM +0100, Daniel P. Berrangé wrote:
> On Wed, May 27, 2020 at 11:29:23AM +0100, Stefan Hajnoczi wrote:
> > Automatically size the number of virtio-scsi-pci, vhost-scsi-pci, and
> > vhost-user-scsi-pci request virtqueues to match the number of vCPUs.
> > Other transpo
On 28/05/2020 10.48, Philippe Mathieu-Daudé wrote:
> When building with clang version 10.0.0-4ubuntu1, we get:
>
> CC lm32-softmmu/fpu/softfloat.o
> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression;
> did you mean logical negation? [-Werror,-Wbool-operation]
>
On 5/28/20 10:57 AM, Thomas Huth wrote:
> On 28/05/2020 10.48, Philippe Mathieu-Daudé wrote:
>> When building with clang version 10.0.0-4ubuntu1, we get:
>>
>> CC lm32-softmmu/fpu/softfloat.o
>> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression;
>> did you mean lo
Changes is v4:
- Update the "[PATCH v4 2/2] vhost-user-blk: delay
vhost_user_blk_disconnect" patch based on Raphael's comment and Li
Feng previous commit:
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg02255.html
Don't change the vhost_user_blk_device_realize() function. Update th
During testing of the vhost-user-blk reconnect functionality the qemu
SIGSEGV was triggered:
start qemu as:
x86_64-softmmu/qemu-system-x86_64 -m 1024M -M q35 \
-object
memory-backend-file,id=ram-node0,size=1024M,mem-path=/dev/shm/qemu,share=on \
-numa node,cpus=0,memdev=ram-node0 \
-cha
A socket write during vhost-user communication may trigger a disconnect
event, calling vhost_user_blk_disconnect() and clearing all the
vhost_dev structures holding data that vhost-user functions expect to
remain valid to roll back initialization correctly. Delay the cleanup to
keep vhost_dev struc
On 28/05/2020 10.41, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> Some people might want to run the gitlab CI pipelines in an environment
>> where multiple CPUs are available to the runners, so let's rather get
>> the number for "-j" from the "nproc" program (increased by 1 to compensate
>> f
Hi,
Some devices use timers (QEMUTimer) to emulate hardware precise timings.
i.e. with a flash device, the guest orders erasing it, the physical
erasure takes some time - let say 200ms - and upon completion a bit is
set in a register, and an interruption is eventually raised.
When not multi-taskin
On Thu, 28 May 2020, Gerd Hoffmann wrote:
On Wed, May 27, 2020 at 09:44:54PM +0200, BALATON Zoltan wrote:
Hello,
I've seen a case when QEMU hangs with a passed through USB device. This is
with -device usb-ehci and pass through with usb-host. This works until the
attached USB device reboots (so
07.05.2020 17:08, Eric Blake wrote:
On 5/7/20 3:47 AM, Vladimir Sementsov-Ogievskiy wrote:
The function has the only user: bdrv_co_block_status(). Inline it to
s/the only/only one/
simplify reviewing of the following patches, which will finally drop
unallocated_blocks_are_zero field too.
Si
Le 02/05/2020 à 18:12, Jonathan Marler a écrit :
> Fixes: https://bugs.launchpad.net/bugs/1876373
>
> This code path in mmap occurs when a page size is decreased with mremap.
> When a section of pages is shrunk, qemu calls mmap_reserve on the pages that
> were released. However, it has the dif
Patch sent:
https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg07861.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1881004
Title:
fpu/softfloat.c: error: bitwise negation of a boolean ex
Le 02/05/2020 à 18:12, Jonathan Marler a écrit :
> Fixes: https://bugs.launchpad.net/bugs/1876373
>
> This code path in mmap occurs when a page size is decreased with mremap.
> When a section of pages is shrunk, qemu calls mmap_reserve on the pages that
> were released. However, it has the dif
The function has only one user: bdrv_co_block_status(). Inline it to
simplify reviewing of the following patches, which will finally drop
unallocated_blocks_are_zero field too.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
---
include/block/block.h | 1 -
block.c
qemu-img convert wants to distinguish ZERO which comes from short
backing files. unallocated_blocks_are_zero field of bdi is unrelated:
space after EOF is always considered to be zero anyway. So, just make
post_backing_zero true in case of short backing file.
Signed-off-by: Vladimir Sementsov-Ogie
Hi all,
Just wonderring if there is any reason not to be able to defer
qemu_semihosting_connect_chardevs a little more to be able to specify
chardev=serial0?
Like:
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 6390cf0..9fa1553 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -4333,8 +4333,6 @@
It's false by default, no needs to set it. We are going to drop this
variable at all, so drop it now here, it doesn't hurt.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
---
block/crypto.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/crypto.c b/block/crypto.c
i
In case when get_image_offset() returns -1, we do zero out the
corresponding chunk of qiov. So, this should be reported as ZERO.
Note that this changes visible output of "qemu-img map --output=json"
and "qemu-io -c map" commands. For qemu-img map, the change is obvious:
we just mark as zero what i
This is first step to block-status refactoring, and solves most simple
problem mentioned in my investigation of block-status described in
the thread "backing chain & block status & filters":
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg04706.html
The whole series is reviewed, let's p
Currently this field only set by qed and qcow2. But in fact, all
backing-supporting formats (parallels, qcow, qcow2, qed, vmdk) share
these semantics: on unallocated blocks, if there is no backing file they
just memset the buffer with zeroes.
So, document this behavior for .supports_backing and dr
We set bdi->unallocated_blocks_are_zero = iscsilun->lbprz, but
iscsi_co_block_status doesn't return 0 in case of iscsilun->lbprz, it
returns ZERO when appropriate. So actually unallocated_blocks_are_zero
is useless (it doesn't affect the only user of the field:
bdrv_co_block_status()). Drop it now.
In case of !VDI_IS_ALLOCATED[], we do zero out the corresponding chunk
of qiov. So, this should be reported as ZERO.
Note that this changes visible output of "qemu-img map --output=json"
and "qemu-io -c map" commands. For qemu-img map, the change is obvious:
we just mark as zero what is really zer
raw_co_block_status() in block/file-posix.c never returns 0, so
unallocated_blocks_are_zero is useless (it doesn't affect the only user
of the field: bdrv_co_block_status()). Drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
---
block/file-posix.c | 3 ---
1 file chan
vhdx doesn't have .bdrv_co_block_status handler, so DATA|ALLOCATED is
always assumed for it in bdrv_co_block_status().
unallocated_blocks_are_zero is useless (it doesn't affect the only user
of the field: bdrv_co_block_status()), drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: E
From: Eric Blake
The other four drivers that support backing files (qcow, qcow2,
parallels, vmdk) all rely on the block layer to populate zeroes when
reading beyond EOF of a short backing file. We can simplify the qed
code by doing likewise.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Seme
Hi ,
Thanks for the hint.
I have been looking for how QEMU determine the target program terminates by
checking the host implementation (eg i386). I thought the target program
termination is connected to the initial FP pushed to stack, I am not sure this
is how QEMU does. Could you be mor
> On 28 May 2020, at 11:26, Philippe Mathieu-Daudé wrote:
>
> Hi,
>
> Some devices use timers (QEMUTimer) to emulate hardware precise timings.
> i.e. with a flash device, the guest orders erasing it, the physical
> erasure takes some time - let say 200ms - and upon completion a bit is
> set i
Le 19/05/2020 à 21:44, Richard Henderson a écrit :
> The subject of AT_SYSINFO came up on launchpad recently.
>
> There is definite room for improvement in all of this:
>
> (1) We could build the vdso binary into qemu instead of really
> loading it from the file system. This would obviate th
On Tue, 19 May 2020 at 20:45, Richard Henderson
wrote:
> Makefile | 4 +-
> linux-user/elfload.c | 203 +-
> pc-bios/Makefile | 5 +
> pc-bios/vdso-linux-x64.S | 115 +
> pc-bios/vdso-linux-x64.ld | 81 ++
Hi Peter,
the following changes since commit 06539ebc76b8625587aa78d646a9d8d5fddf84f3:
Merge remote-tracking branch
'remotes/philmd-gitlab/tags/mips-hw-next-20200526' into staging (2020-05-26
20:25:06 +0100)
are available in the Git repository at:
https://gitlab.com/huth/qemu.git tags/p
We have a dedicated folder for the gitlab-ci - so there is no need
to clutter the top directory with these .yml files.
Message-Id: <20200525131823.715-5-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
Signed-off-by: Thomas Huth
---
.gitlab-ci-edk2.yml => .gitlab-
From: Alex Bennée
Newer clangs rightly spot that you can never exceed the full address
space of 64 bit hosts with:
linux-user/elfload.c:2076:41: error: result of comparison 'unsigned
long' > 18446744073709551615 is always false
[-Werror,-Wtautological-type-limit-compare]
4685 if
From: Cleber Rosa
At this point it seems that all jobs depend on those steps, with
maybe the EDK2 jobs as exceptions.
The jobs that will be added later will not want those scripts to be
run, so let's move these steps to the appropriate jobs, while
still trying to avoid repetition.
Signed-off-by
Some people might want to run the gitlab CI pipelines in an environment
where multiple CPUs are available to the runners, so let's rather get
the number for "-j" from the "nproc" program (increased by 1 to compensate
for jobs that wait for I/O) instead of hard-coding it.
Message-Id: <2020052513182
Initially, I was the only one who was using Gitlab while most developers
had their git trees still on other systems, but that has changed nowadays.
There is now much more interest in the Gitlab-CI today, so it would be
good to have more than only one maintainer / reviewer for the gitlab-ci.yml
file
From: Philippe Mathieu-Daudé
QEMU does not use flex/bison packages.
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20200515163029.12917-4-phi...@redhat.com>
Message-Id: <20200525131823.715-3-th...@redhat.com>
Reviewed-by: Alex Bennée
Signed-off-by: Thomas Huth
---
.gitlab-ci.yml | 2 +-
bdrv_co_block_status_above has several design problems with handling
short backing files:
1. With want_zeros=true, it may return ret with BDRV_BLOCK_ZERO but
without BDRV_BLOCK_ALLOCATED flag, when actually short backing file
which produces these after-EOF zeros is inside requested backing
sequenc
Thanks to Eric, the whole series is reviewed now!
v4:
01: fix grammar in comment, add Eric's r-b
02-05: add Eric's r-b
Hi all!
These series are here to address the following problem:
block-status-above functions may consider space after EOF of
intermediate backing files as unallocated, which is
bdrv_is_allocated_above wrongly handles short backing files: it reports
after-EOF space as UNALLOCATED which is wrong, as on read the data is
generated on the level of short backing file (if all overlays has
unallocated area at that place).
Reusing bdrv_common_block_status_above fixes the issue an
Currently all pipelines of the gitlab CI are failing, except for the
"build-user" pipeline. There is an issue with the default container
image (likely Debian stable) where they imported something bad in one
of the system headers:
/usr/include/linux/swab.h: In function '__swab':
/builds/huth/qemu
On 5/27/20 1:36 PM, Daniel P. Berrangé wrote:
> On Tue, May 19, 2020 at 08:20:23PM +0200, Philippe Mathieu-Daudé wrote:
>> Example of use to dump:
>>
>> $ qemu-system-x86_64 -S \
>> -object tls-cipher-suites,id=mysuite,priority=@SYSTEM,verbose=yes
>> Cipher suites for @SYSTEM:
>> - TLS_AE
In order to reuse bdrv_common_block_status_above in
bdrv_is_allocated_above, let's support include_base parameter.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Kevin Wolf
Reviewed-by: Eric Blake
---
block/io.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(
We are going to reuse bdrv_common_block_status_above in
bdrv_is_allocated_above. bdrv_is_allocated_above may be called with
include_base == false and still bs == base (for ex. from img_rebase()).
So, support this corner case.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Kevin Wolf
R
These cases are fixed by previous patches around block_status and
is_allocated.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
---
tests/qemu-iotests/274 | 20
tests/qemu-iotests/274.out | 65 ++
2 files changed, 85 inser
On Wed, 27 May 2020 at 06:38, David Gibson wrote:
>
> The following changes since commit ddc760832fa8cf5e93b9d9e6e854a5114ac63510:
>
> Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-05-26' into
> staging (2020-05-26 14:05:53 +0100)
>
> are available in the Git repository at:
>
>
Le 23/05/2020 à 15:24, cheng...@emindsoft.com.cn a écrit :
> From: Chen Gang
>
> Another DRM_IOCTL_* commands will be done later.
>
> Signed-off-by: Chen Gang
> ---
> configure | 18 +++
> linux-user/ioctls.h| 3 ++
> linux-user/syscall.c | 61 ++
Le 28/05/2020 à 12:08, Peter Maydell a écrit :
> On Tue, 19 May 2020 at 20:45, Richard Henderson
> wrote:
>> Makefile | 4 +-
>> linux-user/elfload.c | 203 +-
>> pc-bios/Makefile | 5 +
>> pc-bios/vdso-linux-x64.S | 115
On Thu, 28 May 2020 08:26:42 +0300
Jon Doron wrote:
> On 22/05/2020, Igor Mammedow wrote:
> >On Thu, 21 May 2020 18:02:07 +0200
> >Paolo Bonzini wrote:
> >
> >> On 13/05/20 17:34, Igor Mammedov wrote:
> >> > I'd rather avoid using random IRQ numbers (considering we are
> >> > dealing with bl
On Thu, 28 May 2020 01:24:42 +
"Verma, Vishal L" wrote:
> On Thu, 2020-05-21 at 17:16 +0200, Igor Mammedov wrote:
>
> Hi Igor, Thanks for the review.
>
> [..]
> > >
> > > @@ -2429,6 +2430,25 @@ build_srat(GArray *table_data, BIOSLinker *linker,
> > > MachineState *machine)
> > >
On 28/05/20 11:52, Christophe de Dinechin wrote:
>
> Since we run the fuzzer with the QTest accelerator, my first idea was to
> check for 'if (qtest_enabled())' in the timer code, and directly expire
> a timer instead of scheduling it. This way we can test reproducers.
> However various tests requ
Le 25/05/2020 à 09:59, Andreas Schwab a écrit :
> Signed-off-by: Andreas Schwab
> ---
> linux-user/generic/fcntl.h | 4
> linux-user/syscall.c | 6 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/linux-user/generic/fcntl.h b/linux-user/generic/fcntl.h
> index 9f727d4df2..c
Le 25/05/2020 à 09:59, Andreas Schwab a écrit :
> Signed-off-by: Andreas Schwab
> ---
> linux-user/generic/fcntl.h | 4
> linux-user/syscall.c | 6 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/linux-user/generic/fcntl.h b/linux-user/generic/fcntl.h
> index 9f727d4df2..c
On 28/05/2020, Igor Mammedov wrote:
On Thu, 28 May 2020 08:26:42 +0300
Jon Doron wrote:
On 22/05/2020, Igor Mammedow wrote:
>On Thu, 21 May 2020 18:02:07 +0200
>Paolo Bonzini wrote:
>
>> On 13/05/20 17:34, Igor Mammedov wrote:
>> > I'd rather avoid using random IRQ numbers (considering we are
stm32f405_soc_initfn() creates six such devices, but
stm32f405_soc_realize() realizes only one. Affects machine
netduinoplus2.
In theory, a device becomes real only on realize. In practice, the
transition from unreal to real is a fuzzy one. The work to make a
device real can be spread between r
This fixes a bunch of bugs I ran into while reworking how qdevs plug
into buses.
I instrumented the code a bit to flush out instances of bug patterns.
I posted these hacks separately as '[PATCH not-for-merge 0/5]
Instrumentation for "Fixes around device realization"'. PATCH 2/5
since became "[PAT
This would have caught some of the bugs I just fixed.
Signed-off-by: Markus Armbruster
Reviewed-by: Mark Cave-Ayland
---
hw/core/qdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 9e5538aeae..b5b42b2616 100644
--- a/hw/core/qdev.c
+++ b/hw/core/q
xlnx_dp_init() creates these two devices, but they're never realized.
Affects machine xlnx-zcu102.
In theory, a device becomes real only on realize. In practice, the
transition from unreal to real is a fuzzy one. The work to make a
device real can be spread between realize methods (fine),
instan
These devices are optional, and enabled by property "enable-bitband".
armv7m_instance_init() creates them unconditionally, because the
property has not been set then. armv7m_realize() realizes them only
when the property is true. Works, although it leaves unrealized
devices hanging around in the
object_property_set_bool(OBJECT(dev), true, "realized", ...) right
after qdev_init_nofail(dev) does nothing, because qdev_init_nofail()
already realizes. Drop.
Cc: BALATON Zoltan
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: BALATON Zoltan
Reviewed-by: Thom
pxa2xx_mmci_init() creates a "pxa2xx-mmci" device, but neglects to
realize it. Affects machines akita, borzoi, connex, mainstone, spitz,
terrier, tosa, verdex, and z2.
In theory, a device becomes real only on realize. In practice, the
transition from unreal to real is a fuzzy one. The work to m
Cc: Cédric Le Goater
Cc: David Gibson
Cc: qemu-...@nongnu.org
Signed-off-by: Markus Armbruster
Acked-by: David Gibson
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3690f313c3..3bd5c613f5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1213
mac_via_realize() creates a "mos6522-q800-via1" and a
"mos6522-q800-via2" device, but neglects to realize them. Affects
machine q800.
In theory, a device becomes real only on realize. In practice, the
transition from unreal to real is a fuzzy one. The work to make a
device real can be spread be
sm501_init() and ati_vga_realize() create an "i2c-ddc" device, but
neglect to realize it. Affects machines sam460ex, shix, r2d, and
fulong2e.
In theory, a device becomes real only on realize. In practice, the
transition from unreal to real is a fuzzy one. The work to make a
device real can be s
pnv_init() creates "power10_v1.0-pnv-chip", "power8_v2.0-pnv-chip",
"power8e_v2.1-pnv-chip", "power8nvl_v1.0-pnv-chip", or
"power9_v2.0-pnv-chip" sysbus devices in a way that leaves them
unplugged.
pnv_chip_power9_instance_init() creates a "pnv-xive" sysbus device in
a way that leaves it unplugged
The number of stacks is controlled by property "num-stacks".
pnv_pec_instance_init() creates the maximum supported number, because
the property has not been set then. pnv_pec_realize() realizes only
the wanted number. Works, although it can leave unrealized devices
hanging around in the QOM compo
This would have caught some of the bugs I just fixed.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
---
hw/core/qdev.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index b5b42b2616..a68ba674db 100644
--- a/hw/core/q
From: Cédric Le Goater
The number of MACs supported by an Aspeed SoC is defined by "macs_num"
under the SoC model, that is two for the AST2400 and AST2500 and four
for the AST2600. The model initializes the maximum number of supported
MACs but the number of realized devices is capped by the numbe
The devices we plug into the macio-bus are all sysbus devices
(DeviceClass member bus_type is TYPE_SYSTEM_BUS), but macio-bus does
not derive from TYPE_SYSTEM_BUS. Fix that.
"info qtree" now shows the devices' mmio ranges, as it should
Cc: Mark Cave-Ayland
Cc: David Gibson
Cc: qemu-...@nongnu.
macio_oldworld_init() creates a "macio-nvram", sysbus device, but
neglects to but it on a bus.
Put it on the macio bus. Affects machine g3beige. Visible in "info
qtree":
bus: macio.0
type macio-bus
[...]
+ dev: macio-nvram, id ""
+
Commit 260bc9d8aa "hw/sd/sd.c: QOMify" QOMified only the device
itself, not its users. It kept sd_init() around for non-QOMified
users.
More than four years later, three such users remain: omap1 (machines
cheetah, sx1, sx1-v1) and omap2 (machines n800, n810) are not
QOMified, and pl181 (machines
cuda_init() creates a "mos6522-cuda" device, but it's never realized.
Affects machines mac99 with via=cuda (default) and g3beige.
pmu_init() creates a "mos6522-pmu" device, but it's never realized.
Affects machine mac99 with via=pmu and via=pmu-adb,
In theory, a device becomes real only on realiz
We plug aux-to-i2c-bridge into the aux-bus, even though its
DeviceClass member bus_type is null, not TYPE_AUX_BUS. Fix that by
deriving it from TYPE_AUX_SLAVE instead of TYPE_DEVICE.
Cc: KONRAD Frederic
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
---
hw/misc/auxbus.c
pnv_chip_power8_instance_init() creates a "pnv-psi-POWER8" sysbus
device in a way that leaves it unplugged.
pnv_chip_power9_instance_init() and pnv_chip_power10_instance_init()
do the same for "pnv-psi-POWER9" and "pnv-psi-POWER10", respectively.
These devices aren't actually sysbus devices. Corr
These devices go with the "via-pmu" device, which is controlled by
property "has-pmu". macio_newworld_init() creates it unconditionally,
because the property has not been set then. macio_newworld_realize()
realizes it only when the property is true. Works, although it can
leave an unrealized dev
Just adding Huacai, the original author and the new maintainer for Fuloong
2E machine.
1:04 PM Čet, 28.05.2020. Markus Armbruster је
написао/ла:
>
> sm501_init() and ati_vga_realize() create an "i2c-ddc" device, but
> neglect to realize it. Affects machines sam460ex, shix, r2d, and
> fulong2e.
>
Philippe Mathieu-Daudé writes:
> On 5/28/20 9:12 AM, Pavel Dovgalyuk wrote:
>>
>> On 27.05.2020 17:53, Philippe Mathieu-Daudé wrote:
>>> On 5/27/20 12:31 PM, Pavel Dovgalyuk wrote:
This patch adds a test for record/replay an execution of x86_64 machine.
Execution scenario includes si
Device "riscv.sifive.e.soc" is a direct subtype of TYPE_DEVICE, but
its instance struct SiFiveESoCState's member @parent_obj is
SysBusDevice instead of DeviceState. Correct that.
Same for "riscv.sifive.u.soc"'s instance struct SiFiveUSoCState.
Cc: Palmer Dabbelt
Cc: Alistair Francis
Cc: Sagar
riscv_sifive_e_soc_init(), riscv_sifive_u_soc_init(),
spike_board_init(), spike_v1_10_0_board_init(),
spike_v1_09_1_board_init(), and riscv_virt_board_init() create
"riscv-hart_array" sysbus devices in a way that leaves them unplugged.
Create them the common way that puts them into the main system
From: Cédric Le Goater
Commit ece09beec457 ("aspeed: introduce a configurable number of CPU
per machine") was a convient change during bringup but the Aspeed SoCs
have a fixed number of CPUs : one for the AST2400 and AST2500, and two
for the AST2600.
When the number of CPUs configured with -smp
On Wed, 27 May 2020 at 07:03, Markus Armbruster wrote:
>
> The following changes since commit ddc760832fa8cf5e93b9d9e6e854a5114ac63510:
>
> Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-05-26' into
> staging (2020-05-26 14:05:53 +0100)
>
> are available in the Git repository at:
1 - 100 of 339 matches
Mail list logo
