nfirm that this patch series resolves the issue that I originally
observed in https://gitlab.com/qemu-project/qemu/-/issues/2040 and that
Windows 10 32-bit is able to boot with PAE enabled and memory over 4G.
Tested-by: Michael Brown
Thanks,
Michael
On 23/12/2023 11:47, Paolo Bonzini wrote:
The linear address is the one that has the segment base added, and it is
not truncated to 16 bits (otherwise the whole A20 thing would not
exist). The same should be true of e.g. an FSAVE instruction; it would
allow access slightly beyond the usual 1M+6
ze (16 or 32 bits) before any conversion to a physical address
takes place.
Regardless: this updated patch (in isolation) definitely fixes the issue
that I observed, so I'm happy for an added
Tested-by: Michael Brown
Thanks,
Michael
ving the address truncation in get_physical_address().
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2040
Signed-off-by: Michael Brown
---
target/i386/tcg/sysemu/excp_helper.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/target/i386/tcg/sysemu/excp_helper.c
b/target/i386/tcg/sysemu/
On 20/12/2023 21:51, Richard Henderson wrote:
On 12/20/23 22:03, Michael Brown wrote:
For the default case, I think it would make sense to unconditionally
truncate the address to 32 bits if paging is disabled. (I am not sure
why the original commit 33dfdb5 included a test for long mode, since
On 20/12/2023 04:22, Richard Henderson wrote:
On 12/18/23 23:56, Michael Brown wrote:
The address translation logic in get_physical_address() will currently
truncate physical addresses to 32 bits unless long mode is enabled.
This is incorrect when using physical address extensions (PAE) outside
of long mode, and so this is a generalisation of the
current test.
Remove the #ifdef TARGET_X86_64 check since PAE exists in both 32-bit
and 64-bit processors, and both should exhibit the same truncation
behaviour when PAE is disabled.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/204
On 03/04/2023 11:13, Chao Li wrote:
This problem is because the gcc-12 does not yet to support the option
'mno-explicit-reloc', this option is used to open the new reloaction
type for LoongArch, this new feature is very important for LoongArch,
because it can reduce the binary size and improve
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 9d83974ec9..ac1adca543 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -91,6
The USB_CDC_SET_ETHERNET_PACKET_FILTER request is mandatory for
CDC-ECM devices. Accept this request, ignoring the actual filter
value (to match the existing behaviour for RNDIS).
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw
The xHCI controller will ignore the endpoint MTU and so may deliver
packets of any length. Detect short packets as being any packet that
has a length of zero or a length that is not a multiple of the MTU.
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c | 2 +-
1 file changed, 1 insertion
usbnet_receive() does not currently wake up the USB endpoint, leading
to a dead RX datapath when used with a host controller such as xHCI
that relies on being woken up.
Fix by adding a call to usb_wakeup() at the end of usbnet_receive().
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c
From: Michael Brown
Fix some minor violations of the CDC-ECM specification and some
interoperability issues with the emulated xHCI controller.
This patch series has been working out-of-tree since 2015; my
apologies for not getting around to upstreaming it sooner.
Michael Brown (4):
usbnet
On 22/07/2020 15:13, Daniel P. Berrangé wrote:
We could easily define etc/ipxe/https/{ciphers,cacerts} paths in a
different format if better suited for iPXE. Libvirt can set the right
path depending on whether its booting a VM with EDK2 vs legacy BIOS
The most useful for iPXE would probably be
On 22/07/2020 14:21, Michael Brown wrote:
After looking at https://ipxe.org/cfg/crosscert I'm not convinced this
is a good idea though. This would likely put quite some load to
ca.ipxe.org. Also that machine becomes a single point of failure for
worldwide ipxe https boot, and looking th
On 22/07/2020 13:08, Gerd Hoffmann wrote:
With the world moving to use https by default people start to ask for
https being enabled by default for the qemu boot roms.
We could simply flip the DOWNLOAD_PROTO_HTTPS switch in
src/config/qemu/general.h (ipxe git repo). Note that this would only
aff
The USB_CDC_SET_ETHERNET_PACKET_FILTER request is mandatory for
CDC-ECM devices. Accept this request, ignoring the actual filter
value (to match the existing behaviour for RNDIS).
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw
The xHCI controller will ignore the endpoint MTU and so may deliver
packets of any length. Detect short packets as being any packet that
has a length of zero or a length that is not a multiple of the MTU.
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c | 2 +-
1 file changed, 1 insertion
This patch series fixes a few minor issues discovered when attempting
to use the CDC-ECM configuration for usbnet with the xHCI host
controller.
usbnet_receive() does not currently wake up the USB endpoint, leading
to a dead RX datapath when used with a host controller such as xHCI
that relies on being woken up.
Fix by adding a call to usb_wakeup() at the end of usbnet_receive().
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c
Signed-off-by: Michael Brown
---
hw/usb/dev-network.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 09312d4..f8e6e57 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -86,6 +86,8
On 28/01/16 10:19, Gerd Hoffmann wrote:
No idea. qemu is a very specific case, ipxe has drivers for the qemu
nics (both virtual such as virtio-net and emulated such as rtl8139), and
right now we actually build ipxe tree times (bios, efi-ia32,
efi-x86_64), then combine them into a single image, u
On 26/01/16 14:21, Gerd Hoffmann wrote:
A fedora user requested it here:
https://bugzilla.redhat.com/show_bug.cgi?id=1280318
Ping?
What is the reason for ipv6 not being enabled by default?
Just historical?
Rarely used in practice?
ROM image size issues?
Stability concerns?
From qemu point of
On 20/10/15 09:16, Gerd Hoffmann wrote:
Hmm, EfiPxeBaseCode*Callback*Protocol?
Ping. Any progress here?
Meanwhile I've noticed efi grub2 fails to load grub.cfg on microsoft
hyper-v too, so possibly this is something in grub not ipxe ...
Haven't had time to look at it yet, sorry. It _is_ st
On 10/09/15 16:20, Gerd Hoffmann wrote:
Thanks. From my experiments, it seems that GRUB is using the hardcoded
path /efi/boot/grub.cfg to locate the configuration file, regardless of
where grub.efi was loaded from.
Hmm, probably depends on how you are building it. There are also tools
like gr
On 07/09/15 15:58, Gerd Hoffmann wrote:
This is generated by a script which does also copy the kernels to the
tftproot, there are more simliar entries for more RHEL versions but this
should be enough to get the idea ...
First entry actually works. Second does not, but I'm hoping some day it
doe
On 07/09/15 11:14, Gerd Hoffmann wrote:
ipxe just got a EFI_PXE_BASE_CODE_PROTOCOL implementation. I've updated
ipxe and commented the EFI_DOWNGRADE_UX define in the qemu config. If
you want to test this you can fetch the qemu branch with the updated
roms here:
https://www.kraxel.org/cgit/qemu
On 21/07/15 23:58, Laszlo Ersek wrote:
Instead of propagating that fix
into QEMU, let's focus on ipxe upstream to solve the problem.
How's this for focus:
(1) [PATCH] efi_snp: improve compliance with the
EFI_SIMPLE_NETWORK_PROTOCOL spec
http://thread.gmane.org/gmane.network.i
On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
> Which is exactly what happens here. My understanding of big real mode is
> that to achieve a segment limit != 0x, you must go into 32-bit
> protected mode, load a segment with a larger limit, and return into real
> mode without touching the se
On Monday 21 Mar 2011 21:40:31 Stefan Hajnoczi wrote:
> > Yes, iPXE for UEFI exists and works. Last tested by me about a week ago,
> > on various IBM UEFI systems.
> >
> > Compared to a "legacy" BIOS network boot, you can't do anything very
> > interesting with UEFI. Features such as iSCSI, FCoE,
sing a CSM where you can:
> >> * Load a legacy option ROM (vbios, or disk rom),
> >> and use it during a UEFI boot
> >
> > Is there gPXE for UEFI yet?
>
> I have never tried it myself, but I think it should work. CCed
> Michael Brown to check.
Yes, iP
Hi,
I was hitting the STOP 0x00A5 error when attempting to boot Vista or
similar (Server 2008, WinPE) on current qemu CVS. Googling suggested that
this was a problem with the qemu BIOS not supporting ACPI 2.0.
Replacing pc-bios/bios.bin with the bios/BIOS-bochs-latest from current
bochs C
On Thu, 24 Aug 2006, Michael Brown wrote:
I've found what looks like a bug in hw/serial.c; the structure field
"divider" is only a uint8_t, but should be a uint16_t. This currently
breaks Etherboot, which is somewhat paranoid about the UART and will
verify that both bytes of
I've found what looks like a bug in hw/serial.c; the structure field
"divider" is only a uint8_t, but should be a uint16_t. This currently
breaks Etherboot, which is somewhat paranoid about the UART and will
verify that both bytes of the divider are functional. (Don't ask me why.)
The attach
34 matches
Mail list logo
