On 12/31/22 20:55, Mika Penttilä wrote:
If decompression does clobber the data, then we *also* need to figure
out why that is. There are basically three possibilities:
1. If physical KASLR is NOT used:
a. The boot loader doesn't honor the kernel safe area properly;
b. Somewhere in
On 12/31/22 10:22, Jason A. Donenfeld wrote:
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
That failure is unrelated to the ident mapping issue Peter and
I discussed. The original failure is described in t
On 12/31/22 19:21, H. Peter Anvin wrote:
Alternatively, setup_data could be relocated, the boot param protocol
could be bumped, and then QEMU could conditionalized it's use of
setup_data based on that protocol version. That'd work, but seems a bit
more involved.
I think this is at least worth
On 12/31/22 11:00, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote:
So with that understanding confirmed, I'm confused at your surprise that
hpa's unrelated fix to the different issue didn't fix this issue.
No surprise there - I used a qemu variant
> When booting the Zephyr demo in [1] we get:
>
> aspeed.io: unimplemented device write (size 4, offset 0x185128, value
> 0x030f1ff1) <--
> aspeed.io: unimplemented device write (size 4, offset 0x18512c, value
> 0x03f1)
>
> This corresponds to this Zephyr code [2]:
>
> static int aspee
>
> Avoid confusing two different things:
> - the WDT I/O region size ('iosize')
> - at which offset the SoC map the WDT ('offset') While it is often the same,
> we
> can map smaller region sizes at larger offsets.
>
> Here we are interested in the I/O region size, so rename as 'iosize'.
>
> Re
Nada Lachtar writes:
> [[S/MIME Signed Part:Undecided]]
> Hello,
>
> Does Qemu maintain two TLB for the x86_64 system (i.e iTLB and dTLB)?
> If yes, can you please point me to how to access the dTLB and what
> data structure maintains this information!
Qemu's internal softmmu TLB is unified an
On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote:
> So with that understanding confirmed, I'm confused at your surprise that
> hpa's unrelated fix to the different issue didn't fix this issue.
No surprise there - I used a qemu variant without your patch to prevent the
setup_data
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
> > That failure is unrelated to the ident mapping issue Peter and
> > I discussed. The original failure is described in the commit message:
> > decompression clobb
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
> That failure is unrelated to the ident mapping issue Peter and
> I discussed. The original failure is described in the commit message:
> decompression clobbers the data, so sd->next points to garbage.
Right, and the fact that th
On Thu, 29 Dec 2022 11:41:22 +0100
Thomas Huth wrote:
> I'm now seeing changes to scripts/meson-buildoptions.sh after
> rebuilding QEMU ... looks like you likely forgot to update that file
> with the automatic update after changing meson_options.txt ?
Ah, there seems to be another couple of unre
On Sat, 31 Dec 2022 17:19:35 +0800
Zongyuan Li wrote:
> Variable 'yynerrs' is recognized as unused variable in clang15,
This issue is already handled by another similar patch (target/hexagon:
suppress unused variable warning) that will soon end up in a pull
request.
Thanks for looking into this
On Sat, Dec 31, 2022 at 02:48:12PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 02:44:08PM +0100, Jason A. Donenfeld wrote:
> > Are you using patch v1 minus the 62 MiB thing?
>
> No, I want to see the original failure - the one that prompted you to send
>
> https://lore.kernel.org/r/20
On Sat, Dec 31, 2022 at 02:44:08PM +0100, Jason A. Donenfeld wrote:
> Are you using patch v1 minus the 62 MiB thing?
No, I want to see the original failure - the one that prompted you to send
https://lore.kernel.org/r/20221228143831.396245-1-ja...@zx2c4.com
--
Regards/Gruss,
Boris.
https:/
On 31/12/22 10:53, Bernhard Beschow wrote:
Am 21. November 2022 15:34:05 UTC schrieb Bernhard Beschow :
Am 27. Oktober 2022 20:47:19 UTC schrieb "Philippe Mathieu-Daudé"
:
Linux kernel expects the northbridge & southbridge chipsets
configured by the BIOS firmware. We emulate that by writin
On Sat, Dec 31, 2022 at 02:40:59PM +0100, Borislav Petkov wrote:
> On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
> > This needs to be something like:
> >
> > kernel_add_identity_map(sd_addr, sd_addr + sizeof(*sd));
> > kernel_add_identity_map(sd_addr + sizeof(*sd),
> > sd_add
On Sat, Dec 31, 2022 at 02:35:45PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 01:54:50PM +0100, Jason A. Donenfeld wrote:
> > Nothing special... `-kernel bzImage` should be enough to do it. Eric
> > reported it, and then I was able to repro trivially. Sure you got the
> > right version
On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
> This needs to be something like:
>
> kernel_add_identity_map(sd_addr, sd_addr + sizeof(*sd));
> kernel_add_identity_map(sd_addr + sizeof(*sd),
> sd_addr + sizeof(*sd) + sd->len);
It still #PFs with that:
(gdb) bt
#0 0xf
On Sat, Dec 31, 2022 at 01:54:50PM +0100, Jason A. Donenfeld wrote:
> Nothing special... `-kernel bzImage` should be enough to do it. Eric
> reported it, and then I was able to repro trivially. Sure you got the
> right version?
Yeah, qemu executables confusion here - had wrongly something older of
On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
>
>
> On 12/30/22 14:10, Jason A. Donenfeld wrote:
> > On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
> >> See the other thread fork. They have identified the problem already.
> >
> > Not sure I follow. Is there ano
On Sat, Dec 31, 2022 at 10:48:16AM +0100, Borislav Petkov wrote:
> On Fri, Dec 30, 2022 at 04:59:30PM +0100, Jason A. Donenfeld wrote:
> > I'll attach a .config file. Apply the patch at the top of this thread to
> > qemu,
>
> Hmm, so the patch at the top of this thread is fixing the clobbering of
Alexander,
On Sat, Dec 31, 2022 at 12:34:45PM +0100, Alexander Graf wrote:
> On 31.12.22 11:17, Vitaly Chikunov wrote:
> > On Sat, Dec 31, 2022 at 10:28:21AM +0100, Alexander Graf wrote:
> > > On 30.12.22 19:16, Vitaly Chikunov wrote:
> > > > On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Gra
Hi Vitaly,
On 31.12.22 11:17, Vitaly Chikunov wrote:
Alexander,
On Sat, Dec 31, 2022 at 10:28:21AM +0100, Alexander Graf wrote:
On 30.12.22 19:16, Vitaly Chikunov wrote:
On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Graf wrote:
This is a kvm kernel bug and should be fixed with the late
Alexander,
On Sat, Dec 31, 2022 at 10:28:21AM +0100, Alexander Graf wrote:
> On 30.12.22 19:16, Vitaly Chikunov wrote:
> > On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Graf wrote:
> > >
> > > This is a kvm kernel bug and should be fixed with the latest stable
> > > releases. Which kernel
Am 21. November 2022 15:34:05 UTC schrieb Bernhard Beschow :
>
>
>Am 27. Oktober 2022 20:47:19 UTC schrieb "Philippe Mathieu-Daudé"
>:
>>Linux kernel expects the northbridge & southbridge chipsets
>>configured by the BIOS firmware. We emulate that by writing
>>a tiny bootloader code in write_bo
On Fri, Dec 30, 2022 at 04:59:30PM +0100, Jason A. Donenfeld wrote:
> I'll attach a .config file. Apply the patch at the top of this thread to
> qemu,
Hmm, so the patch at the top of this thread is fixing the clobbering of
setup_data.
But I tried latest qemu with your .config and it boots ok here
Hello,
Does Qemu maintain two TLB for the x86_64 system (i.e iTLB and dTLB)? If yes,
can you please point me to how to access the dTLB and what data structure
maintains this information!
I would appreciate any help,
Thanks,
smime.p7s
Description: S/MIME cryptographic signature
Hi Vitaly,
On 30.12.22 19:16, Vitaly Chikunov wrote:
Alexander,
On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Graf wrote:
Hi Vitaly,
This is a kvm kernel bug and should be fixed with the latest stable releases.
Which kernel version are you running?
This is on latest v6.0 stable - 6.0.
Variable 'yynerrs' is recognized as unused variable in clang15,
which is auto-generated by bison in parser file, as long as user
code doesn't access it in '.y'. This is already fixed in bison 8.2.
But for user who use latest clang, a simple harmless code piece
would fix this building error.
FYI: b
29 matches
Mail list logo
