On Wed, Dec 30, 2020 at 3:42 PM Sylvain Pelissier
wrote:
>
> Target description is not currently implemented in RISC-V architecture. Thus
> GDB won't set it properly when attached. The patch implements the target
> description response.
>
> Signed-off-by: Sylvain Pelissier
> ---
> target/riscv
Target description is not currently implemented in RISC-V architecture.
Thus GDB won't set it properly when attached. The patch implements the
target description response.
Signed-off-by: Sylvain Pelissier
---
target/riscv/cpu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/t
On 2020/12/29 上午10:56, Zhang, Chen wrote:
I think we can start form COLO. To avoid QMP compatibility issues, I would
like to add the n tuple and wildcard support now.
OK, I will do this job in next version.
For the QMP compatibility issues, please give me a demo of what we want to see,
Like s
On Tue, Dec 29, 2020 at 05:56:15PM +, Mark Cave-Ayland wrote:
> The heathrow PIC is located within the macio device on real hardware so make
> it
> a child of the macio-oldworld device. This also removes the need for setting
> and
> checking a separate PIC object property link on the macio-ol
On Tue, Dec 29, 2020 at 05:56:14PM +, Mark Cave-Ayland wrote:
> In order to move the heathrow PIC to the macio device, the PCI bus needs to be
> initialised before the macio device and also before wiring the PIC IRQs.
>
> Signed-off-by: Mark Cave-Ayland
Reviewed-by: David Gibson
> ---
> h
... but you also mentioned strrchr, and there is a qemu bug there. The
REV (predicate) instruction doesn't seem to be doing the right thing --
input 0x1 -> output 0x8000 which is not correct for the current
vector length (64).
** Changed in: qemu
Status: Invalid => Confirmed
--
You r
Hi Sylvain,
On Wed, Dec 30, 2020 at 12:37 AM Sylvain Pelissier
wrote:
>
> Thank you for your remark here is the new patch:
This should not be put into the commit message.
Previous commit message is missing.
>
> Signed-off-by: Sylvain Pelissier
> ---
> target/riscv/cpu.c | 13 +
>
Similar to the SMBus io registers there is a power management io range
that's set via similar base address reg and enable bit. Some handling
of this was already there but with several problems: using the wrong
registers and bits, wrong size range, not acually updating mapping and
handling reset cor
The vt82c686b-pm model can be shared between VT82C686B and VT8231. The
only difference between the two is the device id in what we model so
make an abstract via-pm model by renaming appropriately and add types
for vt82c686b-pm and vt8231-pm based on it.
Signed-off-by: BALATON Zoltan
---
hw/isa/v
Rename local variable holding object state for readability and
consistency.
Signed-off-by: BALATON Zoltan
---
hw/isa/vt82c686.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 02d6759c00..2633cfe7dc
The superio memory region holds the io space index/data registers used
to access the superio config registers that are implemented in struct
SuperIOConfig. To keep these related things together move the memory
region to SuperIOConfig and rename it accordingly.
Also remove the unused data member of
Move lines around so that object definitions become consecutive and
not scattered around. This brings functions belonging to an object
together so it's clearer what's defined and what parts belong to which
object.
Signed-off-by: BALATON Zoltan
---
hw/isa/vt82c686.c | 279 +++-
Use less confusing naming for superio config register handling related
parts that makes it clearer what belongs to this part.
Signed-off-by: BALATON Zoltan
---
hw/isa/vt82c686.c | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/
The base address of the SMBus io ports and its enabled status is set
by registers in the PCI config space but this was not correctly
emulated. Instead the SMBus registers were mapped on realize to the
base address set by a property to the address expected by fuloong2e
firmware.
Fix the base and co
This is continuing cleaning up the vt82c686b model with the aim to add
vt8231 emulation without too much duplication, reusing or fixing the
existing model where possible. (DISCALIMER: It does not aim to fix all
existing bugs or make the model perfectly emulate the real chip.) This
series continues
The program is buggy.
The first instruction sets the stack to 0x2002,
but that address is not mapped.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x01 0x0800 0x0800 0x0025c 0x0025c R E 0x1
LOAD 0x02000
On Tue, 29 Dec 2020 19:04:58 +0100
Philippe Mathieu-Daudé wrote:
> On 12/29/20 6:29 PM, Igor Mammedov wrote:
> > It is not safe to pretend that emulated NVDIMM supports
> > persistence while backend actually failed to enable it
> > and used non-persistent mapping as fall back.
> > Instead of fall
Bah. The code at label 9 does not match the comment.
Best fixed thus.
** Patch added: "z.patch"
https://bugs.launchpad.net/qemu/+bug/1908551/+attachment/5447736/+files/z.patch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
http
On 12/29/20 5:50 AM, Cho, Yu-Chen wrote:
Add build-system-opensuse jobs and opensuse-leap.docker dockerfile.
Use openSUSE Leap 15.2 container image in the gitlab-CI.
Signed-off-by: Cho, Yu-Chen
---
v4:
Add package tar and fix python3 version from 3.8 to 3.6
Add acceptance-system-opensuse back
FWIW, as I think on this further, this probably isn't the
ideal fix -- I recall now that INCP is a "reduction" class
instruction and thus its overhead is non-trivial.
We could instead add an integer min operation at label 9,
which is outside of the main loop.
--
You received this bug notificatio
I don't know why the test worked previously, and I did not
investigate, but as far as I can tell, the test is broken.
The test is returning a value >= maxlen because it it using
the wrong increment. Fixed thus.
** Patch added: "z.patch"
https://bugs.launchpad.net/qemu/+bug/1908551/+attachme
On 12/29/20 6:29 PM, Igor Mammedov wrote:
> It is not safe to pretend that emulated NVDIMM supports
> persistence while backend actually failed to enable it
> and used non-persistent mapping as fall back.
> Instead of falling-back, QEMU should be more strict and
> error out with clear message that
The heathrow PIC is located within the macio device on real hardware so make it
a child of the macio-oldworld device. This also removes the need for setting and
checking a separate PIC object property link on the macio-oldworld device which
currently causes the automated QOM introspection tests to
This condition will have already been caught when wiring the heathrow PIC
IRQs to the CPU.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: David Gibson
---
hw/ppc/mac_oldworld.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 04f98a4d81.
Now that all of the object property links to the heathrow PIC and OpenPIC have
been removed from the macio devices, it is safe to allow the macio-oldworld
and macio-neworld devices to be marked as user_creatable.
Signed-off-by: Mark Cave-Ayland
---
hw/misc/macio/macio.c | 2 --
1 file changed, 2
In order to move the OpenPIC device to the macio device, the PCI bus needs to be
initialised before the macio device and also before wiring the OpenPIC IRQs.
Signed-off-by: Mark Cave-Ayland
---
hw/ppc/mac_newworld.c | 46 ---
1 file changed, 26 insertions(
The OpenPIC device is located within the macio device on real hardware so make
it
a child of the macio-newworld device. This also removes the need for setting and
checking a separate PIC object property link on the macio-newworld device which
currently causes the automated QOM introspection tests
This patchset follows on from the dicussion at
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02630.html
where the user_creatable flag for the macio devices was set back to false just
before the 5.2 release.
The underlying cause was that the PIC object property links were not being set
This both allows the wiring to be done as Ben suggested in his original comment
in
gpio.c and also enables the OpenPIC object property link to be removed.
Signed-off-by: Mark Cave-Ayland
---
hw/misc/macio/gpio.c | 24 +---
hw/misc/macio/macio.c| 12 +++---
In order to move the heathrow PIC to the macio device, the PCI bus needs to be
initialised before the macio device and also before wiring the PIC IRQs.
Signed-off-by: Mark Cave-Ayland
---
hw/ppc/mac_oldworld.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
It is not safe to pretend that emulated NVDIMM supports
persistence while backend actually failed to enable it
and used non-persistent mapping as fall back.
Instead of falling-back, QEMU should be more strict and
error out with clear message that it's not supported.
So if user asks for persistence
Thank you for your remark here is the new patch:
Signed-off-by: Sylvain Pelissier
---
target/riscv/cpu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 254cd83f8b..ed4971978b 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.
> On Dec 23, 2020, at 1:49 PM, Elena Ufimtseva
> wrote:
>
> On Wed, Dec 23, 2020 at 03:01:24PM +0400, Marc-André Lureau wrote:
>> Hi
>>
>> On Wed, Dec 23, 2020 at 10:45 AM wrote:
>>
>>> From: Jagannathan Raman
>>>
>>> Runs the Avocado acceptance test to check if a
>>> remote lsi53c895a d
The gtk window is not limited for -display but also for compatmonitor /
serial /paralel, but when -spice is used, the gtk window does not show
at all. While you can force the window to show with -display gtk, but
the *side effect* is the vga will be wired/connected to the gtk window
(which seems to
On 12/14/20 9:50 PM, Eduardo Habkost wrote:
> This includes code previously submitted[1] by Daniel P. Berrangé
> to add a "smbios-ep" machine property on PC.
>
> SMBIOS 3.0 is necessary to support more than ~720 VCPUs, as a
> large number of VCPUs can easily hit the table size limit of
> SMBIOS 2.
On 28/12/2020 07:08, David Gibson wrote:
On Sat, Dec 19, 2020 at 10:42:25AM +, Mark Cave-Ayland wrote:
Really needs a commit message.
This is currently explained in the cover letter: it's moving the PIC to the macio
device as per real hardware (which also nicely removes the need for comp
On Tue, 29 Dec 2020, Mark Cave-Ayland wrote:
On 29/12/2020 12:01, BALATON Zoltan via wrote:
Fortunately with PCI_CLASS_PROG at 0x8a Linux will keep the VIA IDE in
compatible mode and not attempt to switch to native mode: therefore if you
keep this as-is and add the legacy IDE ioports back, that
On 12/29/20 2:02 PM, Jiaxun Yang wrote:
> 在 2020/12/29 18:47, Philippe Mathieu-Daudé 写道:
>> On 12/29/20 6:26 AM, Jiaxun Yang wrote:
>>> 在 2020/12/29 上午11:26, BALATON Zoltan 写道:
Hello,
While continuing with part two of my vt82c686b clean ups I've tried to
implement SMBus IO base
On 28/12/2020 07:07, David Gibson wrote:
On Sat, Dec 19, 2020 at 10:42:24AM +, Mark Cave-Ayland wrote:
Signed-off-by: Mark Cave-Ayland
Looks correct, but it could really do with a rationale in the commit message.
It's just changing the order of initialisation since as the plan is to mo
On Wed, 23 Dec 2020 17:08:34 +0800
Jiahui Cen wrote:
subj
s/by default//
s/enable/compile/
> PXB is now supported on ARM, so let's enable it by default.
s/it by default/for arm_virt machine/
s/enable/compile/
>
> Signed-off-by: Jiahui Cen
> ---
> hw/pci-bridge/Kconfig | 2 +-
> 1 file changed
On Wed, 23 Dec 2020 17:08:33 +0800
Jiahui Cen wrote:
> The overlap check of IO resource window would fail when Linux kernel
> registers an IO resource [b, c) earlier than another resource [a, b).
> Though this incorrect check could be fixed by [1], it would be better to
> append pxb devs into DSD
On Wed, 23 Dec 2020 17:08:31 +0800
Jiahui Cen wrote:
> There may be some differences in pci resource assignment between guest os
> and firmware.
>
> Eg. A Bridge with Bus [d2]
> -+-[:d2]---01.0-[d3]01.0
>
> where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref)
On Wed, 23 Dec 2020 17:08:30 +0800
Jiahui Cen wrote:
> AML needs Address Translation offset to describe how a bridge translates
> addresses accross the bridge when using an address descriptor, and
> especially on ARM, the translation offset of pio resource is usually
> non zero.
could you point
On Mon, 14 Dec 2020 15:50:28 -0500
Eduardo Habkost wrote:
> This prepares for exposing the SMBIOS entry point type as a
> machine property on x86.
>
> Based on a patch from Daniel P. Berrangé.
>
> Signed-off-by: Daniel P. Berrangé
> Signed-off-by: Eduardo Habkost
Reviewed-by: Igor Mammedov
On Mon, 14 Dec 2020 15:50:27 -0500
Eduardo Habkost wrote:
> Rename the enums to match the naming style used by QAPI. This
> will allow us to more easily move the enum to the QAPI schema
> later.
>
> Based on portions of a patch submitted by Daniel P. Berrangé.
>
> Signed-off-by: Daniel P. Berr
On Mon, 14 Dec 2020 15:50:26 -0500
Eduardo Habkost wrote:
> This includes code previously submitted[1] by Daniel P. Berrangé
> to add a "smbios-ep" machine property on PC.
>
> SMBIOS 3.0 is necessary to support more than ~720 VCPUs, as a
> large number of VCPUs can easily hit the table size limi
在 2020/12/29 18:47, Philippe Mathieu-Daudé 写道:
On 12/29/20 6:26 AM, Jiaxun Yang wrote:
在 2020/12/29 上午11:26, BALATON Zoltan 写道:
Hello,
While continuing with part two of my vt82c686b clean ups I've tried to
implement SMBus IO base configuration in the vt82c686b-pm part that
I've already done
On 29/12/2020 12:01, BALATON Zoltan via wrote:
Fortunately with PCI_CLASS_PROG at 0x8a Linux will keep the VIA IDE in compatible
mode and not attempt to switch to native mode: therefore if you keep this as-is and
add the legacy IDE ioports back, that just leaves the problem with BAR4 (BMDMA). I
On Tue, 29 Dec 2020, Mark Cave-Ayland wrote:
On 28/12/2020 20:50, BALATON Zoltan via wrote:
I think leaving the legacy ports enabled is a bad idea for at least two
reasons: 1) It may clash with other io ports on other machines, e.g. I'm
not sure on PPC where firmware or OS does not expect to se
On Tue, 29 Dec 2020, Mark Cave-Ayland wrote:
On 28/12/2020 20:50, BALATON Zoltan via wrote:
diff --git a/hw/ide/via.c b/hw/ide/via.c
index be09912b33..7d54d7e829 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -26,6 +26,7 @@
#include "qemu/osdep.h"
#include "hw/pci/pci.h"
+#include "hw/qde
On 28/12/2020 20:50, BALATON Zoltan via wrote:
I think leaving the legacy ports enabled is a bad idea for at least two reasons: 1)
It may clash with other io ports on other machines, e.g. I'm not sure on PPC where
firmware or OS does not expect to see legacy ISA ports won't map some io BAR of a
On Tue, 29 Dec 2020, Philippe Mathieu-Daudé wrote:
I think this casued problems before because if it's not set to 0x8a
(legacy) at start then guests may assume it's already switched to native
mode by firmware and won't program the BARs and it will not work. This
way, even if it looks odd all gues
On Wed, 23 Dec 2020 23:56:30 +0200
Marian Posteuca wrote:
> Thanks for the thorough review.
>
> Igor Mammedov writes:
> > On Tue, 22 Dec 2020 13:33:53 +0200
> > Marian Posteuca wrote:
> >
> > I see defaults are now initialized in pcmc->oem_[table_]id fields,
> > and sometimes used from there,
On 28/12/2020 20:50, BALATON Zoltan via wrote:
diff --git a/hw/ide/via.c b/hw/ide/via.c
index be09912b33..7d54d7e829 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -26,6 +26,7 @@
#include "qemu/osdep.h"
#include "hw/pci/pci.h"
+#include "hw/qdev-properties.h"
#include "migration/vmstate
On Tue, 29 Dec 2020, Philippe Mathieu-Daudé wrote:
On 12/29/20 6:26 AM, Jiaxun Yang wrote:
在 2020/12/29 上午11:26, BALATON Zoltan 写道:
Hello,
While continuing with part two of my vt82c686b clean ups I've tried to
implement SMBus IO base configuration in the vt82c686b-pm part that
I've already don
On 12/28/20 9:50 PM, BALATON Zoltan via wrote:
> On Mon, 28 Dec 2020, Mark Cave-Ayland wrote:
>> On 27/12/2020 22:13, BALATON Zoltan via wrote:
>>
>>> From: Guenter Roeck
>>>
>>> The IDE legacy mode emulation has been removed in commit 4ea98d317eb
>>> ("ide/via: Implement and use native PCI IDE mo
On 12/28/20 8:30 PM, Mark Cave-Ayland wrote:
> On 27/12/2020 22:13, BALATON Zoltan wrote:
>
>> We'll need a flag for implementing some device specific behaviour in
>> via-ide but we already have a currently CMD646 specific field that can
>> be repurposed for this and leave room for further flags i
On 12/29/20 6:26 AM, Jiaxun Yang wrote:
> 在 2020/12/29 上午11:26, BALATON Zoltan 写道:
>> Hello,
>>
>> While continuing with part two of my vt82c686b clean ups I've tried to
>> implement SMBus IO base configuration in the vt82c686b-pm part that
>> I've already done for vt8231 for pegasos2 and it should
On 26/12/2020 10.06, John Paul Adrian Glaubitz wrote:
Hello!
On 12/26/20 9:39 AM, Thomas Huth wrote:
the problem is not that the target CPU is old, but rather that according to the
(former?) maintainer, there are no users left:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.ht
Add build-system-opensuse jobs and opensuse-leap.docker dockerfile.
Use openSUSE Leap 15.2 container image in the gitlab-CI.
Signed-off-by: Cho, Yu-Chen
---
v4:
Add package tar and fix python3 version from 3.8 to 3.6
Add acceptance-system-opensuse back.
v3:
Drop the "acceptance-system-opensuse"
Hi Wainer,
On Mon, 2020-12-28 at 15:02 -0300, Wainer dos Santos Moschetta wrote:
> Hi,
>
> On 12/24/20 5:59 AM, Cho, Yu-Chen wrote:
> > Add build-system-opensuse jobs and opensuse-leap.docker dockerfile.
> > Use openSUSE Leap 15.2 container image in the gitlab-CI.
> >
> > Signed-off-by: Cho, Yu-
61 matches
Mail list logo
