On 27/05/2020 23.54, Eric Blake wrote:
> On 5/27/20 4:40 PM, Peter Maydell wrote:
>> On Wed, 27 May 2020 at 20:21, Philippe Mathieu-Daudé
>> <1881...@bugs.launchpad.net> wrote:
>>>
>>> Public bug reported:
>>>
>>> Last time I built QEMU was on commit
>>> d5c75ec500d96f1d93447f990cd5a4ef5ba27fae,
On Thu, May 28, 2020 at 07:10:46AM +0200, Paolo Bonzini wrote:
> On 28/05/20 06:35, Yan Zhao wrote:
> > On Tue, May 26, 2020 at 10:26:35AM +0100, Peter Maydell wrote:
> >> On Mon, 25 May 2020 at 11:20, Paolo Bonzini wrote:
> >>> Not all of them, only those that need to return MEMTX_ERROR. I
28.05.2020 00:57, Eric Blake wrote:
On 5/27/20 4:46 PM, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/20200527203733.16129-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below.
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 likely it disconnects and
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 address
space of 64 bit hosts
Patchew URL:
https://patchew.org/QEMU/20200528054807.21278-1-vishal.l.ve...@intel.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20200528054807.21278-1-vishal.l.ve...@intel.com
Subject: [PATCH v2 0/3] account for NVDIMM nodes
** 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
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
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:
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;
On 27.05.2020 19:44, Alex Bennée wrote:
Pavel Dovgalyuk writes:
This patch adds a test for record/replay, which boots Linux
image from the disk and interacts with the network.
The idea and code of this test is borrowed from boot_linux.py
However, currently record/replay works only for
On 27.05.2020 18:41, Alex Bennée wrote:
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 Dovgalyuk
---
0 files
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
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
Paolo Bonzini writes:
> On 27/05/20 17:05, Peter Maydell wrote:
>> I disagree with these. We're in a realize function, the API
>> says "on errors, report them via the Error* you got passed",
>> so we should do that, not blow up. _abort only makes
>> sense if (a) we have no better way to report
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 );
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
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
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
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 \
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
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
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
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
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
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
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
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:
> 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
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
> > > 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
>
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
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 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
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
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
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
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
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
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
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
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 ) &
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
>>
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
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
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
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
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
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 already
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
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.
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
Hi Fred,
On 5/28/20 11:44 AM, Fred Konrad wrote:
> 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
The warnings in the report like "MSR(48FH).vmx-exit-load-perf-global-ctrl" are
unrelated (in regard to guest hang).
Those happen on
a) too old kernels that don't support the feature
b) mismatch of expectations of a chips vs its actual capabilities
E.g. if libvirt thinks a feature should be
@Andreas - If we find nothing else to try I'll ping you when I have a
newer qemu build for Ubuntu 20.10 for you to try.
** Tags added: qemu-20.10
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 5/20/20 12:34 AM, Laszlo Ersek wrote:
> On 05/19/20 20:20, Philippe Mathieu-Daudé wrote:
>> The 'blob_id' argument refers to a QOM object able to produce
>> data consumable by the fw_cfg device. The producer object must
>> implement the FW_CFG_DATA_GENERATOR interface.
>
> OK, this answers my
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
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:
>
>
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
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
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
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
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)
> > >
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
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:
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
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
---
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
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:
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 ""
+
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
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
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.
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
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
leon3_generic_hw_init() creates a "grlib,ahbpnp" and a "grlib,apbpnp"
sysbus device in a way that leaves them unplugged.
Create them the common way that puts them into the main system bus.
Affects machine leon3_generic. Visible in "info qtree":
bus: main-system-bus
type System
+
From: "Dr. David Alan Gilbert"
When the source finishes migration the destination will still be
receiving the data sent by the source, so it might not have quite
finished yet, so won't quite have reached 'completed'.
This lead to occasional asserts in the next few checks.
After the source has
On 5/28/20 1:24 PM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> When the source finishes migration the destination will still be
> receiving the data sent by the source, so it might not have quite
> finished yet, so won't quite have reached 'completed'.
> This lead
On 5/28/20 1:04 PM, Markus Armbruster wrote:
> 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
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:
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
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.
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
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:
>> -
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
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
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
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
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
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
@@
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
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.
1 - 100 of 344 matches
Mail list logo
