Vladimir Sementsov-Ogievskiy писал 2020-02-25 10:27:
25.02.2020 8:58, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-21 16:23:
21.02.2020 15:35, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-21 13:09:
21.02.2020 12:49, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy пис
Common VM users sometimes care about CPU speed, so we add two new
options to allow VM vendors to present CPU speed to their users.
Normally these information can be fetched from host smbios.
Strictly speaking, the "max speed" and "current speed" in type 4
are not really for the max speed and curre
On 2/25/20 12:37 AM, David Gibson wrote:
> MIN_RMA_SLOF records the minimum about of RMA that the SLOF firmware
> requires. It lets us give a meaningful error if the RMA ends up too small,
> rather than just letting SLOF crash.
>
> It's currently stored as a number of megabytes, which is strange
On Mon, 24 Feb 2020 11:29:37 -0600
Babu Moger wrote:
> On 2/24/20 2:52 AM, Igor Mammedov wrote:
> > On Thu, 13 Feb 2020 12:17:25 -0600
> > Babu Moger wrote:
> >
> >> Use the new functions from topology.h and delete the unused code. Given the
> >> sockets, nodes, cores and threads, the new fun
On 24.02.20 23:49, Peter Xu wrote:
> On Fri, Feb 21, 2020 at 05:42:04PM +0100, David Hildenbrand wrote:
>> When we partially change mappings (esp., mmap over parts of an existing
>> mmap like qemu_ram_remap() does) where we have a userfaultfd handler
>> registered, the handler will implicitly be un
On Mon, 24 Feb 2020 11:12:41 -0600
Babu Moger wrote:
> On 2/24/20 2:34 AM, Igor Mammedov wrote:
> > On Thu, 13 Feb 2020 12:17:04 -0600
> > Babu Moger wrote:
> >
> >> Update structures X86CPUTopoIDs and CPUX86State to hold the nodes_per_pkg.
> >> This is required to build EPYC mode topology.
>
use the new virtio_delete_queue function to cleanup.
Signed-off-by: Pan Nengyuan
Cc: "Dr. David Alan Gilbert"
Cc: Stefan Hajnoczi
---
hw/virtio/vhost-user-fs.c | 15 +--
include/hw/virtio/vhost-user-fs.h | 2 ++
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git
Similar to other virtio-deivces, rq_vq forgot to delete in
virtio_pmem_unrealize, this patch fix it.
This device has aleardy maintained a vq pointer, thus we use the new
virtio_delete_queue function directly to do the cleanup.
Reported-by: Euler Robot
Signed-off-by: Pan Nengyuan
---
hw/virtio
Similar to other virtio-deivces, ctrl_vq forgot to delete in
virtio_crypto_device_unrealize, this patch fix it.
This device has aleardy maintained vq pointers. Thus, we use the new
virtio_delete_queue function directly to do the cleanup.
The leak stack:
Direct leak of 10752 byte(s) in 3 object(s
Similar to other virtio device(https://patchwork.kernel.org/patch/11399237/),
virtio queues forgot to delete in unrealize, and aslo error path in realize,
this patch fix these memleaks, the leak stack is as follow:
Direct leak of 57344 byte(s) in 1 object(s) allocated from:
#0 0x7f15784fb970
Similar to other virtio device(https://patchwork.kernel.org/patch/11399237/),
we aslo found some virtio-queue leaks in unrealize().
This series do the cleanup in unrealize to fix it.
Pan Nengyuan (4):
vhost-user-fs: do delete virtio_queues in unrealize
vhost-user-fs: convert to the new virtio
On 25/02/20 06:59, Gerd Hoffmann wrote:
> Now that the rom bar is mapped read-only and the guest can't change
> things under our feet we don't need the shadow rom any more.
Can't it do so when migrating from an older version?
Paolo
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/display/qxl.h |
On Mon, 2020-02-24 at 08:13 -0800, Richard Henderson wrote:
> On 2/23/20 11:07 PM, Robert Hoo wrote:
> > Inspired by your suggestion, I'm thinking go further: use immediate
> > rather than a global variable, so that saves 1 memory(/cache)
> > access.
> >
> > #ifdef CONFIG_AVX512F_OPT
> > #defi
On 24.02.20 23:26, Peter Xu wrote:
> On Fri, Feb 21, 2020 at 05:42:01PM +0100, David Hildenbrand wrote:
>
> [...]
>
>> @@ -3160,7 +3160,13 @@ static int ram_load_postcopy(QEMUFile *f)
>> break;
>> }
>>
>> -if (!offset_in_ramblock(block, addr)) {
>> +
25.02.2020 8:58, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-21 16:23:
21.02.2020 15:35, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-21 13:09:
21.02.2020 12:49, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-20 12:36:
1 or 2 are ok, and 4 or 8 lead t
Ping
On Sun, Feb 09, 2020 at 12:43:35PM -0500, Raphael Norwitz wrote:
>
> On Thu, Feb 06, 2020 at 03:32:38AM -0500, Michael S. Tsirkin wrote:
> >
> > On Wed, Jan 15, 2020 at 09:57:06PM -0500, Raphael Norwitz wrote:
> > > The current vhost-user implementation in Qemu imposes a limit on the
> > >
On Tue, 25 Feb 2020 10:37:08 +1100
David Gibson wrote:
> a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not
> fundamentally available only for PowerPC 64" and added a 32-bit version
> of the MSR[HV] bit.
>
> But nothing was ever really done with that; there is no meaningfu
Hi Jason,
Apologies for the delayed response. I tried plugging NetClientState in the CAN
which is required if we use qemu_send_packet but this will change the
underlying architecture of can-core, can-socketcan a lot. This means changes
the way CAN bus is created/works and socket CAN works. CAN S
Map qxl rom read-only into the guest, so the guest can't tamper with the
content. qxl has a shadow copy of the rom to deal with that, but the
shadow doesn't cover the mode list. A privilidged user in the guest can
manipulate the mode list and that to trick qemu into oob reads, leading
to a DoS vi
Now that the rom bar is mapped read-only and the guest can't change
things under our feet we don't need the shadow rom any more.
Signed-off-by: Gerd Hoffmann
---
hw/display/qxl.h | 2 +-
hw/display/qxl.c | 25 +
2 files changed, 10 insertions(+), 17 deletions(-)
diff --
Gerd Hoffmann (2):
qxl: map rom r/o
qxl: drop shadow_rom
hw/display/qxl.h | 2 +-
hw/display/qxl.c | 27 ++-
2 files changed, 11 insertions(+), 18 deletions(-)
--
2.18.2
Vladimir Sementsov-Ogievskiy писал 2020-02-21 16:23:
21.02.2020 15:35, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-21 13:09:
21.02.2020 12:49, dovgaluk wrote:
Vladimir Sementsov-Ogievskiy писал 2020-02-20 12:36:
1 or 2 are ok, and 4 or 8 lead to the failures.
That is strange.
On 2020/2/25 上午10:59, Chen Qun wrote:
The current code causes clang static code analyzer generate warning:
hw/net/imx_fec.c:858:9: warning: Value stored to 'value' is never read
value = value & 0x000f;
^ ~~
hw/net/imx_fec.c:864:9: warning: Value store
Hi Alistair,
On Tue, Feb 25, 2020 at 5:14 AM Alistair Francis wrote:
>
> On Sun, Feb 16, 2020 at 5:56 AM Bin Meng wrote:
> >
> > At present the board serial number is hard-coded to 1, and passed
> > to OTP model during initialization. Firmware (FSBL, U-Boot) uses
> > the serial number to generat
Hi,
> -Original Message-
> From: Daniel Cho [mailto:daniel...@qnap.com]
> Sent: Tuesday, February 25, 2020 10:53 AM
> To: Zhanghailiang
> Cc: qemu-devel@nongnu.org; quint...@redhat.com; Dr. David Alan Gilbert
>
> Subject: Re: [PATCH V2 4/8] COLO: Optimize memory back-up process
>
> Hi
> > ide_exec_cmd 0.461 pid=147030 bus=0x55b77f922d10
> > state=0x55b77f922d98 cmd=0xef
> The command is run here if I'm not mistaken Does this set the irq
> right
> away on QEMU where on real hadware this may take some time? Not sure
> if
> that's a problem but trying to understand what's happen
We fail to validate the upper bits of a virtual address on a
translation disabled regime, as per AArch64.TranslateAddressS1Off.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/target/ar
This is an aarch64-only function. Move it out of the shared file.
This patch is code movement only.
Signed-off-by: Richard Henderson
---
target/arm/helper-a64.h | 1 +
target/arm/helper.h | 1 -
target/arm/helper-a64.c | 91
target/arm/op_helper.c
We must include the tag in the FAR_ELx register when raising
an addressing exception. Which means that we should not clear
out the tag during translation.
We cannot at present comply with this for user mode, so we
retain the clean_data_tbi function for the moment, though it
no longer does what it
The function does not write registers, and only reads them by
implication via the exception path.
Signed-off-by: Richard Henderson
---
target/arm/helper-a64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/helper-a64.h b/target/arm/helper-a64.h
index b1a5935f61..3
This data access was forgotten when we added support for cleaning
addresses of TBI information.
Fixes: 3a471103ac1823ba
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/trans
We now cache the core mmu_idx in env->hflags. Rather than recompute
from scratch, extract the field. All of the uses of cpu_mmu_index
within target/arm are within helpers where env->hflags is stable.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 23 +--
target/
We missed this case within AArch64.ExceptionReturn.
Signed-off-by: Richard Henderson
---
target/arm/helper-a64.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
index 509ae93069..95e9e879ca 100644
--- a
Replicate the single TBI bit from TCR_EL2 and TCR_EL3 so that
we can unconditionally use pointer bit 55 to index into our
composite TBI1:TBI0 field.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/arm/helpe
We have a bug at present wherein we do not supply the memory tag to
the memory system, so that on fault FAR_ELx does not contain the
correct value.
For system mode, we already handle ignoring TBI in get_phys_addr_lpae,
as long as we don't actually drop the tag during translation.
For user mode, we
> On Feb 19, 2020, at 10:35 AM, BALATON Zoltan wrote:
>
> Hello,
>
> On Tue, 18 Feb 2020, Programmingkid wrote:
>>> On Feb 18, 2020, at 12:10 PM, BALATON Zoltan wrote:
>>> While other targets take advantage of using host FPU to do floating
>>> point computations, this was disabled for PPC tar
The current code causes clang static code analyzer generate warning:
hw/net/imx_fec.c:858:9: warning: Value stored to 'value' is never read
value = value & 0x000f;
^ ~~
hw/net/imx_fec.c:864:9: warning: Value stored to 'value' is never read
value = v
Hi Hailiang,
With version 2, the code in migration/ram.c
+if (migration_incoming_colo_enabled()) {
+if (migration_incoming_in_colo_state()) {
+/* In COLO stage, put all pages into cache temporarily */
+host = colo_cache_from_bloc
On Mon, Feb 24, 2020 at 08:23:43PM +0100, Greg Kurz wrote:
> If a hot plug or unplug request is pending at CAS, we currently trigger
> a CAS reboot, which severely increases the guest boot time. This is
> because SLOF doesn't handle hot plug events and we had no way to fix
> the FDT that gets prese
Patchew URL: https://patchew.org/QEMU/20200225015026.940-1-miaoy...@huawei.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
From: Chen Qun
Clang static code analyzer show warning:
hw/timer/exynos4210_mct.c:1370:9: warning: Value stored to 'index' is never read
index = GET_L_TIMER_CNT_REG_IDX(offset, lt_i);
^ ~
hw/timer/exynos4210_mct.c:1399:9: warning: Value st
From: Chen Qun
Clang static code analyzer show warning:
block/iscsi.c:1920:9: warning: Value stored to 'flags' is never read
flags &= ~BDRV_O_RDWR;
^
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Ronnie Sahlberg
Cc: Paolo Bonzini
Cc: Peter Lie
From: Chen Qun
Clang static code analyzer show warning:
scsi/scsi-disk.c:1918:5: warning: Value stored to 'buflen' is never read
buflen = req->cmd.xfer;
^~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Paolo Bonzini
Cc: Fam Zheng
---
hw/scsi/scsi-disk.
From: Chen Qun
Clang static code analyzer show warning:
block/stream.c:186:9: warning: Value stored to 'ret' is never read
ret = 0;
^ ~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: John Snow
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-bl...@nongnu.org
---
block/s
From: Chen Qun
Clang static code analyzer show warning:
hw/dma/xlnx-zdma.c:399:13: warning: Value stored to 'dst_type' is never read
dst_type = FIELD_EX32(s->dsc_dst.words[3], ZDMA_CH_DST_DSCR_WORD3,
^ ~~~
Repor
From: Chen Qun
Clang static code analyzer show warning:
hw/display/blizzard.c:940:9: warning: Value stored to 'data' is never read
data >>= 5;
^~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Andrzej Zaborowski
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
---
From: Chen Qun
Clang static code analyzer show warning:
monitor/hmp-cmds.c:2867:17: warning: Value stored to 'set' is never read
set = true;
^
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: "Dr. David Alan Gilbert"
---
monitor/hmp-cmds.c | 1
From: Chen Qun
Clang static code analyzer show warning:
hw/display/pxa2xx_lcd.c:596:9: warning: Value stored to 'format' is never read
format = 0;
^~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Andrzej Zaborowski
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
From: Chen Qun
The "again" assignment is meaningless before g_assert_not_reached.
In addition, the break statements no longer needs to be after
g_assert_not_reached.
Clang static code analyzer show warning:
hw/usb/hcd-ehci.c:2108:13: warning: Value stored to 'again' is never read
aga
From: Chen Qun
Clang static code analyzer show warning:
hw/display/exynos4210_fimd.c:1313:17: warning: Value stored to 'is_dirty' is
never read
is_dirty = false;
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Igor Mitsyanko
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
From: Chen Qun
The "ret" has been assigned in all branches. It didn't need to be
assigned separately.
Clang static code analyzer show warning:
migration/vmstate.c:365:17: warning: Value stored to 'ret' is never read
ret = 0;
^ ~
Reported-by: Euler Robot
S
From: Chen Qun
Clang static code analyzer show warning:
block/file-posix.c:891:9: warning: Value stored to 'op' is never read
op = RAW_PL_ABORT;
^
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-bl...@nongnu.org
---
From: Chen Qun
Clang static code analyzer show warning:
hw/scsi/esp-pci.c:198:9: warning: Value stored to 'size' is never read
size = 4;
^ ~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Paolo Bonzini
Cc: Fam Zheng
---
hw/scsi/esp-pci.c | 1 -
1 file change
From: Chen Qun
Hi all, our EulerRobot integrates clang static code analyzer tools and
found a lot of warnings. They are mainly redundant variable assignments.
This series fixes the warnings.
Chen Qun (13):
block/stream: Remove redundant statement in stream_run()
block/iscsi:Remove redundant
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Monday, February 24, 2020 8:36 PM
> To: miaoyubo
> Cc: peter.mayd...@linaro.org; m...@redhat.com; qemu-devel@nongnu.org;
> Xiexiangyou ; shannon.zha...@gmail.com;
> imamm...@redhat.com
> Subject: Re: [RFC
From: miaoyubo
Currently, pxb-pcie could be defined by the cmdline like
--device pxb-pcie,id=pci.9,bus_nr=128
However pxb-pcie is not described in acpi tables for arm.
The formal two patches support pxb-pcie for arm, escpcially the
specification for pxb-pcie in DSDT table.
Add a testcase to
From: miaoyubo
Extract two APIs acpi_dsdt_add_pci_route_table and
acpi_dsdt_add_pci_osc form acpi_dsdt_add_pci. The first
API is used to specify the pci route table and the second
API is used to declare the operation system capabilities.
These two APIs would be used to specify the pxb-pcie in DSD
From: miaoyubo
Currently virt machine is not supported by pxb-pcie,
and only one main host bridge described in ACPI tables.
In this patch,PXB-PCIE is supproted by arm and certain
resource is allocated for each pxb-pcie in acpi table.
The resource for the main host bridge is also reallocated.
Sig
From: miaoyubo
Currently pxb-pcie is not supported by arm, the reason for it is
pxb-pcie is not described in DSDT table and only one main host bridge
is described in acpi tables, which means it is not impossible to
present different io numas for different devices, especially
host-passthrough devi
/On Mon, Feb 24, 2020 at 9:12 AM Damien Hedde wrote
>
> Add functions to easily handle clocks with devices.
> Clock inputs and outputs should be used to handle clock propagation
> between devices.
> The API is very similar the GPIO API.
>
> This is based on the original work of Frederic Konrad.
>
On 2020/2/24 下午8:43, Paolo Bonzini wrote:
> On 22/02/20 13:25, Chen Gang wrote:
>> On 2020/2/22 下午3:37, Paolo Bonzini wrote:
>>> On 22/02/20 03:10, Chen Gang wrote:
Set C1 to 1 if stack overflow occurred; set to 0 otherwise".
In helper_fxam_ST0, I guess, we need "env->fpus |= 0x200"
On Mon, Feb 24, 2020 at 2:27 PM Kevin Wolf wrote:
> > > There are quite a few machines running on this host, and we have not
> > > experienced other problems so far. So right now, only ZFS is able to
> > > trigger this for some reason. The guest has 8 virtual cores. I also
> > > tried writing dire
On Thu, Feb 20, 2020 at 10:19 AM Stefan Ring wrote:
>
> Hi,
>
> I have a very curious problem on an oVirt-like virtualization host
> whose storage lives on gluster (as qcow2).
>
> The problem is that of the writes done by ZFS, whose sizes according
> to blktrace are a mixture of 8, 16, 24, ... 256
On Mon, Feb 24, 2020 at 1:35 PM Stefan Ring wrote:
>
> [...]. As already stated in
> the original post, the problem only occurs with multiple parallel
> write requests happening.
Actually I did not state that. Anyway, the corruption does not happen
when I restrict the ZFS io scheduler to only 1 r
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Monday, February 24, 2020 11:19 PM
> To: Zhanghailiang ;
> qemu-devel@nongnu.org
> Cc: daniel...@qnap.com; dgilb...@redhat.com; quint...@redhat.com
> Subject: Re: [PATCH V2 7/8] COLO: Migrate dirty pages during th
It's easier to work with than a list of tuples, because we can check the
keys for membership.
Signed-off-by: John Snow
---
python/qemu/machine.py| 10 +-
tests/qemu-iotests/040| 12 ++--
tests/qemu-iotests/260| 5 +++--
tests/qemu-iotests/iotests.py | 16
This job copies the allocation map into a bitmap. It's a job because
there's no guarantee that allocation interrogation will be quick (or
won't hang), so it cannot be retrofit into block-dirty-bitmap-merge.
It was designed with different possible population patterns in mind,
but only top layer all
Hi,
This is a new (very small) block job that writes a pattern into a
bitmap. The only pattern implemented is the top allocation information.
This can be used to "recover" an incremental bitmap chain if an external
snapshot was taken without creating a new bitmap first: any writes made
to the ima
Signed-off-by: John Snow
---
tests/qemu-iotests/257| 110 +---
tests/qemu-iotests/bitmaps.py | 131 ++
2 files changed, 132 insertions(+), 109 deletions(-)
create mode 100644 tests/qemu-iotests/bitmaps.py
diff --git a/tests/qemu-io
This is a new job-creating command.
Signed-off-by: John Snow
---
qapi/block-core.json | 18 ++
qapi/transaction.json | 2 ++
blockdev.c| 78 +++
3 files changed, 98 insertions(+)
diff --git a/qapi/block-core.json b/qapi/block-core.js
Just a mild cleanup while I was here.
Signed-off-by: John Snow
---
tests/qemu-iotests/iotests.py | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 8815052eb5..5d2990a0e4 100644
--- a/tests/q
David Gibson writes:
> Currently, we construct the SLBE used for VRMA translations when the LPCR
> is written (which controls some bits in the SLBE), then use it later for
> translations.
>
> This is a bit complex and confusing - simplify it by simply constructing
> the SLBE directly from the LPC
On Mon, Feb 24, 2020 at 09:55:18PM +0100, Philippe Mathieu-Daudé wrote:
> The scripts/coccinelle/memory-region-housekeeping.cocci reported:
> * TODO
> [[view:./hw/ppc/ppc405_boards.c::face=ovl-face1::linb=195::colb=8::cole=30][potential
> use of memory_region_init_rom*() in ./hw/ppc/ppc405_board
On Mon, Feb 24, 2020 at 09:55:12PM +0100, Philippe Mathieu-Daudé wrote:
> This commit was produced with the Coccinelle script
> scripts/coccinelle/memory-region-housekeeping.cocci.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: David Gibson
> ---
> hw/ppc/mac_newworld.c | 3 +--
> hw/ppc
On Mon, Feb 24, 2020 at 09:55:11PM +0100, Philippe Mathieu-Daudé wrote:
> This commit was produced with the Coccinelle script
> scripts/coccinelle/memory-region-housekeeping.cocci.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: David Gibson
> ---
> hw/pci-host/prep.c | 5 ++---
> 1 file
On Mon, Feb 24, 2020 at 12:18:27PM +0100, Greg Kurz wrote:
> On Wed, 19 Feb 2020 10:21:05 +1100
> David Gibson wrote:
>
> > On Fri, Feb 14, 2020 at 07:19:00PM +0100, Greg Kurz wrote:
> > > On Fri, 14 Feb 2020 09:28:35 +1100
> > > David Gibson wrote:
> > >
> > > > On Thu, Feb 13, 2020 at 04:38:3
On Mon, Feb 24, 2020 at 9:06 AM Damien Hedde wrote:
>
> Signed-off-by: Damien Hedde
> Reviewed-by: Peter Maydell
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> --
>
> v7: remove leading underscores in macro args
> ---
> include/hw/clock.h | 9 +
David Gibson writes:
> When running guests under a hypervisor, the hypervisor obviously needs to
> be protected from guest accesses even if those are in what the guest
> considers real mode (translation off). The POWER hardware provides two
> ways of doing that: The old way has guest real mode a
On Mon, Feb 24, 2020 at 9:05 AM Damien Hedde wrote:
>
> This object may be used to represent a clock inside a clock tree.
>
> A clock may be connected to another clock so that it receives update,
> through a callback, whenever the source/parent clock is updated.
>
> Although only the root clock of
In spapr_machine_init() we clamp the size of the RMA to 16GiB and the
comment saying why doesn't make a whole lot of sense. In fact, this was
done because the real mode handling code elsewhere limited the RMA in TCG
mode to the maximum value configurable in LPCR[RMLS], 16GiB.
But,
* Actually LPC
On 2020/2/25 0:04, Alex Williamson wrote:
> On Mon, 24 Feb 2020 14:42:17 +0800
> "Longpeng(Mike)" wrote:
>
>> From: Longpeng
>>
>> vfio_pci_load_rom() maybe failed and then the vdev->rom is NULL in
>> some situation (though I've not encountered yet), maybe we should
>> avoid the VM abort.
>>
The Real Mode Area (RMA) is the part of memory which a guest can access
when in real (MMU off) mode. Of course, for a guest under KVM, the MMU
isn't really turned off, it's just in a special translation mode - Virtual
Real Mode Area (VRMA) - which looks like real mode in guest mode.
The mechanics
This function calculates the maximum size of the RMA as implied by the
host's page size of structure of the VRMA (there are a number of other
constraints on the RMA size which will supersede this one in many
circumstances).
The current interface takes the current RMA size estimate, and clamps it
t
The Real Mode Area (RMA) needs to fit within the NUMA node owning memory
at address 0. That's usually node 0, but can be a later one if there are
some nodes which have no memory (only CPUs).
This is currently handled by the spapr_node0_size() helper. It has only
one caller, so there's not a lot
Move the calculation of the Real Mode Area (RMA) size into a helper
function. While we're there clean it up and correct it in a few ways:
* Add comments making it clearer where the various constraints come from
* Remove a pointless check that the RMA fits within Node 0 (we've just
clamped
Currently we use a big switch statement in ppc_hash64_update_rmls() to work
out what the right RMA limit is based on the LPCR[RMLS] field. There's no
formula for this - it's just an arbitrary mapping defined by the existing
CPU implementations - but we can make it a bit more readable by using a
lo
When the LPCR is written, we update the env->rmls field with the RMA limit
it implies. Simplify things by just calculating the value directly from
the LPCR value when we need it.
It's possible this is a little slower, but it's unlikely to be significant,
since this is only for real mode accesses
When we store the Logical Partitioning Control Register (LPCR) we have a
big switch statement to work out which are valid bits for the cpu model
we're emulating.
As well as being ugly, this isn't really conceptually correct, since it is
based on the mmu_model variable, whereas the LPCR isn't (only
MIN_RMA_SLOF records the minimum about of RMA that the SLOF firmware
requires. It lets us give a meaningful error if the RMA ends up too small,
rather than just letting SLOF crash.
It's currently stored as a number of megabytes, which is strange for global
constants. Move that megabyte scaling i
Currently, we construct the SLBE used for VRMA translations when the LPCR
is written (which controls some bits in the SLBE), then use it later for
translations.
This is a bit complex and confusing - simplify it by simply constructing
the SLBE directly from the LPCR when we need it.
Signed-off-by:
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qem
The table of RMA limits based on the LPCR[RMLS] field is slightly wrong.
We're missing the RMLS == 0 => 256 GiB RMA option, which is available on
POWER8, so add that.
The comment that goes with the table is much more wrong. We *don't* filter
invalid RMLS values when writing the LPCR, and there's
When running guests under a hypervisor, the hypervisor obviously needs to
be protected from guest accesses even if those are in what the guest
considers real mode (translation off). The POWER hardware provides two
ways of doing that: The old way has guest real mode accesses simply offset
and bound
For the "pseries" machine, we use "virtual hypervisor" mode where we
only model the CPU in non-hypervisor privileged mode. This means that
we need guest physical addresses within the modelled cpu to be treated
as absolute physical addresses.
We used to do that by clearing LPCR[VPM0] and setting L
Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus
from POWER7 onwards. However the translation mode which the RMOR controls
is no longer supported in POWER9, and so the register has been removed from
the architecture.
Remove it from our model on POWER9 and POWER10.
Sign
POWER "book S" (server class) cpus have a concept of "real mode" where
MMU translation is disabled... sort of. In fact this can mean a bunch
of slightly different things when hypervisor mode and other
considerations are present.
We had some errors in edge cases here, so clean some things up and
c
The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability.
However, it can be (and often was) strapped into "Apple mode", where the
hypervisor capabilities were disabled (essentially putting it always in
hypervisor mode).
That's actually the only mode of the 970 we support in qemu
a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not
fundamentally available only for PowerPC 64" and added a 32-bit version
of the MSR[HV] bit.
But nothing was ever really done with that; there is no meaningful support
for 32-bit hypervisor mode 13 years later. Let's stop pr
New y2038 safe 32-bit architectures (like RISC-V) don't support old
syscalls with a 32-bit time_t. The kernel defines new *_time64 versions
of these syscalls. Add some more #ifdefs to syscall.c in linux-user to
allow us to compile without these old syscalls.
Signed-off-by: Alistair Francis
Review
Signed-off-by: Alistair Francis
---
linux-user/riscv/syscall32_nr.h | 314
linux-user/riscv/syscall64_nr.h | 303 ++
linux-user/riscv/syscall_nr.h | 294 +-
3 files changed, 619 insertions(+), 292 deletions
1 - 100 of 438 matches
Mail list logo
