PAE mode in x86 supports 36 bit address space. Check the PAE CPUID on the
guest processor and set phys_bits to 36 if PAE feature is set. This is in
addition to checking the presence of PSE36 CPUID feature for setting 36 bit
phys_bits.
Signed-off-by: Ani Sinha
---
target/i386/cpu.c | 2 +-
1 file
On Tue, 5 Sep 2023 20:15:13 -0400
Gregory Price wrote:
> Call CXL_TYPE3 once at top of function to avoid multiple invocations.
>
> Signed-off-by: Gregory Price
This one is queued up in a set I posted for Michael to hopefully pick up.
So no need to keep it in this series (I'll post tree short
On Sat, 9 Sept 2023 at 18:06, Richard Henderson
wrote:
>
> On 9/7/23 09:03, Peter Maydell wrote:
> > +void HELPER(cpyp)(CPUARMState *env, uint32_t syndrome, uint32_t wdesc,
> > + uint32_t rdesc, uint32_t move)
> > +{
> > +int rd = mops_destreg(syndrome);
> > +int rs = mops
12.09.2023 14:30, Philippe Mathieu-Daudé:
kvm_get_radix_page_info() is only defined for ppc targets (in
target/ppc/kvm.c). The declaration is not useful in other targets.
Rename using the 'kvmppc_' prefix following other declarations
from target/ppc/kvm_ppc.h.
Signed-off-by: Philippe Mathieu-Dau
On Tue, 5 Sep 2023 12:04:29 -0400
Gregory Price wrote:
> On Wed, Sep 06, 2023 at 02:04:45PM +0100, Jonathan Cameron wrote:
> > On Thu, 31 Aug 2023 21:29:14 -0400
> > Gregory Price wrote:
> >
> > Hi Gregory,
> >
> > Some comments inline, but I'm happy to add this to my staging tree in the
> >
On Tue, 5 Sep 2023 20:15:12 -0400
Gregory Price wrote:
> Preparation for allowing devices to define their own CCI commands
>
> Signed-off-by: Gregory Price
I've updated this because I've queued up Davidlohr's
scan media work ahead of this so there is one more usage.
Will push a tree out with
12.09.2023 14:30, Philippe Mathieu-Daudé wrote:
Inline and guard the single call to kvm_openpic_connect_vcpu()
allows to remove kvm-stub.c. While it seems some code churn,
it allows forbidding user emulation to include "kvm_ppc.h" in
the next commit.
Reviewed-by: Michael Tokarev
FWIW, if you
On 07.09.23 13:21, Hanna Czenczek wrote:
On 06.09.23 15:18, Stefan Hajnoczi wrote:
On Fri, 1 Sept 2023 at 04:18, Hanna Czenczek wrote:
The following changes since commit
f5fe7c17ac4e309e47e78f0f9761aebc8d2f2c81:
Merge tag 'pull-tcg-20230823-2' of
https://gitlab.com/rth7680/qemu into stag
On 12/9/23 14:32, Michael Tokarev wrote:
12.09.2023 14:30, Philippe Mathieu-Daudé:
kvm_get_radix_page_info() is only defined for ppc targets (in
target/ppc/kvm.c). The declaration is not useful in other targets.
Rename using the 'kvmppc_' prefix following other declarations
from target/ppc/kvm_p
Cc'ing VFIO maintainers.
On 12/9/23 14:39, Shlomo Pongratz wrote:
Hi,
I'm running qemu-system-aarch64 (QEMU emulator version 7.0.93) on
Ubuntu 20.04.4 LTS i with Intel's i7.
I'm trying to pass a Samsung NVME device using vfio-pci. I detached
the device from the nvme driver and attached it to the
On Tue, Sep 12, 2023 at 10:34:04AM +0400, Marc-André Lureau wrote:
> Hi
>
> On Wed, Aug 23, 2023 at 2:03 PM Marc-André Lureau
> wrote:
> >
> > Hi
> >
> > On Wed, Aug 23, 2023 at 4:31 AM Stephen Brennan
> > wrote:
> > >
> > > Stephen Brennan writes:
> > > > Marc-André Lureau writes:
> > > >> I
Hi Klaus,
On Tue, 2023-09-05 at 10:38 +0200, Klaus Jensen wrote:
> >
> > +static void nmi_handle_mi_config_get(NMIDevice *nmi, NMIRequest
> > *request)
> > +{
> > + uint32_t dw0 = le32_to_cpu(request->dw0);
> > + uint8_t identifier = FIELD_EX32(dw0,
> > NMI_CMD_CONFIGURATION_GET_DW0,
> > +
Hello,
I'm working on a college project where the goal is supposed to be an
experiment in OS instrumentation. What we decided to try is to modify the
QEmu source code to be able to acquire some info about a VM we launch with
it. We've forked the repository and successfully built from source, but t
On Tue, 12 Sep 2023 14:47:41 +0200
Philippe Mathieu-Daudé wrote:
> Cc'ing VFIO maintainers.
>
> On 12/9/23 14:39, Shlomo Pongratz wrote:
> > Hi,
> > I'm running qemu-system-aarch64 (QEMU emulator version 7.0.93) on
> > Ubuntu 20.04.4 LTS i with Intel's i7.
> > I'm trying to pass a Samsung NVME d
ilable in the Git repository at:
>
> https://gitlab.com/kraxel/qemu.git
> tags/firmware/seabios-20230912-pull-request
>
> for you to fetch changes up to a14c30fc3d38d569415259a2d877c36a0b8de058:
>
> seabios: update
This avoids the warnings à la:
"warning: redirecting to https://gitlab.com/qemu-project/xyz.git/";
Signed-off-by: Thomas Huth
---
subprojects/berkeley-softfloat-3.wrap | 2 +-
subprojects/berkeley-testfloat-3.wrap | 2 +-
subprojects/slirp.wrap| 2 +-
3 files changed, 3 insertion
12.09.2023 14:30, Philippe Mathieu-Daudé:
kvm-stub.c only defines kvm_openpic_connect_vcpu(),
which is clearly not used by user emulation.
Yes, kvm-stub only defines this function. But you also move kvm.c
from ppc_ss to ppc_system_ss, and the commit message does not say
a word about this. Hop
12.09.2023 16:02, Thomas Huth wrote:
This avoids the warnings à la:
"warning: redirecting to https://gitlab.com/qemu-project/xyz.git/";
Signed-off-by: Thomas Huth
I wanted to do that for quite some time.. :)
Reviewed-by: Michael Tokarev
Applied to my trivial-patches tree, thanks!
/mjt
On 12/9/23 15:02, Thomas Huth wrote:
This avoids the warnings à la:
"warning: redirecting to https://gitlab.com/qemu-project/xyz.git/";
Signed-off-by: Thomas Huth
---
subprojects/berkeley-softfloat-3.wrap | 2 +-
subprojects/berkeley-testfloat-3.wrap | 2 +-
subprojects/slirp.wrap
Occasionally some avocado tests will fail waiting for console line
despite the machine running correctly. Console data goes missing, as can
be seen in the console log. This is due to _console_interaction calling
makefile() on the console socket each time it is invoked, which must be
losing old buff
Hi,
In this version we have a change in patch 3. It was causing a build
break with --enable-debug builds that weren't being detected by regular
gitlab CI but was detected when running the merge CI [1]. The problem is
reproducible by any risc-v --enable-debug build.
I ended up leaving kvm_riscv_cp
Our goal is to make riscv_cpu_extensions[] hold only ratified,
non-vendor extensions.
Create a new riscv_cpu_vendor_exts[] array for them, changing
riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties()
accordingly.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
We'll add a new CPU type that will enable a considerable amount of
extensions. To make it easier for us we'll do a few cleanups in our
existing riscv_cpu_extensions[] array.
Start by splitting all CPU non-boolean options from it. Create a new
riscv_cpu_options[] array for them. Add all these prope
Create a new riscv_cpu_experimental_exts[] to store the non-ratified
extensions properties. Once they are ratified we'll move them back to
riscv_cpu_extensions[].
riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are
changed to keep adding non-ratified properties to users.
Signed
Inside riscv_cpu_validate_v() we're always throwing a log message if the
user didn't set a vector version via 'vext_spec'.
We're going to include one case with the 'max' CPU where env->vext_ver
will be set in the cpu_init(). But that alone will not stop the "vector
version is not specified" messag
Future patches will split the existing Property arrays even further, and
the existing code in riscv_cpu_add_user_properties() will start to scale
bad with it because it's dealing with KVM constraints mixed in with TCG
constraints. We're going to pay a high price to share a couple of common
lines of
Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its
code repetition.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
Reviewed-by: Alistair Francis
---
target/riscv/cpu.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff
The code inside riscv_cpu_add_user_properties() became quite repetitive
after recent changes. Add a helper to hide the repetition away.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
---
target/riscv/cpu.c | 2
Add smoke tests to ensure that we'll not break the 'max' CPU type when
adding new frozen/ratified RISC-V extensions.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
tests/avocado/tuxrun_baselines.py
The RISC-V KVM driver uses a CPUCFG() macro that calculates the offset
of a certain field in the struct RISCVCPUConfig. We're going to use this
macro in target/riscv/cpu.c as well in the next patches. Make it public.
Rename it to CPU_CFG_OFFSET() for more clarity while we're at it.
Signed-off-by:
Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when
iterating in the riscv_cpu_options[] array, making it similar to what
we already do when working with riscv_cpu_extensions[].
We also have a more sophisticated motivation behind this change. In the
future we might need to expo
Let's change the other instances in realize() where we're enabling an
extension based on a certain criteria (e.g. it's a dependency of another
extension).
We're leaving icsr and ifencei being enabled during RVG for later -
we'll want to error out in that case. Every other extension enablement
duri
If we want to make better decisions when auto-enabling extensions during
realize() we need a way to tell if an user set an extension manually.
The RISC-V KVM driver has its own solution via a KVMCPUConfig struct
that has an 'user_set' flag that is set during the Property set()
callback. The set() c
We'll have future usage for a function where, given an offset of the
struct RISCVCPUConfig, the flag is updated to a certain val.
Change all existing callers to use edata->ext_enable_offset instead of
'edata'.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: And
The 'max' CPU type is used by tooling to determine what's the most
capable CPU a current QEMU version implements. Other archs such as ARM
implements this type. Let's add it to RISC-V.
What we consider "most capable CPU" in this context are related to
ratified, non-vendor extensions. This means tha
Before adding support to detect if an extension was user set we need to
handle how we're enabling extensions in riscv_init_max_cpu_extensions().
object_property_set_bool() calls the set() callback for the property,
and we're going to use this callback to set the 'multi_ext_user_opts'
hash.
This me
The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU
Core Definition"), being around since the beginning. It's not an easy
CPU to use: it's undocumented and its name doesn't tell users much about
what the CPU is supposed to bring. 'git log' doesn't help us either in
knowing what w
During realize() time we're activating a lot of extensions based on some
criteria, e.g.:
if (cpu->cfg.ext_zk) {
cpu->cfg.ext_zkn = true;
cpu->cfg.ext_zkr = true;
cpu->cfg.ext_zkt = true;
}
This practice resulted in at least one case where we ended up enabling
somet
After the introduction of riscv_cpu_options[] all properties in
riscv_cpu_extensions[] are booleans. This check is now obsolete.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: Andrew Jones
---
target/riscv/cpu.c | 14 --
1 file changed, 4 insertio
Enabling RVG will enable a set of extensions that we're not checking if
the user was okay enabling or not. And in this case we want to error
out, instead of ignoring, otherwise we will be inconsistent enabling RVG
without all its extensions.
After this patch, disabling ifencei or icsr while enabli
Add a new cpu_cfg_ext_is_user_set() helper to check if an extension was
set by the user in the command line. Use it inside
cpu_cfg_ext_auto_update() to verify if the user set a certain extension
and, if that's the case, do not change its value.
This will make us honor user choice instead of overwr
The test still fails intermittently with a 60 second timeout in the
GitLab CI environment. Raise the timeout to 120 seconds.
576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion
failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" ==
"st0: index=0,t
On Tue, 12 Sep 2023 13:13:51 +0100
Jonathan Cameron wrote:
> On Tue, 5 Sep 2023 20:15:13 -0400
> Gregory Price wrote:
>
> > Call CXL_TYPE3 once at top of function to avoid multiple invocations.
> >
> > Signed-off-by: Gregory Price
>
> This one is queued up in a set I posted for Michael to
The 80m timeout is not enough:
672/832 qemu:block / io-qcow2-041 OK 39.77s 1 subtests
passed
Timed out!
https://gitlab.com/qemu-project/qemu/-/jobs/5058610599
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/1882
Fixes: d06f3bf92267 ("gitlab-ci/cirrus: Increase
On Tue, Sep 12, 2023 at 09:33:10AM -0400, Stefan Hajnoczi wrote:
> The test still fails intermittently with a 60 second timeout in the
> GitLab CI environment. Raise the timeout to 120 seconds.
>
> 576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix:
> assertion failed (resp == ex
Hi!
I've an interesting situation here which I'd love to discuss.
Cc'ing authors of commits in question, but this is actually a much more
general topic than this very specific issue, - so also adding some more
addresses to Cc.
I tried to cherry-pick a trivial commit from master to stable-7.2, th
On 9/9/23 13:53, Huang Rui wrote:
> On Thu, Aug 31, 2023 at 11:51:50PM +0800, Dmitry Osipenko wrote:
>> On 8/31/23 13:40, Antonio Caggiano wrote:
>>> Hi Huang,
>>>
>>> Thank you for pushing this forward!
>>>
>>> On 31/08/2023 11:32, Huang Rui wrote:
From: Antonio Caggiano
Request Ve
On Tue, Sep 12, 2023 at 09:38:29AM -0400, Stefan Hajnoczi wrote:
> The 80m timeout is not enough:
>
> 672/832 qemu:block / io-qcow2-041 OK 39.77s 1
> subtests passed
> Timed out!
IIUC, that 'timed out' message is coming from Cirrus CI logs, which
we can see over on the
On 9/12/23 12:53, Gerd Hoffmann wrote:
Needed to make the build fit into 128k.
Signed-off-by: Gerd Hoffmann
---
roms/config.seabios-128k | 1 +
1 file changed, 1 insertion(+)
diff --git a/roms/config.seabios-128k b/roms/config.seabios-128k
index d18c802c46e9..bc3ba7f65bcd 100644
--- a/roms/
On Tue, 12 Sep 2023 16:22:27 +0300
Shlomo Pongratz wrote:
> Hi,
> What can I as a user do to honor this requirement.
> Are you suggesting that I should patch the QEMU code as it is not
> supported out of the box?
You can reduce the VM memory, for example the mapping is starting at
1GB so using 2
Hi Gurchetan
On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh
wrote:
>
>
>
> On Wed, Aug 30, 2023 at 7:26 PM Huang Rui wrote:
>>
>> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
>> > From: Gurchetan Singh
>> >
>> > Changes since v12:
>> > - Added r-b tags from Antonio Caggiano
When I backport patches into RHEL, the general process I follow is:
1. For context conflicts, just adjust the patch to resolve them.
2. For real dependencies, backport the dependencies, if possible.
3. If backporting the dependencies is not possible, think of a
downstream-only solution. This should
On Tue, 12 Sept 2023 at 09:53, Daniel P. Berrangé wrote:
>
> On Tue, Sep 12, 2023 at 09:38:29AM -0400, Stefan Hajnoczi wrote:
> > The 80m timeout is not enough:
> >
> > 672/832 qemu:block / io-qcow2-041 OK 39.77s 1
> > subtests passed
> > Timed out!
>
> IIUC, that 'time
The FEAT_MOPS instructions need a couple of helper routines that
check for MTE tag failures:
* mte_mops_probe() checks whether there is going to be a tag
error in the next up-to-a-page worth of data
* mte_check_fail() is an existing function to record the fact
of a tag failure, which we nee
The FEAT_MOPS CPY* instructions implement memory copies. These
come in both "always forwards" (memcpy-style) and "overlap OK"
(memmove-style) flavours.
Signed-off-by: Peter Maydell
---
v2: - separate helpers for the 'forwards' and 'move' variants
- fix cpyfp saturation limit
- cpyfm/cpyfp
The LDRT/STRT "unprivileged load/store" instructions behave like
normal ones if executed at EL0. We handle this correctly for
the load/store semantics, but get the MTE checking wrong.
We always look at s->mte_active[is_unpriv] to see whether we should
be doing MTE checks, but in hflags.c when we s
Enable FEAT_MOPS on the AArch64 'max' CPU, and add it to
the list of features we implement.
Signed-off-by: Peter Maydell
---
v2: Now sets the hwcap bit
---
docs/system/arm/emulation.rst | 1 +
linux-user/elfload.c | 1 +
target/arm/tcg/cpu64.c| 1 +
3 files changed, 3 insertions
The FEAT_MOPS memory copy operations need an extra helper routine
for checking for MTE tag checking failures beyond the ones we
already added for memory set operations:
* mte_mops_probe_rev() does the same job as mte_mops_probe(), but
it checks tags starting at the provided address and working
FEAT_MOPS defines a handful of new enable bits:
* HCRX_EL2.MSCEn, SCTLR_EL1.MSCEn, SCTLR_EL2.MSCen:
define whether the new insns should UNDEF or not
* HCRX_EL2.MCE2: defines whether memops exceptions from
EL1 should be taken to EL1 or EL2
Since we don't sanitise what bits can be written fo
For the FEAT_MOPS operations, the existing allocation_tag_mem()
function almost does what we want, but it will take a watchpoint
exception even for an ra == 0 probe request, and it requires that the
caller guarantee that the memory is accessible. For FEAT_MOPS we
want a function that will not take
Currently the only tag-setting instructions always do so in the
context of the current EL, and so we only need one ATA bit in the TB
flags. The FEAT_MOPS SETG instructions include ones which set tags
for a non-privileged access, so we now also need the equivalent "are
tags enabled?" information fo
This patchset implements the Arm FEAT_MOPS architectural feature,
which is a set of instructions to implement memory copy and set
operations. The new instructions come in sets of three:
* SETP, SETM, SETE -- memory set
* SETGP, SETGM, SETME -- memory set with MTE tag setting
* CPYP, CPYM, CPYE -
On 9/11/23 23:13, Philippe Mathieu-Daudé wrote:
/*
* Only for builtin_x86_defs models initialized with
x86_register_cpudef_types.
*/
@@ -6163,6 +6195,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
}
*edx = env->features[FEAT_7_0_EDX
On 9/12/23 15:42, Daniel P. Berrangé wrote:
On Tue, Sep 12, 2023 at 09:33:10AM -0400, Stefan Hajnoczi wrote:
The test still fails intermittently with a 60 second timeout in the
GitLab CI environment. Raise the timeout to 120 seconds.
576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stre
The FEAT_MOPS SETG* instructions are very similar to the SET*
instructions, but as well as setting memory contents they also
set the MTE tags. They are architecturally required to operate
on tag-granule aligned regions only.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
---
v2: - s
In every place that we call the get_a64_user_mem_index() function
we do it like this:
memidx = a->unpriv ? get_a64_user_mem_index(s) : get_mem_index(s);
Refactor so the caller passes in the bool that says whether they
want the 'unpriv' or 'normal' mem_index rather than having to
do the ?: themselv
On 9/11/23 23:13, Philippe Mathieu-Daudé wrote:
Too many system-specific code (and in particular KVM related)
is pulled in user-only build. This led to adding unjustified
stubs as kludge to unagressive linker non-optimizations.
This series restrict x86 system-specific features to sysemu,
so we d
The FEAT_MOPS memory operations can raise a Memory Copy or Memory Set
exception if a copy or set instruction is executed when the CPU
register state is not correct for that instruction. Define the
usual syn_* function that constructs the syndrome register value
for these exceptions.
Signed-off-by:
Implement the SET* instructions which collectively implement a
"memset" operation. These come in a set of three, eg SETP
(prologue), SETM (main), SETE (epilogue), and each of those has
different flavours to indicate whether memory accesses should be
unpriv or non-temporal.
This commit does not in
Ping^2 for review/pickup by the rdma folks, please?
thanks
-- PMM
On Tue, 29 Aug 2023 at 16:49, Peter Maydell wrote:
>
> On Tue, 25 Jul 2023 at 12:36, Peter Maydell wrote:
> >
> > In query_port() we pass the address of a local pvrdma_port_attr
> > struct to the rdma_query_backend_port() functio
On Tue, 29 Aug 2023 at 16:48, Peter Maydell wrote:
>
> On Tue, 1 Aug 2023 at 16:44, Peter Maydell wrote:
> >
> > The spec for m68k semihosting is documented in the libgloss
> > sources. Add a comment with the URL for it, as we already
> > have for nios2 semihosting.
> >
> > Signed-off-by: Peter M
On Tue, Sep 12, 2023 at 10:02:17AM -0400, Stefan Hajnoczi wrote:
> On Tue, 12 Sept 2023 at 09:53, Daniel P. Berrangé wrote:
> >
> > On Tue, Sep 12, 2023 at 09:38:29AM -0400, Stefan Hajnoczi wrote:
> > > The 80m timeout is not enough:
> > >
> > > 672/832 qemu:block / io-qcow2-041 OK
On Mon, 14 Aug 2023 at 08:09, Klaus Jensen wrote:
>
> On Aug 11 18:47, Peter Maydell wrote:
> > The QEMU codebase has very few C variable length arrays, and if we can
> > get rid of them all we can make the compiler error on new additions.
> > This is a defensive measure against security bugs wher
Hi,
What can I as a user do to honor this requirement.
Are you suggesting that I should patch the QEMU code as it is not
supported out of the box?
Thank you.
S.P.
On Tue, Sep 12, 2023 at 3:58 PM Alex Williamson
wrote:
>
> On Tue, 12 Sep 2023 14:47:41 +0200
> Philippe Mathieu-Daudé wrote:
>
> >
Here is a log from the CI, but I don't think it has much information:
https://gitlab.com/qemu-project/qemu/-/jobs/5020899550
Is it possible to detect the crash? Timeouts are hard to diagnose, so
it would be better for the test to detect a terminated child process
and print an error.
Stefan
On Tu
Thank you!
Stefan
On Tue, 12 Sept 2023 at 10:15, Daniel P. Berrangé wrote:
>
> On Tue, Sep 12, 2023 at 10:02:17AM -0400, Stefan Hajnoczi wrote:
> > On Tue, 12 Sept 2023 at 09:53, Daniel P. Berrangé
> > wrote:
> > >
> > > On Tue, Sep 12, 2023 at 09:38:29AM -0400, Stefan Hajnoczi wrote:
> > > >
Hi Gerd; this series has been reviewed. Did you want to take it
via the audio tree? Or I can put it in via target-arm.next
if you prefer.
thanks
-- PMM
On Fri, 18 Aug 2023 at 16:58, Peter Maydell wrote:
>
> This patchset removes two variable length arrays from the jack audio
> backend. The code
On Sep 12 15:15, Peter Maydell wrote:
> On Mon, 14 Aug 2023 at 08:09, Klaus Jensen wrote:
> >
> > On Aug 11 18:47, Peter Maydell wrote:
> > > The QEMU codebase has very few C variable length arrays, and if we can
> > > get rid of them all we can make the compiler error on new additions.
> > > This
Hi, Jason. This patchset has been reviewed -- do you want to
pick it up via the net tree?
thanks
-- PMM
On Thu, 24 Aug 2023 at 16:32, Peter Maydell wrote:
>
> This patchset removes the use of variable length arrays in a couple
> of network devices and the net/ core code. In one case we can swit
From: Peter Maydell
Instead of using a variable-length array in nvme_map_prp(),
allocate on the stack with a g_autofree pointer.
The codebase has very few VLAs, and if we can get rid of them all we
can make the compiler error on new additions. This is a defensive
measure against security bugs w
From: Philippe Mathieu-Daudé
In nvme_map_sgl() we create an array segment[] whose size is the
'const int SEG_CHUNK_SIZE'. Since this is C, rather than C++, a
"const int foo" is not a true constant, it's merely a variable with a
constant value, and so semantically segment[] is a variable-length
a
From: Klaus Jensen
Hi,
The following changes since commit 9ef497755afc252fb8e060c9ea6b0987abfd20b6:
Merge tag 'pull-vfio-20230911' of https://github.com/legoater/qemu into
staging (2023-09-11 09:13:08 -0400)
are available in the Git repository at:
https://gitlab.com/birkelund/qemu.git ta
On Tue, Sep 12, 2023, 8:01 AM Stefan Hajnoczi wrote:
> When I backport patches into RHEL, the general process I follow is:
> 1. For context conflicts, just adjust the patch to resolve them.
> 2. For real dependencies, backport the dependencies, if possible.
> 3. If backporting the dependencies is
On 12.09.23 14:06, Ani Sinha wrote:
PAE mode in x86 supports 36 bit address space. Check the PAE CPUID on the
guest processor and set phys_bits to 36 if PAE feature is set. This is in
addition to checking the presence of PSE36 CPUID feature for setting 36 bit
phys_bits.
Signed-off-by: Ani Sinha
The avocado-system-alpine, avocado-system-fedora, and
avocado-system-ubuntu jobs are unreliable. I identified them while
looking over CI failures from the past week:
https://gitlab.com/qemu-project/qemu/-/jobs/5058610614
https://gitlab.com/qemu-project/qemu/-/jobs/5058610654
https://gitlab.com/qemu
On Tue, Sep 12, 2023 at 11:06:11AM -0400, Stefan Hajnoczi wrote:
> The avocado-system-alpine, avocado-system-fedora, and
> avocado-system-ubuntu jobs are unreliable. I identified them while
> looking over CI failures from the past week:
> https://gitlab.com/qemu-project/qemu/-/jobs/5058610614
> htt
On Tue, Sep 12, 2023 at 10:00:46AM -0400, Stefan Hajnoczi wrote:
> When I backport patches into RHEL, the general process I follow is:
> 1. For context conflicts, just adjust the patch to resolve them.
> 2. For real dependencies, backport the dependencies, if possible.
> 3. If backporting the depen
The prototype of do_[st|ld]*_mmu() is unified between system- and
user-mode allowing a large chunk of helper_[st|ld]*() and cpu_[st|ld]*()
functions to be expressed in same manner between both modes. These
functions will be moved to ldst_common.c.inc in a following commit.
Signed-off-by: Anton Joh
TARGET_PAGE_ENTRY_EXTRA is a macro that allows guests to specify additional
fields for caching with the full TLB entry. This macro is replaced with
a union in CPUTLBEntryFull, thus making CPUTLB target-agnostic at the
cost of slightly inflated CPUTLBEntryFull for non-arm guests.
Note, this is nee
This patchset reduces the dependence of cputlb.c on the full
CPUArchState, instead replacing it with the generic CPUState. Target-
facing functions such as probe_access(), cpu_ld*(), etc. are not
modified in this patchset, the idea is to try and isolate all usage of
CPUArchState into smaller wrappe
On Tue, Sep 12, 2023 at 11:13:40PM +1000, Nicholas Piggin wrote:
> Occasionally some avocado tests will fail waiting for console line
> despite the machine running correctly. Console data goes missing, as can
> be seen in the console log. This is due to _console_interaction calling
> makefile() on
do_[ld|st]*() and mmu_lookup*() are changed to use CPUState over
CPUArchState, moving the target-dependence to the target-facing facing
cpu_[ld|st] functions.
Signed-off-by: Anton Johansson
---
accel/tcg/cputlb.c | 324 ++---
1 file changed, 161 insertions
[...]
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 54838c0c41..d187890675 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -908,9 +908,12 @@ static hwaddr pc_max_used_gpa(PCMachineState *pcms,
uint64_t pci_hole64_size)
{
X86CPU *cpu = X86_CPU(first_cpu);
-/* 32-bit systems don't have
probe_access_internal() is changed to instead take the generic CPUState
over CPUArchState, in order to lessen the target-specific coupling of
cputlb.c. Note: probe_access*() also don't need the full CPUArchState,
but aren't touched in this patch as they are target-facing.
Signed-off-by: Anton Joha
The goal is to (in the future) allow for per-target compilation of
functions in atomic_template.h whilst atomic_mmu_lookup() and cputlb.c
are compiled once-per user- or system mode.
Signed-off-by: Anton Johansson
---
accel/tcg/atomic_template.h | 20
accel/tcg/cputlb.c
Changes tlb_*() functions to take CPUState instead of CPUArchState, as
they don't require the full CPUArchState. This makes it easier to
decouple target-(in)dependent code.
Signed-off-by: Anton Johansson
---
include/exec/cpu_ldst.h | 8 +-
accel/tcg/cputlb.c | 218 +++-
The function is no longer used to access the TLB, and has been replaced
by cpu_tlb().
Signed-off-by: Anton Johansson
---
include/exec/cpu-all.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index b03218d7d3..ee21f94969 100644
---
Makes ldst_atomicity.c.inc almost target-independent, with the exception
of TARGET_PAGE_MASK, which will be addressed in a future patch.
Signed-off-by: Anton Johansson
---
accel/tcg/cputlb.c | 20
accel/tcg/user-exec.c | 16 +++
accel/tcg/ldst_atomicity.c.inc |
Adds a CPUTLB * field to CPUState in order to access the TLB without
knowledge of the ArchCPU struct layout. A cpu_tlb(CPUState *) function
is added for ease of access.
Signed-off-by: Anton Johansson
---
include/exec/cpu-all.h | 12
include/hw/core/cpu.h | 6 ++
2 files change
A large chunk of ld/st functions are moved from cputlb.c and user-exec.c
to ldst_common.c.inc as their implementation is the same between both
modes.
Eventually, ldst_common.c.inc could be compiled into a separate
target-specific compilation unit, and be linked in with the targets.
Keeping CPUArch
101 - 200 of 357 matches
Mail list logo
