We can simply use the g_ascii_isxdigit() from the glib instead.
Signed-off-by: Thomas Huth
---
util/uri.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/util/uri.c b/util/uri.c
index dcb3305236..7411c5ba14 100644
--- a/util/uri.c
+++ b/util/uri.c
@@ -1561,15 +156
On 1/12/24 10:42, Thomas Huth wrote:
On 12/01/2024 05.57, Harsh Prateek Bora wrote:
On 1/11/24 22:16, Thomas Huth wrote:
The character "+" is now forbidden in QOM device names (see commit
b447378e1217 - "Limit type names to alphanumerical and some few special
characters"). For the "power5+
From: Robert Hoo
Linear Address Masking (LAM) is a new Intel CPU feature, which allows
software to use of the untranslated address bits for metadata.
The bit definition:
CPUID.(EAX=7,ECX=1):EAX[26]
Add CPUID definition for LAM.
Note LAM feature is not supported for TCG of target-i386, LAM CPIU
Linear-address masking (LAM) [1], modifies the checking that is applied to
*64-bit* linear addresses, allowing software to use of the untranslated
address bits for metadata and masks the metadata bits before using them as
linear addresses to access memory.
When the feature is virtualized and expos
LAM uses CR3[61] and CR3[62] to configure/enable LAM on user pointers.
LAM uses CR4[28] to configure/enable LAM on supervisor pointers.
For CR3 LAM bits, no additional handling needed:
- TCG
LAM is not supported for TCG of target-i386. helper_write_crN() and
helper_vmrun() check max physical
Thomas Huth writes:
> We can simply use the g_ascii_isxdigit() from the glib instead.
>
> Signed-off-by: Thomas Huth
> ---
> util/uri.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/util/uri.c b/util/uri.c
> index dcb3305236..7411c5ba14 100644
> --- a/util
Am 12.01.24 um 07:35 schrieb Markus Armbruster:
Thomas Huth writes:
We can simply use the g_ascii_isxdigit() from the glib instead.
... or even use unescape_string() from the glib?
https://docs.gtk.org/glib/type_func.Uri.unescape_string.html
Regards,
Stefan
Regarding pseries, migration compat broke because of 5bc8d26de20c
("spapr: allocate the ICPState object from under sPAPRCPUCore") which
is similar to the changes proposed by this series, it impacts the QOM
hierarchy. Here is the workaround/fix from Greg : 46f7afa37096
("spapr: fix migration of
On 1/12/24 06:09, Thomas Huth wrote:
On 11/01/2024 23.28, Helge Deller wrote:
On 1/9/24 17:01, Richard Henderson wrote:
On 1/9/24 22:16, Helge Deller wrote:
On 1/9/24 10:57, Richard Henderson wrote:
On 1/8/24 00:22, del...@kernel.org wrote:
From: Helge Deller
Add support for the qemu --nod
301 - 309 of 309 matches
Mail list logo