On Wed, Jun 20, 2018 at 12:24:13PM +0200, Cédric Le Goater wrote:
> This changes the IPC realize and reset handlers in DeviceRealize and
> DeviceReset handlers. parent handlers are now called from the
> inheriting classes which is a cleaner object pattern.
>
> Signed-off-by: Cédric Le Goater
App
Thomas Huth writes:
> The oldest machine type which is still used in a still maintained distro
> is a pc-0.12 based machine type in RHEL6, so everything that is older
> than pc-0.12 should not be used anymore. Thus let's deprecate pc-0.10
> and pc-0.11 so that we can finally remove them in a futu
Paolo Bonzini writes:
> On 22/06/2018 21:35, Eduardo Habkost wrote:
Why is this better than using KVM by default if it's available?
>>> The answer is (as almost always): Compatibility with migration. Nobody
>>> dares to sacrifice that chicken :-(
>> We can now kill it if we announce the feat
On 06/25/2018 08:27 AM, David Gibson wrote:
> On Wed, Jun 20, 2018 at 12:24:12PM +0200, Cédric Le Goater wrote:
>> This moves the common ICS code of the realize and reset handlers of
>> the ICS_SIMPLE class under the ICS_BASE class. The vmstate is also
>> moved down one class.
>>
>> The benefits ar
On Wed, Jun 20, 2018 at 12:24:12PM +0200, Cédric Le Goater wrote:
> This moves the common ICS code of the realize and reset handlers of
> the ICS_SIMPLE class under the ICS_BASE class. The vmstate is also
> moved down one class.
>
> The benefits are that the ICS_KVM class can directly inherit from
On Wed, Jun 20, 2018 at 07:29:37AM +0200, Cédric Le Goater wrote:
> On 06/20/2018 02:56 AM, David Gibson wrote:
> > On Tue, Jun 19, 2018 at 07:24:44AM +0200, Cédric Le Goater wrote:
> >>
> > typedef struct PnvChipClass {
> > /*< private >*/
> > @@ -75,6 +95,7 @@ typedef struct Pnv
On 22.06.2018 15:30, Philippe Mathieu-Daudé wrote:
> Hi Peter,
>
> On 06/06/2018 12:02 PM, Philippe Mathieu-Daudé wrote:
>> On 06/06/2018 11:53 AM, Thomas Huth wrote:
>>> On 06.06.2018 16:47, Philippe Mathieu-Daudé wrote:
These COMs are hard to find, and the companie dropped the support
>>
>>
On Tue, 12 Jun 2018, at 16:27, Cédric Le Goater wrote:
> Also handle the fake transfers for dummy bytes in this setup
> routine. It will be useful when we activate MMIO execution.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Andrew Jeffery
> ---
> hw/ssi/aspeed_smc.c | 31
On Tue, 12 Jun 2018, at 16:27, Cédric Le Goater wrote:
> Only the flash type is strapped by HW. The 4BYTE mode is set by
> firmware when the flash device is detected.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Andrew Jeffery
> ---
> hw/ssi/aspeed_smc.c | 8 +---
> 1 file changed, 1
On 22.06.2018 22:13, Philippe Mathieu-Daudé wrote:
> On 06/22/2018 04:44 PM, Thomas Huth wrote:
>> On 22.06.2018 15:40, Philippe Mathieu-Daudé wrote:
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> ---
>>> include/hw/arm/omap.h | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>>
On 22.06.2018 22:10, Philippe Mathieu-Daudé wrote:
> On 06/22/2018 04:38 PM, Thomas Huth wrote:
>> On 22.06.2018 15:40, Philippe Mathieu-Daudé wrote:
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> ---
>>> hw/i2c/omap_i2c.c | 20
>>> 1 file changed, 12 insertions(+), 8 deletion
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Pavel Dovgalyuk writes:
>
> >> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> >> Pavel Dovgalyuk writes:
> >>
> >> >> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> >> >> Pavel Dovgalyuk writes:
> >> >>
> >> >> > Ping?
> >> >>
> >>
On Tue, 12 Jun 2018, at 16:27, Cédric Le Goater wrote:
> When configured in dual I/O mode, address and data are sent in dual
> mode, including the dummy byte cycles in between. Adapt the count to
> the IO setting.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Andrew Jeffery
> ---
> hw/ssi/
Peter, what about this one?
Pavel Dovgalyuk
> -Original Message-
> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
> Sent: Tuesday, June 05, 2018 2:56 PM
> To: 'Peter Maydell'; 'Pavel Dovgalyuk'
> Cc: 'QEMU Developers'; maria.klimushenk...@ispras.ru; 'Paolo Bonzini'; 'Lluís
> Vilanova'
New CPU models mostly inherit features from ancestor Skylake, while addin new
features: UMIP, New Instructions ( PCONIFIG (server only), WBNOINVD,
AVX512_VBMI2, GFNI, AVX512_VNNI, VPCLMULQDQ, VAES, AVX512_BITALG),
Intel PT and 5-level paging (Server only). As well as
IA32_PRED_CMD and IA32_ARCH_CAP
WBNOINVD: Write back and do not invalidate cache, enumerated by
CPUID.(EAX=8008H, ECX=0):EBX[bit 9].
Reference:
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
Signed-off-by: Robert Hoo
---
target/i386/cpu.c | 2
PCONFIG: Platform configuration, enumerated by CPUID.(EAX=07H, ECX=0):
EDX[bit18].
Reference:
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
Signed-off-by: Robert Hoo
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h
Support of IA32_PRED_CMD MSR already be enumerated by same CPUID bit as
SPEC_CTRL.
Signed-off-by: Robert Hoo
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1e69e68..3134af4 100644
--
This patch set defines the new guest CPU models of Icelake.
The first patch adds support of IA32_PRED_CMD MSR (IBPB) and
IA32_ARCH_CAPABILITIES MSR.
Other patches add CPUID bits feature words for new features, like PCONFIG,
WBNOINVD. The final patch defines Icelake-{Server,Client} CPU models.
R
IA32_PRED_CMD MSR gives software a way to issue commands that affect the state
of indirect branch predictors. Enumerated by CPUID.(EAX=7H,ECX=0):EDX[26].
IA32_ARCH_CAPABILITIES MSR enumerates architectural features of RDCL_NO and
IBRS_ALL. Enumerated by CPUID.(EAX=07H, ECX=0):EDX[29].
https://soft
On 2018-06-19 11:31, luc.mic...@greensocs.com wrote:
> From: Luc MICHEL
>
> This patch series add support for the virtualization extensions in the
> ARM GICv2 interrupt controller.
>
> The first two commits do some refactoring to prepare for the
> implementation. Commits 3 and 4 are the actual i
Hi Peter,
Yes, your considerations reasonable.
But in practice of hardware platforms, programmer checks that Arm TF
is using SMC for PSCI call conduit, then fix it manually in the ACPI
table, reason may be that Arm TF is lack of ACPI support, if device
tree used, there should be no such thing becau
On 06/24/2018 11:38 AM, Programmingkid wrote:
> void test_division_by_zero()
> {
> Converter c;
> uint64_t expected_answer = 0x0;
> uint32_t actual_fpscr, expected_fpscr = 0xc410;
> reset_fpscr();
> set_fpscr_bit(ZE);
> asm volatile("fdiv %0, %1, %2" : "=f"(c.d) : "f"(1.
If qemu-kvm quit without saving bitmaps to image(coredump, host kernel panic,
or host pooweroff), bitmaps in image can not be safely used anymore, and also
can not be removed. Useless bitmaps should be removed.
Signed-off-by: yaoxu
---
diff --git a/blockdev.c b/blockdev.c
index 58d7570932..c85056
If qemu-kvm quit without saving bitmaps to image(coredump, host kernel panic,
or host pooweroff), bitmaps in image can not be safely used anymore, and also
can not be removed. Useless bitmaps should be removed.
Signed-off-by: yaoxu <13466399...@163.com>
---
diff --git a/blockdev.c b/blockdev.c
ind
On Sun, Jun 24, 2018 at 11:24:17PM -0400, G 3 wrote:
>
> On Jun 24, 2018, at 8:46 PM, David Gibson wrote:
>
> > On Fri, Jun 22, 2018 at 10:22:58PM -0400, John Arbuckle wrote:
> > > When the fdiv instruction divides a finite number by zero,
> > > the result actually depends on the FPSCR[ZE] bit. I
On Jun 24, 2018, at 8:46 PM, David Gibson wrote:
On Fri, Jun 22, 2018 at 10:22:58PM -0400, John Arbuckle wrote:
When the fdiv instruction divides a finite number by zero,
the result actually depends on the FPSCR[ZE] bit. If this
bit is set, the return value is zero. If it is not set
the resul
If qemu-kvm quit without saving bitmaps to image(coredump, host kernel panic,
or host pooweroff), bitmaps in image can not be safely used anymore, and also
can not be removed. Useless bitmaps should be removed.
Signed-off-by: Yaoxu19870920 <13466399...@163.com>
---
diff --git a/blockdev.c b/blockd
If qemu-kvm quit without saving bitmaps to image(coredump, host kernel panic,
or host pooweroff), bitmaps in image can not be safely used anymore, and also
can not be removed. Useless bitmaps should be removed.
Signed-off-by: Yaoxu19870920 <13466399...@163.com>
---
diff --git a/blockdev.c b/blockd
If qemu-kvm quit without saving bitmaps to image(coredump, host kernel panic,
or host pooweroff), bitmaps in image can not be safely used anymore, and also
can not be removed. Useless bitmaps should be removed.
Signed-off-by: Yao Xu <13466399...@163.com>
---
diff --git a/blockdev.c b/blockdev.c
in
If qemu-kvm quit without saving bitmaps to image(coredump, host kernel panic,
or host pooweroff), bitmaps in image can not be safely used anymore, and also
can not be removed. Useless bitmaps should be removed.
Signed-off-by: Yaoxu19870920 <13466399...@163.com>
---
diff --git a/blockdev.c b/blockd
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180623172538.1590-1-ya...@didichuxing.com
Subject: [Qemu-devel] block/dirty-bitmap: Useless bitmap in image should be
removed
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=b
On Fri, Jun 22, 2018 at 10:22:58PM -0400, John Arbuckle wrote:
> When the fdiv instruction divides a finite number by zero,
> the result actually depends on the FPSCR[ZE] bit. If this
> bit is set, the return value is zero. If it is not set
> the result should be either positive or negative infinit
On Sat, Jun 23, 2018 at 04:17:08PM -0400, Programmingkid wrote:
>
> > On Jun 23, 2018, at 12:17 PM, Richard Henderson
> > wrote:
> >
> > On 06/22/2018 07:22 PM, John Arbuckle wrote:
> >> When the fdiv instruction divides a finite number by zero,
> >> the result actually depends on the FPSCR[ZE]
On Fri, 22 Jun 2018, at 17:27, Cédric Le Goater wrote:
> The timer controller can be driven by either an external 1MHz clock or
> by the APB clock. Today, the model makes the assumption that the APB
> frequency is always set to 24MHz but this is incorrect.
>
> The AST2400 SoC on the palmetto machi
On Fri, 22 Jun 2018, at 17:26, Cédric Le Goater wrote:
> The System Control Unit should be initialized first as it drives all
> the configuration of the SoC and other device models.
>
> Signed-off-by: Cédric Le Goater
> Reviewed-by: Joel Stanley
Acked-by: Andrew Jeffery
> ---
> hw/arm/aspeed
On Fri, 22 Jun 2018, at 17:26, Cédric Le Goater wrote:
> All Aspeed SoC clocks are driven by an input source clock which can
> have different frequencies : 24MHz or 25MHz, and also, on the Aspeed
> AST2400 SoC, 48MHz. The H-PLL (CPU) clock is defined from a
> calculation using parameters in the H-P
On 06/20/2018 05:06 AM, Yongbok Kim wrote:
> case NM_P_ROTX:
> +if (rt != 0) {
> +TCGv t0 = tcg_temp_new();
> +TCGv_i32 shift = tcg_const_i32(extract32(ctx->opcode, 0, 5));
> +TCGv_i32 shiftx = tcg_const_i32(extract32(ctx->opcode,
On 06/20/2018 05:06 AM, Yongbok Kim wrote:
> +void helper_llwp(CPUMIPSState *env, target_ulong addr, uint32_t reg1,
> + uint32_t reg2, uint32_t mem_idx)
> +{
> +if (addr & 0x7) {
> +env->CP0_BadVAddr = addr;
> +do_raise_exception(env, EXCP_AdEL, GETPC());
> +
On 06/20/2018 05:06 AM, Yongbok Kim wrote:
> +if (rt == 0 && imm == 0) {
> +/* Unconditional branch */
> +} else if (rt == 0 && imm != 0) {
> +/* Treat as NOP */
> +goto out;
Given that there is a different unconditional BC opcode, I would expect
On 06/20/2018 05:05 AM, Yongbok Kim wrote:
> Add nanoMIPS p_lsx and LSA instructions
>
> Signed-off-by: Yongbok Kim
> ---
> target/mips/translate.c | 139
> +++-
> 1 file changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/target/mips/translat
On 06/20/2018 05:05 AM, Yongbok Kim wrote:
> +case NM_SOV:
> +{
> +TCGv t0 = tcg_temp_local_new();
> +TCGv t1 = tcg_temp_new();
> +TCGv t2 = tcg_temp_new();
> +TCGLabel *l1 = gen_new_label();
> +
> +gen_load_gpr(t1, rs);
> +gen_load_gpr(t2, rt
On 06/20/2018 05:05 AM, Yongbok Kim wrote:
> case NM_P48I:
> +insn = cpu_lduw_code(env, ctx->base.pc_next + 4);
Surely split this case out to a new function. And properly form the common,
signed 32-bit offset once before the switch.
> +switch ((ctx->opcode >> 16) & 0x1f) {
>
On 06/20/2018 05:05 AM, Yongbok Kim wrote:
> Add nanoMIPS 32bit instructions
>
> Signed-off-by: Yongbok Kim
> ---
> target/mips/translate.c | 285
> +++-
> 1 file changed, 284 insertions(+), 1 deletion(-)
>
> diff --git a/target/mips/translate.c b/ta
The FPSCR[FI] bit indicates if the last floating point instruction had a result
that was rounded. Each consecutive floating point instruction is suppose to set
this bit to the correct value. What currently happens is this bit is not set as
often as it should be. I have verified that this is the
On 06/22/2018 07:12 AM, Alex Bennée wrote:
> This involves parsing the command line parameter and calling the
> kernel to set the VQ limit. We also add dumping of the register state
> in the main register dump.
>
> Signed-off-by: Alex Bennée
> ---
> risu_reginfo_aarch64.c | 38 ++
On 06/22/2018 07:12 AM, Alex Bennée wrote:
> We also tweak the justification of the rest of the registers so the :
> lines up nicely across the register dump and diff dump.
>
> Signed-off-by: Alex Bennée
>
> ---
> v2
> - include ffr in comparison
> - mild re-factor of preg cmp/diff
> v3
>
On 06/22/2018 07:11 AM, Alex Bennée wrote:
> This allows us to use any new risugen options when generating all our
> test patterns.
>
> Signed-off-by: Alex Bennée
> ---
> contrib/generate_all.sh | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
Reviewed-by: Richard Henders
On 06/22/2018 07:11 AM, Alex Bennée wrote:
> From: Richard Henderson
>
> Signed-off-by: Alex Bennée
> ---
> risugen_arm.pm | 126 +
> 1 file changed, 126 insertions(+)
Signed-off-by: Richard Henderson
r~
On 06/22/2018 07:11 AM, Alex Bennée wrote:
> From: Richard Henderson
>
> Signed-off-by: Alex Bennée
> ---
> risugen_arm.pm | 32 +++-
> 1 file changed, 19 insertions(+), 13 deletions(-)
Ho hum,
Signed-off-by: Richard Henderson
r~
On 06/22/2018 07:11 AM, Alex Bennée wrote:
> This is similar to the approach used by the FP/simd data in so far as
> we generate a block of random data and then load into it. The loading
> is actually done by the current vector length but that is implicit in
> the run anyway.
>
> Signed-off-by: Al
Hello,
On Sun, 24 Jun 2018, Cédric Le Goater wrote:
On 06/24/2018 01:20 PM, BALATON Zoltan wrote:
Rewrite to make it closer to how real device works so that guest OS
drivers can access I2C devices. Previously this was only a hack to
allow U-Boot to get past accessing SPD EEPROMs but to support
> On Jun 24, 2018, at 2:30 PM, Richard Henderson
> wrote:
>
> On 06/24/2018 06:46 AM, Programmingkid wrote:
>>> Even in your referenced PDF, table 3-13, it says that frD is unmodified.
>>
>> Actually it says when FPSCR[ZE] is set is when frD is unmodified. When
>> FPSCR[ZE] is not set it frD'
On 06/24/2018 06:46 AM, Programmingkid wrote:
>> Even in your referenced PDF, table 3-13, it says that frD is unmodified.
>
> Actually it says when FPSCR[ZE] is set is when frD is unmodified. When
> FPSCR[ZE] is not set it frD's sign is determined by an XOR of the signs of
> the operands. I have
On 06/24/2018 01:20 PM, BALATON Zoltan wrote:
> The Sam460ex has an M41T80 serial RTC chip on I2C bus 0 at address 0x68.
>
> Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> hw/ppc/sam460ex.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/ppc/sam
On 06/24/2018 01:20 PM, BALATON Zoltan wrote:
> Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
> of day is implemented. Setting time and RTC alarm are not supported.
>
> Signed-off-by: BALATON Zoltan
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> MAINTAINERS
On 06/24/2018 01:20 PM, BALATON Zoltan wrote:
> Rewrite to make it closer to how real device works so that guest OS
> drivers can access I2C devices. Previously this was only a hack to
> allow U-Boot to get past accessing SPD EEPROMs but to support other
> I2C devices and allow guests to access the
On 06/21/2018 02:12 PM, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi01.c | 42 +++--
> hw/block/pflash_cfi02.c | 18 +-
> hw/block/trace-events | 13 +
> 3 files changed, 37 inse
> On Jun 24, 2018, at 12:18 AM, Richard Henderson
> wrote:
>
> On 06/23/2018 01:17 PM, Programmingkid wrote:
https://www.pdfdrive.net/powerpc-microprocessor-family-the-programming-environments-for-32-e3087633.html
This document has the information on the fdiv. Page 133 has the
On 22 June 2018 at 19:49, Eduardo Habkost wrote:
> The following changes since commit 7ed14cbf3cf083f125c079bd02b3215941853830:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2018-06-22'
> into staging (2018-06-22 17:08:58 +0100)
>
> are available in the Git repository at:
>
>
From: Sameeh Jubran
The defrag.exe tool which is used for executing the fstrim command
on Windows doesn't support retrim for OSes lower than Win8. This
commit handles this case and returns a suitable error.
Output of fstrim before this commit:
{"execute":"guest-fstrim"}
{"return": {"paths": [{"p
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1529716721-28400-1-git-send-email-li...@roeck-us.net
Subject: [Qemu-devel] [PATCH v2] ppc: Fix sam460ex devicetree when booting the
Linux kernel
=== TEST SCRIPT BEGIN ===
#!
Rewrite to make it closer to how real device works so that guest OS
drivers can access I2C devices. Previously this was only a hack to
allow U-Boot to get past accessing SPD EEPROMs but to support other
I2C devices and allow guests to access them we need to model real
device more properly.
Signed-
PPC440 SoCs such as the AMCC 460EX have a DMA controller which is used
by AmigaOS on the sam460ex. Implement the parts used by AmigaOS so it
can get further booting on the sam460ex machine.
Signed-off-by: BALATON Zoltan
---
hw/ppc/ppc440.h| 1 +
hw/ppc/ppc440_uc.c | 215 +++
These are the remaining patches for sam460ex needed to implement RTC
and get AmigaOS to boot. The sm501 patches are also needed but that's
now a separate series. I'd appreciate if this could be reviewed and
merged before the imminent 3.0 freeze.
I think only patch 1/4 (i2c rewrite) is a bit more c
The Sam460ex has an M41T80 serial RTC chip on I2C bus 0 at address 0x68.
Signed-off-by: BALATON Zoltan
---
hw/ppc/sam460ex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index bdc53d2..dc730cc 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@
Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
of day is implemented. Setting time and RTC alarm are not supported.
Signed-off-by: BALATON Zoltan
---
MAINTAINERS | 1 +
default-configs/ppc-softmmu.mak | 1 +
hw/timer/Makefile.objs | 1 +
On Sat, Jun 23, 2018 at 02:18:05PM -0700, Guenter Roeck wrote:
> sam460ex (or at least this emulation) does not support the "ibm,cpm" power
> management. As a result, Linux crashes when trying to access it. Remove
> its device tree node. Also, if/when we boot the Linux kernel directly,
> serial por
Hi,
This series failed build test on s390x host. Please find the details below.
Type: series
Message-id: 20180622192148.178309-1-...@redhat.com
Subject: [Qemu-devel] [PATCH v6 0/2] kvm: limited x86 CPU power management
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under
On 24/06/18 04:55, Michael S. Tsirkin wrote:
On Sat, Jun 23, 2018 at 09:50:28AM +0100, Mark Cave-Ayland wrote:
The current implementation of pci_dev_fw_name() scans through a fixed
set of PCI class descriptions to determine the firmware device name
but in some cases this isn't always appropriat
70 matches
Mail list logo
