If it is a pcie device, check that all devices on the path from
the device to the root complex have ACS enabled, and then the
device will become an iommu_group.
it will have the effect of isolation
Signed-off-by: wlfightup
---
hw/pci-bridge/xio3130_upstream.c | 3 +++
1 file changed, 3 in
On Sun, Aug 14, 2022 at 03:47:49PM +0800, Paul Schlacter wrote:
> If it is a pcie device, check that all devices on the path from
>
> the device to the root complex have ACS enabled, and then the
>
> device will become an iommu_group.
>
> it will have the effect of isolation
>
>
> Signed-off-b
u.git tags/pull-la-20220814
for you to fetch changes up to 1f90ce64fc6043470209f825c7763950ec2067a1:
docs/system/loongarch: Update the LoongArch document (2022-08-13 04:45:03
-0700)
Loongarch d
From: Xiaojuan Yang
1. Add some information about how to boot the LoongArch virt
machine by uefi bios and linux kernel and how to access the
source code or binary file.
2. Move the explanation of LoongArch system emulation in the
target/loongarch/README to docs/system/loongarch/loongson3.rst
Sig
From: WANG Xuerui
Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
command-line option, the latter of which being excessively long and
redundant, hence unwanted. Remove support for consistency with other
targets and simpler code.
Signed-off-by: WANG Xuerui
---
target/loo
From: WANG Xuerui
The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
but it is not the real thing, and at least one feature [1] is missing
that actually made the model incompatible with the real 3A5000. What's
more, the model is currently named "la464", while none of the
mic
From: WANG Xuerui
Much information is already outdated in its current form, not to mention
the hard-to-understand Chinglish. Rewrite to hopefully de-duplicate and
re-organize things, and reflect the latest status of LoongArch at
upstream.
Signed-off-by: WANG Xuerui
---
docs/system/loongarch/lo
From: WANG Xuerui
Also add a header and indentation for each entry, while at it.
Signed-off-by: WANG Xuerui
---
target/loongarch/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index dc233ee209..4663539443 100644
---
Provide a descriptions of the options that control the emulation of option
ROMS for PCIe devices.
Signed-off-by: Heinrich Schuchardt
---
v2:
correct description of rombar property
use romfile= to suppress option ROM loading
---
docs/pcie.txt | 28
1 f
Hi,
Some people are already testing out the 7.1 RCs for the LoongArch
emulation, and have suggested improvements to the CPU model naming
scheme. While assessing the situation I also found the documentation
already out-of-date, in addition to being especially hard to read (for a
Chinese who could *
What's wrong with not disabling the old version?
On Sun, Aug 14, 2022 at 6:48 PM Michael S. Tsirkin wrote:
> On Sun, Aug 14, 2022 at 03:47:49PM +0800, Paul Schlacter wrote:
> > If it is a pcie device, check that all devices on the path from
> >
> > the device to the root complex have ACS enable
ository at:
https://gitlab.com/rth7680/qemu.git tags/pull-la-20220814
for you to fetch changes up to 1f90ce64fc6043470209f825c7763950ec2067a1:
docs/system/loongarch: Update the LoongArch document (2022-08-13 04:45:03
-0700)
On 8/14/22 09:55, WANG Xuerui wrote:
From: WANG Xuerui
Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
command-line option, the latter of which being excessively long and
redundant, hence unwanted. Remove support for consistency with other
targets and simpler code.
Sign
On 8/14/22 09:55, WANG Xuerui wrote:
From: WANG Xuerui
Also add a header and indentation for each entry, while at it.
Signed-off-by: WANG Xuerui
---
target/loongarch/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
On 8/14/22 09:55, WANG Xuerui wrote:
From: WANG Xuerui
The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
but it is not the real thing, ...
The 3A5000 is the SoC, as far as I could find, and the documentation of that says the core
is named the la464.
In general, hig
On Thu, Aug 11, 2022 at 5:06 AM Conor Dooley wrote:
>
> From: Conor Dooley
>
> The reset and poweroff features of the syscon were originally added to
> top level, which is a valid path for a syscon subnode. Subsequently a
> reorganisation was carried out while implementing NUMA in which the
> sub
On Thu, Aug 11, 2022 at 11:05 AM Wilfred Mallawa
wrote:
>
> From: Wilfred Mallawa
>
> This patch adds the `rw1c` functionality to the respective
> registers. The status fields are cleared when the respective
> field is set.
>
> Signed-off-by: Wilfred Mallawa
Reviewed-by: Alistair Francis
Alis
On Sat, Aug 13, 2022 at 8:20 PM Peter Maydell wrote:
>
> On Sat, 13 Aug 2022 at 01:53, Furquan Shaikh wrote:
> > I ran into a problem when I was testing a project (with a microkernel
> > in M-mode and tasks in U-mode) that uses semihosting for debugging.
> > The semihosting worked fine for M-mode
On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote:
>
> From: Conor Dooley
>
> Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot
> entirely is probably not advisable, but it does at least show signs of
> life. Recent Linux kernel versions make use of peripherals that are
> m
On Fri, Aug 12, 2022 at 10:54 AM Wilfred Mallawa
wrote:
>
> From: Wilfred Mallawa
>
> The following patch updates opentitan to match the new configuration,
> as per, lowRISC/opentitan@217a0168ba118503c166a9587819e3811eeb0c0c
>
> Note: with this patch we now skip the usage of the opentitan
> `boot
On Wed, Aug 3, 2022 at 9:34 AM Atish Patra wrote:
>
> With .min_priv_version, additiona priv version check is uncessary
> for mcountinhibit read/write functions.
>
> Reviewed-by: Heiko Stuebner
> Tested-by: Heiko Stuebner
> Signed-off-by: Atish Patra
Reviewed-by: Alistair Francis
Alistair
>
On 14/08/2022 23:08, Alistair Francis wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote:
>> QEMU support for PolarFire SoC seems to be fairly out of date at this
>> point. Running with a r
On Sun, Aug 14, 2022 at 11:59:51PM +0800, Paul Schlacter wrote:
> What's wrong with not disabling the old version?
Old versions have to behave in the same way as they did,
or close enough. Changing that breaks migration between
qemu versions.
>
>
> On Sun, Aug 14, 2022 at 6:48 PM Michael S. Tsi
On Wed, Aug 3, 2022 at 9:33 AM Atish Patra wrote:
>
> The Sscofpmf ('Ss' for Privileged arch and Supervisor-level extensions,
> and 'cofpmf' for Count OverFlow and Privilege Mode Filtering)
> extension allows the perf to handle overflow interrupts and filtering
> support. This patch provides a fra
On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote:
>
> From: Conor Dooley
>
> Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot
> entirely is probably not advisable, but it does at least show signs of
> life. Recent Linux kernel versions make use of peripherals that are
> m
On Mon, Aug 15, 2022 at 8:48 AM wrote:
>
> On 14/08/2022 23:08, Alistair Francis wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote:
> >> QEMU support for PolarFire SoC seems to be
On Fri, Aug 12, 2022 at 12:05 PM Atish Patra wrote:
>
> On Tue, Aug 2, 2022 at 4:33 PM Atish Patra wrote:
> >
> > The latest version of the SBI specification includes a Performance
> > Monitoring
> > Unit(PMU) extension[1] which allows the supervisor to start/stop/configure
> > various PMU event
On Fri, Aug 12, 2022 at 07:03:26PM -0300, Daniel Henrique Barboza wrote:
> David,
>
> On 8/8/22 00:23, David Gibson wrote:
> > On Fri, Aug 05, 2022 at 06:39:29AM -0300, Daniel Henrique Barboza wrote:
> > > At this moment, arm_load_dtb() can free machine->fdt when
> > > binfo->dtb_filename is NULL.
On Fri, Aug 12, 2022 at 07:23:09PM -0300, Daniel Henrique Barboza wrote:
>
>
> On 8/8/22 00:26, David Gibson wrote:
> > On Fri, Aug 05, 2022 at 06:39:38AM -0300, Daniel Henrique Barboza wrote:
> > > The pSeries machine never bothered with the common machine->fdt
> > > attribute. We do all the FDT
From: Wilfred Mallawa
This patch series (note V2) cleans up the ibex_spi driver,
fixes the specified coverity issue,
implements register rw1c functionality and
updates an incorrect register offset.
In V2, the following changes are made.
- New patch [4/4] to isolate the register address offset u
From: Wilfred Mallawa
This patch fixes up minor typos in ibex_spi_host
Signed-off-by: Wilfred Mallawa
Reviewed-by: Alistair Francis
Reviewed-by: Andrew Jones
---
hw/ssi/ibex_spi_host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/ssi/ibex_spi_host.c b/hw/ssi/i
From: Wilfred Mallawa
This patch addresses the coverity issues specified in [1],
as suggested, `FIELD_DP32()`/`FIELD_EX32()` macros have been
implemented to clean up the code.
Patch V2: Style changes have been made as suggested by
Andrew Jones, to promote code readability.
[1] https://www.mail-
From: Wilfred Mallawa
This patch adds the `rw1c` functionality to the respective
registers. The status fields are cleared when the respective
field is set.
Signed-off-by: Wilfred Mallawa
Reviewed-by: Alistair Francis
---
hw/ssi/ibex_spi_host.c | 34 --
From: Wilfred Mallawa
Updates the `EVENT_ENABLE` register to offset `0x34` as per
OpenTitan spec [1].
[1] https://docs.opentitan.org/hw/ip/spi_host/doc/#Reg_event_enable
Signed-off-by: Wilfred Mallawa
---
hw/ssi/ibex_spi_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sat, Aug 13, 2022 at 10:01 PM Anton Kochkov wrote:
>
> * Implement Octal SPI commands based on Micron MT35X series
> * Fix Micron 0x2C-based ID handling (incompatible with Numonyx)
> * Fix Micron configuration registers handling
>
> Signed-off-by: Anton Kochkov
> Resolves: https://gitlab.com/q
On Tue, Aug 9, 2022 at 10:51 PM Cédric Le Goater wrote:
>
> Hello,
>
> On 8/10/22 04:37, Joel Stanley wrote:
> > Hello Shivi,
> >
> > I've added others to cc who may have some input.
> >
> > On Tue, 9 Aug 2022 at 21:38, Shivi Fotedar wrote:
> >>
> >> Hello, we are looking for support for few feat
On Sun, Aug 14, 2022 at 3:04 PM Alistair Francis wrote:
>
> On Sat, Aug 13, 2022 at 8:20 PM Peter Maydell
> wrote:
> >
> > On Sat, 13 Aug 2022 at 01:53, Furquan Shaikh wrote:
> > > I ran into a problem when I was testing a project (with a microkernel
> > > in M-mode and tasks in U-mode) that us
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on highest RAM address. However, they can be disabled
in several cases.
(1) One specific high memory region is disabled by developer by
toggling
This introduces variable 'region_base' for the base address of
the specific high memory region. It's the preparatory to improve
the address assignment for high memory region in next patch.
No functional change intended.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 10 +-
1 file changed
This renames variable 'size' to 'region_size' in virt_set_memmap().
It's counterpart to 'region_base', which will be introducded in
next patch.
No functional change intended.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --g
The logic to assign high memory region's address in virt_set_memmap()
is independent. Lets move the logic to virt_set_high_memmap() helper.
"each device" is replaced by "each region" in the comments.
No functional change intended.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 92 +++
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on highest RAM address. However, they can be disabled
in several cases.
(1) One specific high memory region is disabled by developer by
toggling vms-
42 matches
Mail list logo