On 2023/11/01 15:38, Michael S. Tsirkin wrote:
On Wed, Nov 01, 2023 at 01:50:00PM +0900, Akihiko Odaki wrote:
We had another discussion regarding migration for patch "virtio-net: Do not
clear VIRTIO_NET_F_HASH_REPORT". It does change the runtime behavior so we
need to take migration into account
On Tue, Oct 31, 2023 at 05:39:03PM -0300, Daniel Henrique Barboza wrote:
> We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
> comes with a lot of defaults. This is fine for most regular uses but
> it's not suitable when more control of what is actually loaded in the
> CPU is re
On Wed, Nov 01, 2023 at 05:35:50PM +0900, Akihiko Odaki wrote:
> On 2023/11/01 15:38, Michael S. Tsirkin wrote:
> > On Wed, Nov 01, 2023 at 01:50:00PM +0900, Akihiko Odaki wrote:
> > > We had another discussion regarding migration for patch "virtio-net: Do
> > > not
> > > clear VIRTIO_NET_F_HASH_R
On Tue, Oct 31, 2023 at 05:39:05PM -0300, Daniel Henrique Barboza wrote:
> zic64b is defined in the RVA22U64 profile [1] as a named feature for
> "Cache blocks must be 64 bytes in size, naturally aligned in the address
> space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64
> profile
On 2023/11/01 18:09, Michael S. Tsirkin wrote:
On Wed, Nov 01, 2023 at 05:35:50PM +0900, Akihiko Odaki wrote:
On 2023/11/01 15:38, Michael S. Tsirkin wrote:
On Wed, Nov 01, 2023 at 01:50:00PM +0900, Akihiko Odaki wrote:
We had another discussion regarding migration for patch "virtio-net: Do no
On Tue, Oct 31, 2023 at 05:39:15PM -0300, Daniel Henrique Barboza wrote:
> Enabling a profile and then disabling some of its mandatory extensions
> is a valid use. It can be useful for debugging and testing. But the
> common expected use of enabling a profile is to enable all its mandatory
> extens
On Tue, Oct 31, 2023 at 05:39:16PM -0300, Daniel Henrique Barboza wrote:
> Expose all profile flags for all CPUs when executing
> query-cpu-model-expansion. This will allow callers to quickly determine
> if a certain profile is implemented by a given CPU. This includes
> vendor CPUs - the fact that
On Tue, Oct 31, 2023 at 05:39:02PM -0300, Daniel Henrique Barboza wrote:
> Our current logic in get/setters of MISA and multi-letter extensions
> works because we have only 2 CPU types, generic and vendor, and by using
> "!generic" we're implying that we're talking about vendor CPUs. When adding
>
On Tue, Oct 31, 2023 at 05:39:01PM -0300, Daniel Henrique Barboza wrote:
> We want to add a new CPU type for bare CPUs that will inherit specific
> traits of the 2 existing types:
>
> - it will allow for extensions to be enabled/disabled, like generic
> CPUs;
>
> - it will NOT inherit defaults,
On Tue, Oct 31, 2023 at 03:03:50PM -0400, Peter Xu wrote:
> On Wed, Oct 25, 2023 at 11:07:33AM -0300, Fabiano Rosas wrote:
> > >> +static int parse_ramblock_fixed_ram(QEMUFile *f, RAMBlock *block,
> > >> ram_addr_t length)
> > >> +{
> > >> +g_autofree unsigned long *bitmap = NULL;
> > >> +
On 11/1/23 06:02, Andrew Jones wrote:
On Tue, Oct 31, 2023 at 05:39:03PM -0300, Daniel Henrique Barboza wrote:
We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
comes with a lot of defaults. This is fine for most regular uses but
it's not suitable when more control of what
On Tue, Oct 31, 2023 at 04:05:46PM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé writes:
>
> > On Tue, Oct 31, 2023 at 12:52:41PM -0300, Fabiano Rosas wrote:
> >> Daniel P. Berrangé writes:
> >> >
> >> > I guess I'm not seeing the problem still. A single FD is passed across
> >> > from libvi
On Wed, Nov 01, 2023 at 06:27:02AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 11/1/23 06:02, Andrew Jones wrote:
> > On Tue, Oct 31, 2023 at 05:39:03PM -0300, Daniel Henrique Barboza wrote:
> > > We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
> > > comes with a lot of d
19.09.2023 19:57, Andrey Drobyshev via wrote:
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite fo
31.07.2023 12:10, Akihiko Odaki:
A build of GCC 13.2 will have stack protector enabled by default if it was
configured with --enable-default-ssp option. For such a compiler, it is
necessary to explicitly disable stack protector when linking without
standard libraries.
This is a tree-wide change
On Tue, Oct 31, 2023 at 03:46:01PM +0100, Anthony Harivel wrote:
> The function qio_channel_get_peercred() returns a pointer to the
> credentials of the peer process connected to this socket.
>
> This credentials structure is defined in as follows:
>
> struct ucred {
> pid_t pid;/* Pro
On Tue, Oct 31, 2023 at 03:46:02PM +0100, Anthony Harivel wrote:
> Introduce a privileged helper to access RAPL MSR.
>
> The privileged helper tool, qemu-vmsr-helper, is designed to provide
> virtual machines with the ability to read specific RAPL (Running Average
> Power Limit) MSRs without requi
On Tue, 24 Oct 2023, BALATON Zoltan wrote:
These are some small clean ups for target/ppc/excp_helper.c trying to
make this code a bit simpler. No functional change is intended. This
series was submitted before but only partially merged due to freeze
and conflicting series os thia was postponed th
On Tue, 24 Oct 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode switching for PCI
IDE controllers and updates the via-ide device to use it.
This is needed for my amigaone machine to boot (as that uses the legacy
mode of this controller) so is somebod
On Tue, Oct 31, 2023 at 03:46:02PM +0100, Anthony Harivel wrote:
> Introduce a privileged helper to access RAPL MSR.
>
> The privileged helper tool, qemu-vmsr-helper, is designed to provide
> virtual machines with the ability to read specific RAPL (Running Average
> Power Limit) MSRs without requi
Hi Alex,
On Tue, Oct 31, 2023 at 12:02:03PM +, Alex Bennée wrote:
>
> Hi All,
>
> Since 8.1 we enabled the FEAT_RME CPU feature to allow for Arm CCA
> guests to be run under QEMU's Arm emulation. While this is enough for
> pure software guests eventually we would want to support modelling
>
On Tue, 31 Oct 2023 at 18:45, Kevin Wolf wrote:
> Am 16.10.2023 um 13:58 hat Michael Tokarev geschrieben:
> > Almost everyone mentions -blockdev as a replacement for -drive.
>
> More specifically for -drive if=none. I honestly don't know many common
> use cases for that one.
One use case for it i
On Tue, Oct 31, 2023 at 03:46:03PM +0100, Anthony Harivel wrote:
> Starting with the "Sandy Bridge" generation, Intel CPUs provide a RAPL
> interface (Running Average Power Limit) for advertising the accumulated
> energy consumption of various power domains (e.g. CPU packages, DRAM,
> etc.).
>
> T
> On 31-Oct-2023, at 9:13 PM, Philippe Mathieu-Daudé wrote:
>
> On 27/9/23 17:12, Peter Maydell wrote:
>> Convert docs/specs/vmgenid.txt to rST format.
>> Signed-off-by: Peter Maydell
>> ---
>> MAINTAINERS| 2 +-
>> docs/specs/index.rst | 1 +
>> docs/specs/vmgenid.rst | 24
Daniel P. Berrangé writes:
> On Tue, Oct 31, 2023 at 04:05:46PM -0300, Fabiano Rosas wrote:
>> Daniel P. Berrangé writes:
>>
>> > On Tue, Oct 31, 2023 at 12:52:41PM -0300, Fabiano Rosas wrote:
>> >> Daniel P. Berrangé writes:
>> >> >
>> >> > I guess I'm not seeing the problem still. A single
On Wed, Nov 01, 2023 at 09:16:33AM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé writes:
>
> >
> > So the problem with add-fd is that when requesting a FD, the monitor
> > code masks flags with O_ACCMODE. What if we extended it such that
> > the monitor masked with O_ACCMODE | O_DIRECT.
> >
>
Daniel P. Berrangé writes:
> On Wed, Nov 01, 2023 at 09:16:33AM -0300, Fabiano Rosas wrote:
>> Daniel P. Berrangé writes:
>>
>> >
>> > So the problem with add-fd is that when requesting a FD, the monitor
>> > code masks flags with O_ACCMODE. What if we extended it such that
>> > the monitor ma
This series adds basic support for message-based DMA in qemu's vfio-user
server. This is useful for cases where the client does not provide file
descriptors for accessing system memory via memory mappings. My motivating use
case is to hook up device models as PCIe endpoints to a hardware design. Th
Instead of using a single global bounce buffer, give each AddressSpace
its own bounce buffer. The MapClient callback mechanism moves to
AddressSpace accordingly.
This is in preparation for generalizing bounce buffer handling further
to allow multiple bounce buffers, with a total allocation limit
c
Wire up support for DMA for the case where the vfio-user client does not
provide mmap()-able file descriptors, but DMA requests must be performed
via the VFIO-user protocol. This installs an indirect memory region,
which already works for pci_dma_{read,write}, and pci_dma_map works
thanks to the ex
When DMA memory can't be directly accessed, as is the case when
running the device model in a separate process without shareable DMA
file descriptors, bounce buffering is used.
It is not uncommon for device models to request mapping of several DMA
regions at the same time. Examples include:
* net
Brings in assorted bug fixes. The following are of particular interest
with respect to message-based DMA support:
* bb308a2 "Fix address calculation for message-based DMA"
Corrects a bug in DMA address calculation.
* 1569a37 "Pass server->client command over a separate socket pair"
Adds suppo
PCI config space is little-endian, so on a big-endian host we need to
perform byte swaps for values as they are passed to and received from
the generic PCI config space access machinery.
Signed-off-by: Mattias Nissler
---
hw/remote/vfio-user-obj.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating
Steve Sistare writes:
> Signed-off-by: Steve Sistare
> ---
> tests/qtest/migration-test.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
> index e1c1105..de29fc5 100644
> --- a/tests/qtest/migrati
There are a number of things that are broken on the test currently so
lets fix that up:
- replace retired Debian kernel for tuxrun_baseline one
- remove "detected repeat instructions test" since ea185a55
- log total counted instructions/memory accesses
Signed-off-by: Alex Bennée
---
tests
On 11/1/2023 9:34 AM, Fabiano Rosas wrote:
> Steve Sistare writes:
>
>> Signed-off-by: Steve Sistare
>> ---
>> tests/qtest/migration-test.c | 27 +++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
>> ind
Eiichi Tsukata writes:
> FYI: The EINVAL in vmx_set_nested_state() is caused by the following
> condition:
> * vcpu->arch.hflags == 0
> * kvm_state->hdr.vmx.smm.flags == KVM_STATE_NESTED_SMM_VMXON
This is a weird state indeed,
'vcpu->arch.hflags == 0' means we're not in SMM and not in guest mo
Fix a race situation for global variable dirtylimit_state.
Also, replace usleep by g_usleep to increase platform
accessibility to the sleep function.
Signed-off-by: Hyman Huang
Reviewed-by: Fabiano Rosas
Message-Id:
---
system/dirtylimit.c | 20 ++--
1 file changed, 14 insert
Add migration dirty-limit capability test if kernel support
dirty ring.
Migration dirty-limit capability introduce dirty limit
capability, two parameters: x-vcpu-dirty-limit-period and
vcpu-dirty-limit are introduced to implement the live
migration with dirty limit.
The test case does the followi
Checking if dirty limit is in service is done by the
dirtylimit_query_all function, drop the reduplicative
check in the qmp_query_vcpu_dirty_limit function.
Signed-off-by: Hyman Huang
Reviewed-by: Fabiano Rosas
Message-Id:
<31384f768279027560ab952ebc2bbff1ddb62531.1697815117.git.yong.hu...@smar
v3:
- do nothing but rebase on master
v2:
- rebase on master.
- fix the document typo.
v1:
This is a miscellaneous patchset for dirtylimit that contains
the following parts:
1. dirtylimit module: fix for a race situation and
replace usleep by g_usleep.
2. migration test: add dirtylimit test c
On Wed, Nov 01, 2023 at 09:26:46AM +, Daniel P. Berrangé wrote:
> On Tue, Oct 31, 2023 at 03:03:50PM -0400, Peter Xu wrote:
> > On Wed, Oct 25, 2023 at 11:07:33AM -0300, Fabiano Rosas wrote:
> > > >> +static int parse_ramblock_fixed_ram(QEMUFile *f, RAMBlock *block,
> > > >> ram_addr_t length)
On 11/1/23 11:20, Daniel P. Berrangé wrote:
On Tue, Oct 31, 2023 at 03:46:01PM +0100, Anthony Harivel wrote:
The function qio_channel_get_peercred() returns a pointer to the
credentials of the peer process connected to this socket.
This credentials structure is defined in as follows:
struct u
Currently, guestperf does not cover the dirty-limit
migration, support this feature.
Note that dirty-limit requires 'dirty-ring-size' set.
To enable dirty-limit, setting x-vcpu-dirty-limit-period
as 500ms and x-vcpu-dirty-limit as 10MB/s:
$ ./tests/migration/guestperf.py \
--dirty-ring-size 4
On Wed, Nov 01, 2023 at 10:21:07AM -0400, Peter Xu wrote:
> On Wed, Nov 01, 2023 at 09:26:46AM +, Daniel P. Berrangé wrote:
> > On Tue, Oct 31, 2023 at 03:03:50PM -0400, Peter Xu wrote:
> > > On Wed, Oct 25, 2023 at 11:07:33AM -0300, Fabiano Rosas wrote:
> > > > >> +static int parse_ramblock_fi
On Mon, Oct 23, 2023 at 05:36:02PM -0300, Fabiano Rosas wrote:
> We'll need to set the shadow_bmap bits from outside ram.c soon and
> TARGET_PAGE_BITS is poisoned, so add a wrapper to it.
>
> Signed-off-by: Fabiano Rosas
Merge this into existing patch to add ram.c usage?
> ---
> migration/ram.
Dirty ring size configuration is not supported by guestperf tool.
Introduce dirty-ring-size (ranges in [1024, 65536]) option so
developers can play with dirty-ring and dirty-limit feature easier.
To set dirty ring size with 4096 during migration test:
$ ./tests/migration/guestperf.py --dirty-ring
On 10/31/23 15:46, Anthony Harivel wrote:
+
+static uint64_t vmsr_read_msr(uint32_t reg, unsigned int cpu_id)
+{
+int fd;
+uint64_t data;
+
+char path[MAX_PATH_LEN];
+snprintf(path, MAX_PATH_LEN, "/dev/cpu/%u/msr", cpu_id);
If you allow any CPU here, the thread id is really unus
On 10/31/23 15:46, Anthony Harivel wrote:
+/* Get QEMU PID*/
+pid = getpid();
This should be gettid(), or perhaps a VCPU thread's TID.
+/* Those MSR values should not change as well */
+vmsr->msr_unit = vmsr_read_msr(MSR_RAPL_POWER_UNIT, 0, pid,
+
The dirty limit feature has been introduced since the 8.1
QEMU release but has not reflected in the document, add a
section for that.
Signed-off-by: Hyman Huang
Reviewed-by: Fabiano Rosas
Message-Id:
<36194a8a23d937392bf13d9fff8e898030c827a3.1697815117.git.yong.hu...@smartx.com>
---
docs/devel
On Wed, Nov 01, 2023 at 02:28:24PM +, Daniel P. Berrangé wrote:
> On Wed, Nov 01, 2023 at 10:21:07AM -0400, Peter Xu wrote:
> > On Wed, Nov 01, 2023 at 09:26:46AM +, Daniel P. Berrangé wrote:
> > > On Tue, Oct 31, 2023 at 03:03:50PM -0400, Peter Xu wrote:
> > > > On Wed, Oct 25, 2023 at 11:
Currently we emit GUEST_PANICKED event in case kvm_vcpu_ioctl() returns
KVM_EXIT_SYSTEM_EVENT with the event type KVM_SYSTEM_EVENT_CRASH. Let's
extend this scenario and emit GUEST_PANICKED in case of an abnormal KVM
exit. That's a natural thing to do since in this case guest is no
longer operatio
On Wed, Oct 25, 2023 at 10:39:58AM +0100, Daniel P. Berrangé wrote:
> If I'm reading the code correctly the new format has some padding
> such that each "ramblock pages" region starts on a 1 MB boundary.
>
> eg so we get:
>
>
> | ramblock 1 header|
>
On 11/1/23 11:50, Michael Tokarev wrote:
> 19.09.2023 19:57, Andrey Drobyshev via wrote:
>> In case when we're rebasing within one backing chain, and when target
>> image
>> is larger than old backing file, bdrv_is_allocated_above() ends up
>> setting
>> *pnum = 0. As a result, target offset isn't
On Wed, Nov 01, 2023 at 11:23:37AM -0400, Peter Xu wrote:
> On Wed, Oct 25, 2023 at 10:39:58AM +0100, Daniel P. Berrangé wrote:
> > If I'm reading the code correctly the new format has some padding
> > such that each "ramblock pages" region starts on a 1 MB boundary.
> >
> > eg so we get:
> >
> >
On Tue, Oct 31, 2023 at 08:18:06PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Mon, Oct 23, 2023 at 05:36:00PM -0300, Fabiano Rosas wrote:
> >> Currently multifd does not need to have knowledge of pages on the
> >> receiving side because all the information needed is within the
> >> p
On 11/1/23 16:23, Andrey Drobyshev wrote:
Currently we emit GUEST_PANICKED event in case kvm_vcpu_ioctl() returns
KVM_EXIT_SYSTEM_EVENT with the event type KVM_SYSTEM_EVENT_CRASH. Let's
extend this scenario and emit GUEST_PANICKED in case of an abnormal KVM
exit. That's a natural thing to do si
On Wed, Nov 01, 2023 at 03:52:18PM +, Daniel P. Berrangé wrote:
> On Wed, Nov 01, 2023 at 11:23:37AM -0400, Peter Xu wrote:
> > On Wed, Oct 25, 2023 at 10:39:58AM +0100, Daniel P. Berrangé wrote:
> > > If I'm reading the code correctly the new format has some padding
> > > such that each "rambl
On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote:
> Personally, and honestly, I see no actual use for qemu-img dd at all,
> because we’re trying to mimic a subset of an interface of a rather complex
> program that has been designed to do what it does. We can only fail at
> that. Pers
On 11/1/2023 9:57 AM, Steven Sistare wrote:
> On 11/1/2023 9:34 AM, Fabiano Rosas wrote:
>> Steve Sistare writes:
>>
>>> Signed-off-by: Steve Sistare
>>> ---
>>> tests/qtest/migration-test.c | 27 +++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/tests/qtest/m
On Wed, Nov 01, 2023 at 12:24:22PM -0400, Peter Xu wrote:
> On Wed, Nov 01, 2023 at 03:52:18PM +, Daniel P. Berrangé wrote:
> > On Wed, Nov 01, 2023 at 11:23:37AM -0400, Peter Xu wrote:
> > > On Wed, Oct 25, 2023 at 10:39:58AM +0100, Daniel P. Berrangé wrote:
> > > > If I'm reading the code cor
On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote:
> On 01.10.23 22:46, Denis V. Lunev wrote:
> > Can you please not top-post. This makes the discussion complex. This
> > approach is followed in this mailing list and in other similar lists
> > like LKML.
> >
> > On 10/1/23 19:08, Mike
Steven Sistare writes:
> On 11/1/2023 9:57 AM, Steven Sistare wrote:
>> On 11/1/2023 9:34 AM, Fabiano Rosas wrote:
>>> Steve Sistare writes:
>>>
Signed-off-by: Steve Sistare
---
tests/qtest/migration-test.c | 27 +++
1 file changed, 27 insertions(+)
On 11/1/23 17:51, Daniel P. Berrangé wrote:
On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote:
On 01.10.23 22:46, Denis V. Lunev wrote:
Can you please not top-post. This makes the discussion complex. This
approach is followed in this mailing list and in other similar lists
like LKM
On Mon, 30 Oct 2023, Marc-André Lureau wrote:
Hi
On Tue, Oct 10, 2023 at 5:03 PM BALATON Zoltan wrote:
Apparently these should be half the memory region sizes confirmed at
least by Radeon drivers while Rage 128 Pro drivers don't seem to use
these.
There doesn't seem to be adjustments for th
Peter Xu writes:
> On Tue, Oct 31, 2023 at 08:18:06PM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> > On Mon, Oct 23, 2023 at 05:36:00PM -0300, Fabiano Rosas wrote:
>> >> Currently multifd does not need to have knowledge of pages on the
>> >> receiving side because all the information n
On Wed, Nov 01, 2023 at 06:03:36PM +0100, Denis V. Lunev wrote:
> On 11/1/23 17:51, Daniel P. Berrangé wrote:
> > On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote:
> > > On 01.10.23 22:46, Denis V. Lunev wrote:
> > > > Can you please not top-post. This makes the discussion complex. Th
On Wed, Nov 01, 2023 at 04:37:12PM +, Daniel P. Berrangé wrote:
> It doesn't contain thread number information directly, but it can
> be implicit from the data layout.
>
> If you want parallel I/O, each thread has to know it is the only
> one reading/writing to a particular region of the file.
On Wed, Nov 01, 2023 at 02:20:32PM -0300, Fabiano Rosas wrote:
> I wonder if adapting multifd to use a QIOTask for the channels would
> make sense as an intermediary step. Seems simpler and would force us to
> format multifd in more generic terms.
Isn't QIOTask event based, too?
>From my previous
01.11.2023 18:38, Andrey Drobyshev wrote:
Hi Michael,
Since this series is already merged in master, I'm not sure whether it's
necessary to forward this particular patch to qemu-stable, or it should
rather be cherry-picked to -stable by one of the block maintainers.
It's been my job lately to
Peter Xu writes:
> On Wed, Nov 01, 2023 at 02:20:32PM -0300, Fabiano Rosas wrote:
>> I wonder if adapting multifd to use a QIOTask for the channels would
>> make sense as an intermediary step. Seems simpler and would force us to
>> format multifd in more generic terms.
>
> Isn't QIOTask event bas
On Wed, Nov 01, 2023 at 06:16:07AM -0700, Mattias Nissler wrote:
> Instead of using a single global bounce buffer, give each AddressSpace
> its own bounce buffer. The MapClient callback mechanism moves to
> AddressSpace accordingly.
>
> This is in preparation for generalizing bounce buffer handlin
On Wed, Nov 01, 2023 at 06:16:08AM -0700, Mattias Nissler wrote:
> When DMA memory can't be directly accessed, as is the case when
> running the device model in a separate process without shareable DMA
> file descriptors, bounce buffering is used.
>
> It is not uncommon for device models to reques
On 31.10.23 17:05, Hanna Czenczek wrote:
On 04.10.23 15:56, Vladimir Sementsov-Ogievskiy wrote:
From: Vladimir Sementsov-Ogievskiy
Actually block job is not completed without the final flush. It's
rather unexpected to have broken target when job was successfully
completed long ago and now we f
If Avocado has to fetch this asset, the download fails with a 403 HTTP
error. Use a different URL to fix the issue.
Signed-off-by: Thomas Huth
---
tests/avocado/machine_m68k_nextcube.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/avocado/machine_m68k_nextcube.py
Our current logic in get/setters of MISA and multi-letter extensions
works because we have only 2 CPU types, generic and vendor, and by using
"!generic" we're implying that we're talking about vendor CPUs. When adding
a third CPU type this logic will break so let's handle it beforehand.
In set_mis
The rva22U64 profile, described in:
https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles
Contains a set of CPU extensions aimed for 64-bit userspace
applications. Enabling this set to be enabled via a single user flag
makes it convenient to enable a predictable set of fe
KVM CPUs can handle "cpu->cfg.satp_mode.supported == 0" because KVM will
make it do internally, not requiring the current SATP support from TCG.
But other TCG CPUs doesn't deal well with it. We'll assert out before
OpenSBI if the CPU doesn't set a default:
ERROR:../target/riscv/cpu.c:317:satp_mod
The TCG emulation implements all the extensions described in the
RVA22U64 profile, both mandatory and optional. The mandatory extensions
will be enabled via the profile flag. We'll leave the optional
extensions to be enabled by hand.
Given that this is the first profile we're implementing in TCG w
RVG behaves like a profile: a single flag enables a set of bits. Right
now we're considering user choice when handling RVG and zicsr/zifencei
and ignoring user choice on MISA bits.
We'll add user warnings for profiles when the user disables its
mandatory extensions in the next patch. We'll do the
QEMU already implements zicbom (Cache Block Management Operations) and
zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv:
add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for
what would be the instructions for zicbop (Cache Block Prefetch
Operations), which are
The profile support is handling multi-letter extensions only. Let's add
support for MISA bits as well.
We'll go through every known MISA bit. If the profile doesn't declare
the bit as mandatory, ignore it. Otherwise, set the bit in env->misa_ext
and env->misa_ext_mask.
Now that we're setting prof
Expose all profile flags for all CPUs when executing
query-cpu-model-expansion. This will allow callers to quickly determine
if a certain profile is implemented by a given CPU. This includes
vendor CPUs - the fact that they don't have profile user flags doesn't
mean that they don't implement the pr
We have two instances of the setting/clearing a MISA bit from
env->misa_ext and env->misa_ext_mask pattern. And the next patch will
end up adding one more.
Create a helper to avoid code repetition.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: LIU Zhiwei
Rev
Hi,
This v8 contains a few more extra, trivial changes, related to the
design of the rv64i.
We stripped away all its defaults, including priv_ver and satp mode.
Handling priv_ver was somewhat trivial: profiles and regular extensions
that are user set will now bump the CPU priv_ver if needed. This
We want to add a new CPU type for bare CPUs that will inherit specific
traits of the 2 existing types:
- it will allow for extensions to be enabled/disabled, like generic
CPUs;
- it will NOT inherit defaults, like vendor CPUs.
We can make this conditions met by adding an explicit type for the
We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
comes with a lot of defaults. This is fine for most regular uses but
it's not suitable when more control of what is actually loaded in the
CPU is required.
A bare-bones CPU would be annoying to deal with if not by profile
suppor
Named features (zic64b the sole example at this moment) aren't expose to
users, thus we need another way to expose them.
Go through each named feature, get its boolean value, do the needed
conversions (bool to qbool, qbool to QObject) and add it to output dict.
Another adjustment is needed: named
zic64b is defined in the RVA22U64 profile [1] as a named feature for
"Cache blocks must be 64 bytes in size, naturally aligned in the address
space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64
profile mandates this feature, meaning that applications using this
profile expects 64 by
Current Linux distros ship version 5 of the tesseract OCR software,
so the nextcube screen test is ignored there. Let's make the check
more flexible to allow newer versions, too, and remove the old v3
test since most Linux distros don't ship this version anymore.
Signed-off-by: Thomas Huth
---
t
The setter() for the boolean attributes that set satp_mode (sv32, sv39,
sv48, sv57, sv64) considers that the CPU will always do a
set_satp_mode_max_supported() during cpu_init().
This is not the case for the KVM 'host' CPU, and we'll add another CPU
that won't set satp_mode_max() during cpu_init()
Previous patches added several g_hash_table_insert() patterns. Add two
helpers, one for each user hash, to make the code cleaner.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/tcg/tcg-cpu.c | 28
1 file changed, 16 insertions(+),
Enabling a profile and then disabling some of its mandatory extensions
is a valid use. It can be useful for debugging and testing. But the
common expected use of enabling a profile is to enable all its mandatory
extensions.
Add an user warning when mandatory extensions from an enabled profile
are
Apparently these should be half the memory region sizes confirmed at
least by Radeon FCocde ROM while Rage 128 Pro ROMs don't seem to use
these. Linux r100 DRM driver also checks for a bit in HOST_PATH_CNTL
so we also add that even though the FCode ROM does not seem to set it.
Signed-off-by: BALAT
The GPIO_VGA_DDC and GPIO_DVI_DDC registers are used on Radeon for DDC
access. Some drivers like the PPC Mac FCode ROM uses unaligned writes
to these registers so implement this the same way as already done for
GPIO_MONID which is used the same way for the Rage 128 Pro.
Signed-off-by: BALATON Zolt
We already track user choice for multi-letter extensions because we
needed to honor user choice when enabling/disabling extensions during
realize(). We refrained from adding the same mechanism for MISA
extensions since we didn't need it.
Profile support requires tne need to check for user choice f
Pixman routines can fail if no implementation is available and it will
become optional soon so add fallbacks when pixman does not work.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 8 +
hw/display/ati_2d.c | 75 +++-
hw/display/ati_int.h
We'll add a new bare CPU type that won't have any default priv_ver. This
means that the CPU will default to priv_ver = 0, i.e. 1.10.0.
At the same we'll allow these CPUs to enable extensions at will, but
then, if the extension has a priv_ver newer than 1.10, we'll end up
disabling it. Users will t
KVM does not have the means to support enabling the rva22u64 profile.
The main reasons are:
- we're missing support for some mandatory rva22u64 extensions in the
KVM module;
- we can't make promises about enabling a profile since it all depends
on host support in the end.
We'll revisit this
1 - 100 of 277 matches
Mail list logo