On Feb 4, 2025, at 11:08 PM, Gavin Shan wrote:
On 2/5/25 2:19 PM, Matthew R. Ochs wrote:
The MMIO region size required to support virtualized environments with
large PCI BAR regions can exceed the hardcoded limit configured in QEMU.
For example, a VM with multiple NVIDIA Grace-Hopper GPUs passed
> On Jan 29, 2025, at 2:15 AM, Eric Auger wrote:
> Hi Shameer,
>
> On 1/29/25 9:10 AM, Shameerali Kolothum Thodi wrote:
>>
>>> -Original Message-
>>> From: Eric Auger
>>> Sent: Wednesday, January 29, 2025 7:56 AM
>>> To: Matt Oc
On Jan 29, 2025, at 2:25 AM, Philippe Mathieu-Daudé wrote:
Hi Matthew,
On 28/1/25 17:02, Matthew R. Ochs wrote:
The MMIO region size required to support virtualized environments with
large PCI BAR regions can exceed the hardcoded limit configured in QEMU.
For example, a VM with multiple NVIDIA
> On Jan 28, 2025, at 11:52 AM, Eric Auger wrote:
>
> Hi Matthew, Shameer,
>
> On 1/28/25 6:36 PM, Shameerali Kolothum Thodi wrote:
>>
>>> -Original Message-
>>> From: Matthew R. Ochs
>>> Sent: Tuesday, January 28, 2025 4:03 PM
>>> To: qemu-devel@nongnu.org; Shameerali Kolothum Thodi
>
Thanks Alex
On Wed, Aug 30, 2023, 14:47 Alex Bennée wrote:
>
> Matt Borgerson writes:
>
> > Translation logic may partially decode an instruction, then abort and
> > remove the instruction from the TB. This can happen for example when an
> > instruction spans two p
On Sat, Jul 22, 2023 at 3:11 AM Richard Henderson
wrote:
>
> On 7/18/23 02:35, Matt Borgerson wrote:
> > If CF_PCREL is enabled, generated host assembly logging (command line
> > option `-d out_asm`) may incorrectly report guest instruction virtual
> > addresses as
If CF_PCREL is enabled, generated host assembly logging (command line
option `-d out_asm`) may incorrectly report guest instruction virtual
addresses as page offsets instead of absolute addresses. This patch
corrects the reported guest address.
Signed-off-by: Matt Borgerson
---
accel/tcg
Thanks Paolo!
On Fri, Jul 14, 2023 at 7:28 AM Paolo Bonzini wrote:
>
> Queued, thanks.
>
> Paolo
>
Thanks Alex!
On Mon, Jul 17, 2023 at 8:34 AM Alex Bennée wrote:
>
>
> Alex Bennée writes:
>
> > Matt Borgerson writes:
> >
> >> Translation logic may partially decode an instruction, then abort and
> >> remove the instruction from the TB. This can h
in the TB. This patch updates plugin_gen_tb_end to set the
final instruction count.
Signed-off-by: Matt Borgerson
---
accel/tcg/plugin-gen.c| 5 -
accel/tcg/translator.c| 2 +-
include/exec/plugin-gen.h | 4 ++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/accel/tcg
Hi Philippe,
> num_insns is a 'size_t'.
You are right. I copied the `int` type from `DisasContextBase`, but it
should really be `size_t`. I'll send an updated patch.
Thanks,
Matt
On Fri, Jul 14, 2023 at 11:09 AM Philippe Mathieu-Daudé
wrote:
>
> Hi Matt,
>
> On
in the TB. This patch updates plugin_gen_tb_end to set the
final instruction count.
Signed-off-by: Matt Borgerson
---
accel/tcg/plugin-gen.c| 5 -
accel/tcg/translator.c| 2 +-
include/exec/plugin-gen.h | 4 ++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/accel/tcg
resetting FPU state before the guest has a
chance to save it.
Signed-off-by: Matt Borgerson
---
target/i386/tcg/decode-new.c.inc | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/target/i386/tcg/decode-new.c.inc b/target/i386/tcg/decode-new.c.inc
index 46afd9960b
mctpi2c6 1 0x1d
Hi Klaus,
Thanks for the MCTP model, it's useful here.
I needed the following patch to be able to call SetupEndpoint again when a
device has already been assigned an EID. That tries a Set Endpoint ID/
Get Endpoint ID, addressed to EID 0.
Cheers,
Matt
---
>From cb7ad91474367f8
Qemu Linux Developers,
I’m looking for a solution to keep Hackintoshing a possibly for people like
me. I saw a group of people use your program and turned it into UTM a
problem using Qemu, but can emulate .ipsw restores of MacOS that include
the M1 Chip. The thing is UTM can only be run on a Mac O
seen at least one game make noticeable use of MMX/SSE features
though, which I also need to look at accelerating. Profiler indicates
they are also very costly. I have seen the TCG vector ops, which are a
very cool addition.
Matt
On Fri, Oct 1, 2021 at 1:24 AM Alex Bennée wrote:
>
>
&
ndling of floating point hard.
Agreed!
> I'll happily review patches on the list that provide for an accelerated
> FPU experience as long as the correctness is maintained.
Thank you!
Matt
On Thu, Sep 30, 2021 at 2:38 AM Alex Bennée wrote:
>
>
> Matt writes:
>
> &g
utilize it for accelerated floating point
emulation, and be able to be implemented for various TCG targets where
possible, with x86-64 and AArch64 being my priorities.
Thanks,
Matt
On Wed, Sep 29, 2021 at 10:39 PM Matt wrote:
>
> Hello--
>
> I'm excited to share that I have been devel
rties that this work is happening, to solicit any
early feedback, and to extend an invitation to anyone interested in
collaborating to expedite its upstreaming.
My initial TCG FP work can be found here:
https://github.com/mborgerson/xemu/pull/464/commits
Thanks,
Matt
It's still an issue using qemu-6.0.0-rc4. If you remove the environment
variable ENV GOPROXY="https://proxy.golang.org|direct" you get a
different error:
=> ERROR [6/6] RUN go build .
** Changed in: qemu
Assignee: (unassigned) => Matt Wilbur (mattwilbur)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1869497
Title:
x86_cpu_gdb_read_register segfaults when gdb reque
Public bug reported:
When attempting to attach to the gdbstub, a segfault occurs.
I traced this down to a problem in a call to gdb_get_reg16 where the
mem_buf was being treated like a uint8_t* instead of a GByteArray. The
buffer passed to gdb_get_reg16 ends up passing an invalid GByteArray
point
[ ping ]
Hi Paolo, would you mind taking a quick look at this patch for
memory.c to consider
it for merge? This resolves an issue with dirty bits not being cleared
as expected.
Here's the Patchwork link: http://patchwork.ozlabs.org/patch/1240121/
Thanks for your time!
Matt
On Tue, F
Currently only the final page offset is being passed to the `log_clear`
hook via `memory_region_clear_dirty_bitmap` after it is used as an
iterator in `cpu_physical_memory_test_and_clear_dirty`. This patch
corrects the start address and size of the region.
Signed-off-by: Matt Borgerson
Adding a ditto to this.
== Command and output ==
$ qemu-system-x86_64 -m 2G -hda mydisk.vdi -accel hvf -vga std
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.8001H:ECX.svm [bit 2]
Unimplemented handler (7fe3aac905e8) for 0 (f 11)
This is for a customized Ubuntu
of going through the patch you posted. Nice job! I'm
glad to see more people adding enhancements. It was pretty stale for years.
-Matt
On 7/5/19 12:50 AM, Klaus Birkelund wrote:
On Tue, Jul 02, 2019 at 10:39:36AM -0700, Matt Fitzpatrick wrote:
Adding namespace management support to the nvme device
Adding namespace management support to the nvme device. Namespace
creation requires contiguous block space for a simple method of allocation.
I wrote this a few years ago based on Keith's fork and nvmeqemu fork and
have recently re-synced with the latest trunk. Some data structures in
nvme.h
ping
From: no-re...@patchew.org
Sent: Thursday, January 31, 2019 9:53
To: mhi...@scalecomputing.com
Cc: f...@euphon.net; qemu-devel@nongnu.org; mhi...@scalecomputing.com;
mdr...@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3] QGA: Fix guest-get-fsinfo PCI
addresscollection in Windows
Patch v2 removed the device number and added a summary
From: Michael Roth
Sent: Thursday, January 24, 2019 9:56
To: mhi...@scalecomputing.com; qemu-devel@nongnu.org
Cc: Matt Hines
Subject: Re: [PATCH] QGA: Fix guest-get-fsinfo PCI address collection inWindows
Quoting mhi...@scalecomputing.com
, January 14, 2019 11:41
To: mhi...@scalecomputing.com; qemu-devel@nongnu.org
Cc: Michael Roth
Subject: Re: [Qemu-devel] [PATCH] QGA: Fix guest-get-fsinfo PCI
addresscollection in Windows
On 1/14/19 3:03 AM, mhi...@scalecomputing.com wrote:
> From: Matt Hines
>
> Signed-off-by: Matt Hi
On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote:
> Pulling this out of the shadows again.
>
> We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
> from Matt and Dongwong.
>
> At least from the intel side there seems to be the idea to just have
I found this bug report through https://redmine.pfsense.org/issues/7925
, btw.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1329956
Title:
multi-core FreeBSD guest hangs after warm reboot
Status
sorry, make that https://redmine.pfsense.org/issues/4377
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1329956
Title:
multi-core FreeBSD guest hangs after warm reboot
Status in QEMU:
Fix Release
I'm able to reproduce this issue, but using latest debian 9.
Debian 9
qemu version: 1:2.8+dfsg-6+deb9u3
kernel version: Linux vm2 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5
(2017-09-19) x86_64 GNU/Linux
I'm attempting to cold boot, or warm reboot, pfsense 2.4.2 amd64 iso
image guest. If I have
** Also affects: debian
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1329956
Title:
multi-core FreeBSD guest hangs after warm reboot
Status in QEMU:
effect in the adevs/qemu simulator.
>
> -Original Message-
> From: Matt [mailto:matta...@gmail.com]
> Sent: Monday, October 23, 2017 5:38 AM
> To: Nutaro, James J.
> Cc: Emilio G. Cota; qemu-devel@nongnu.org; Hajime Tazaki
> Subject: Re: [Qemu-devel] Running Qemu in discre
vents
from timers, asynchronous input-output, and bottom halves.
==
Do you manage to achieve perfect reproducibility with adevs + qemu ?
If yes, is there any publication describing how you achieve this ?
Best regards
matt
2017-10-21 0:02 GMT+09:00 Nutaro, James J. :
> Thanks for taking a look
be
possible to merge either approach or a similar one (adevs patch
doesn't seem too big ~500 lines), would that be of interest for the
Qemu comminity too ?
3/ if yes to 2. How to proceed, which one would be favorite ? if no,
what should be improved ? or would that be a definitive no ?
Best re
ping?
On 16/08/17 11:25, Marcel Apfelbaum wrote:
On 15/08/2017 17:44, Matt Redfearn wrote:
PCIe busses are always little endian, so set the endianness of the
memory region to little endian rather than native such that operations
work as expected on big endian targets.
Signed-off-by: Matt
intel-hda is currently using the old_mmio accessors for io.
This updates the device to use .read and .write accessors instead.
Signed-off-by: Matt Parker
---
v3:
* use MAKE_64BIT_MASK
---
hw/audio/intel-hda.c | 58 ++--
1 file changed, 11
On 22 August 2017 at 09:44, Peter Maydell wrote:
> On 21 August 2017 at 22:13, Matt Parker wrote:
>> intel-hda is still using the old_mmio accessors for io.
>> This updates the device to use .read and .write accessors instead.
>
> Hi; thanks for this patch.
>
>
I've just noticed the suggested changes from the v1 patch regarding
using MAKE_64BIT_MASK.
This patch is can be ignored for now.
On 23 August 2017 at 20:37, Matt Parker wrote:
> intel-hda is currently using the old_mmio accessors for io.
> This updates the device to use .read
intel-hda is currently using the old_mmio accessors for io.
This updates the device to use .read and .write accessors instead.
Signed-off-by: Matt Parker
---
hw/audio/intel-hda.c | 57 +---
1 file changed, 10 insertions(+), 47 deletions(-)
diff
intel-hda is still using the old_mmio accessors for io.
This updates the device to use .read and .write accessors instead.
---
hw/audio/intel-hda.c | 56 +---
1 file changed, 9 insertions(+), 47 deletions(-)
diff --git a/hw/audio/intel-hda.c b/hw/au
Both io and memory use the same mmio functions in the rtl8139 device.
This patch removes the separate MemoryRegionOps and old_mmio accessors
for memory, and replaces it with an alias to the io memory region.
Signed-off-by: Matt Parker
---
hw/net/rtl8139.c | 53
PCIe busses are always little endian, so set the endianness of the
memory region to little endian rather than native such that operations
work as expected on big endian targets.
Signed-off-by: Matt Redfearn
---
hw/pci/pcie_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Mon, Aug 14, 2017 at 10:40:27AM +0200, Paolo Bonzini wrote:
> On 12/08/2017 23:33, Matt Parker wrote:
> > This updates the current MemoryRegionOps for the bar 1 memory region
> > from using the old_mmio accessors to the .read and .write accessors.
> >
> >
This updates the current MemoryRegionOps for the bar 1 memory region
from using the old_mmio accessors to the .read and .write accessors.
Signed-off-by: Matt Parker
---
hw/net/rtl8139.c | 60 +++-
1 file changed, 16 insertions(+), 44 deletions
This updates the current MemoryRegionOps for the bar 1 memory region
from using the old_mmio accessors to the .read and .write accessors.
Signed-off-by: Matt Parker
---
hw/net/rtl8139.c | 60 +++-
1 file changed, 16 insertions(+), 44 deletions
On Tue, Oct 25, 2016 at 7:01 PM, Matt Broadstone wrote:
> On Tue, Oct 25, 2016 at 6:27 PM, Stefan Hajnoczi
> wrote:
>
>> On Tue, Oct 25, 2016 at 7:14 PM, Matt Broadstone
>> wrote:
>> > I've been attempting an experimental qemu agent using a node.js daemon
>
On Tue, Oct 25, 2016 at 6:27 PM, Stefan Hajnoczi wrote:
> On Tue, Oct 25, 2016 at 7:14 PM, Matt Broadstone
> wrote:
> > I've been attempting an experimental qemu agent using a node.js daemon on
> > the host side, and have run into an issue I was hoping someone here mi
olox/python-negotiator, which requires two
channels: one for host->guest communication, and another for guest->host
communication, likely because of this very issue.
Hopefully someone on this list is more familiar with how this all works and
can point out what I'm missing!
Regards,
Matt Broadstone
The file size was zero bytes (i.e., it contained no data).
I've tried again with QEMU 2.6.50 on a Windows 7 Professional system and
it appears to have created the s
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
Sorry, I accidentally submitted comment #3 without finishing it.
I was going to say that when I tried QEMU 2.6.50 on a Windows 7
Professional system, it appears to have created the image file
successfully.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
On Thu, 28 Jan, at 09:23:10AM, Gabriel L. Somlo wrote:
> From: "Gabriel Somlo"
>
> Allow access to QEMU firmware blobs, passed into the guest VM via
> the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
> size, and fw_cfg key), as well as the raw binary blob data may be
> accesse
Will do.
Thanks,
Matt
> On Dec 5, 2015, at 2:00 AM, Jan Kiszka wrote:
>
> On 2015-11-14 00:25, Matt Gingell wrote:
>> Hi,
>>
>> The following patches adds support for the new KVM split irqchip
>> interface discussed on the KVM mailing list.
>>
>>
This patch adds the initial plumbing for split IRQ chip mode via
KVM_CAP_SPLIT_IRQCHIP. In addition to option processing, a number of
kvm_*_in_kernel macros are defined to help clarify which component is
where.
Signed-off-by: Matt Gingell
---
hw/core/machine.c| 49
Hi Eric,
Thanks for your comments. I’m submitting a v2 based on your feedback.
Matt
> On Nov 13, 2015, at 4:11 PM, Eric Blake wrote:
>
> On 11/13/2015 04:25 PM, Matt Gingell wrote:
>
> [meta-comment:] This patch was sent without an In-Reply-To header tying
> it back to th
This patch adds the initial plumbing for split IRQ chip mode via
KVM_CAP_SPLIT_IRQCHIP. In addition to option processing, a number of
kvm_*_in_kernel macros are defined to help clarify which component is
where.
Signed-off-by: Matt Gingell
---
hw/core/machine.c| 48
ioapic_eoi_broadcast.
Signed-off-by: Matt Gingell
---
hw/i386/pc.c | 7 --
hw/i386/pc_piix.c| 4 ++--
hw/intc/ioapic.c | 63 ++--
include/sysemu/kvm.h | 5 -
kvm-all.c| 10 +++--
stubs/kvm.c | 2
appreciated.
Thanks,
Matt Gingell
jection isn't set correctly in
post_kvm_run_save.
I'm testing a small patch and we expect to submit that soon. With
fixes to those problems we're able to boot Windows and pass the KVM
unit tests.
Thanks,
Matt
Hi Jan,
Would you be able to look this over? I’d like to get this into shape to commit,
either now or once the corresponding kernel patch goes in.
Thanks,
Matt
Add support for KVM_CAP_SPLIT_IRQCHIP
Adds a new alternative 'split' to the -machine kernel-irqchip option.
When spl
erge marker
and a wonky #define in ioapic.c. I’ll update my procedures and avoid
this in future.
Thanks,
Matt
iece ready to submit, I'd appreciate
any feedback or discussion on the user space portion.
Thanks,
Matt Gingell
diff --git a/hw/core/machine.c b/hw/core/machine.c
index f4db340..3c14e78 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -11,6 +11,7 @@
*/
#include "hw/board
On Mon, 2015-07-13 at 16:09 -0400, Gabriel L. Somlo wrote:
>
> 3. I'm currently only handling x86 and I/O ports. I could drop the
>fw_cfg_dmi_whitelist and just check the signature, using mmio where
>appropriate, but I don't have a handy-dandy set of VMs for those
>architectures on whi
On Tue, 2015-07-14 at 13:00 -0400, Gabriel L. Somlo wrote:
>
> That being said, I did reimplement systemd's escape method in cca. 30
> lines of C, so that shouldn't be too onerous.
I really don't see a reason to use systemd's naming scheme instead of
the one already provided by the kernel.
> Bes
On Mon, 2015-03-16 at 10:15 -0400, Gabriel L. Somlo wrote:
> Allow user supplied files to be inserted into the fw_cfg
> device before starting the guest. Since fw_cfg_add_file()
> already disallows duplicate fw_cfg file names, qemu will
> exit with an error message if the user supplies multiple
> b
On Thu, 2015-02-26 at 10:45 +0100, Laszlo Ersek wrote:
> On 02/26/15 02:13, Gabriel L. Somlo wrote:
> > For myself, I'm tempted to write a kernel driver to allow me to simply
> > "cat /sys/firmware/fw_cfg/etc/guestinfo | grep '^key_name='" when I
> > need to retrieve a guest environment variable.
>
Marking as High since duplicate bug 1350766 was marked High.
** Changed in: nova
Importance: Medium => High
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815
Title:
qemu-img convert intermi
Is there a minimum version of qemu that would be required to use the
FIEMAP_FLAG_SYNC flag?
** Changed in: nova
Status: New => Triaged
** Changed in: nova
Importance: Undecided => Medium
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscri
I'm having this same issue. Tried with both FreeNAS (which uses FreeBSD
9), and a minimal install of FreeBSD 10. Everything seems to work great
up until you try to do a warm boot. I've compiled a custom FreeBSD
kernel with everything unnecessary removed, and also changed the number
of CPUs assigned
On 02/22/2014 02:01 AM, Paolo Bonzini wrote:
> Il 22/02/2014 05:37, Matt Lupfer ha scritto:
>> A HPET timer can be started when HPET is not yet
>> enabled. This will not generate an interrupt
>> to the guest, but causes problems when HPET is later
>> enabled.
>&g
lized). This results in a long period of no HPET
timer ticks.
When this occurs with a CentOS 5.x guest, the guest
may not receive timer interrupts during its narrow
timer check window and panic on boot.
Signed-off-by: Matt Lupfer
---
hw/timer/hpet.c | 3 ++-
1 file changed, 2 insertions(+), 1 del
On 02/21/2014 06:27 AM, Alex Bligh wrote:
>
> On 21 Feb 2014, at 04:34, Matt Lupfer wrote:
>
>>
>> This doesn't appear to be a solution, because with the timer rewrite, QEMU
>> moves its periodic (1 ms) qemu_notify_event() call to break out of
>> the main ev
le KVM PIT IRQ reinjection and to disable
the kvm kernel irqchip altogether result in less frequent panics, but the
guest still panics within 100 boots.
Thanks for any assistance you can provide.
Matt
Thanks for posting your script Tobias, I'm having the same problem on
Fedora 20 and the script alleviates the symptom.
Matt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1174654
Title:
Serge, I believe the other bug mentioned is this one:
https://bugs.launchpad.net/nova/+bug/1247185
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1248427
Title:
weather qemu-img convert will suppor
on to allow to
> > be configured as a binding point for any vendor's PV drivers.
> >
> > Signed-off-by: Paul Durrant
> > Cc: Stefano Stabellini
> > Reviewed-by: Andreas Färber
>
> Acked-by: Stefano Stabellini
Acked-by: Matt Wilson
> &g
gt; (consider cloud platforms).
I agree. If this is really the only solution, we would need to have
both versions presented to the guest so that old drivers continue to
work without any intervention.
Matt
> Expecting an admin to introspect the guest is not a good plan.
> Having the same set of levers that work at least reasonably with
> everything is the way to go.
>
Erik,
Is this patch available for public consumption? It doesn't seem to be
upstream.
Thanks,
#matt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall
** Summary changed:
- qemu-i386 user mode on ARMv5 host fails (bash: fork: Invalid argument)
+ qemu-i386 user mode fails (bash: fork: Invalid argument)
** Summary changed:
- qemu-i386 user mode fails (bash: fork: Invalid argument)
+ qemu-i386 user mode can't fork (bash: fork: Invalid argument)
The current implementation of pci_find_space does not correctly align
PCI capabilities in the PCI configuration space. It also does not
support PCI-Express devices. This patch fixes these issues.
Thanks to Alex Williamson for feedback.
Signed-off-by: Matt Renzelmann
---
Re-sending to add CC
Hi,
I just wanted to ping the status of this patch:
http://patchwork.ozlabs.org/patch/188032/
This version is different from v4 only in that it adds braces as recommended by
Blue Swirl.
Thanks and regards,
Matt
> -Original Message-
> From: qemu-devel-bounces+mjr=cs.wisc@nong
The current implementation of pci_find_space does not correctly align
PCI capabilities in the PCI configuration space. It also does not
support PCI-Express devices. This patch fixes these issues.
Thanks to Alex Williamson for feedback.
Signed-off-by: Matt Renzelmann
---
Braces added.
hw
The current implementation of pci_find_space does not correctly align
PCI capabilities in the PCI configuration space. It also does not
support PCI-Express devices. This patch fixes these issues.
Thanks to Alex Williamson for feedback.
Signed-off-by: Matt Renzelmann
---
This version adds the
>
> Mismatched uses of "size" here. We need both the end of the range to
> search and the size of the sub-range we're looking for. Maybe start,
> end, and size. Thanks,
>
Ah of course, how's this:
static int pci_find_space(PCIDevice *pdev, uint32_t start,
uint32_t e
> > static int pci_find_space(PCIDevice *pdev, uint8_t size, bool pcie_space)
> > {
> > int config_base;
> > int config_size;
> > int offset = PCI_CONFIG_HEADER_SIZE;
> > int i;
> > uint32_t *dword_used = &pdev->used[PCI_CONFIG_HEADER_SIZE];
>
> This needs to change too.
>
> I
ecification */
for (i = config_base; i < config_size; i += 4, dword_used++) {
if (*dword_used)
offset = i + 4;
else if (i - offset + 4 >= size)
return offset;
}
return 0;
}
Thanks for all your help wit
This patch fixes a bug affecting a variety of Neon instructions, such as
VQADD.
Signed-off-by: Matt Craighead
---
target-arm/neon_helper.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index 1e02d61..e0b9dbf 100644
One more bit of info:
There is a similar bug posted here, although they retitled it and
chalked it up to an unsupported platform: http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=641270
** Bug watch added: Debian Bug tracker #641270
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641270
*
Public bug reported:
Running aptitude in a lucid-based chroot qemu-arm-static on top of
amd64/oneiric segfaults/hangs. I get the segfault output about 30% of
the time, the rest of the time the problem exhibits as a hang. The
same commands work fine on a real armel platform (armv7l) running the
** Attachment added: "strace log for aptitude hold"
https://bugs.launchpad.net/bugs/898474/+attachment/2614331/+files/hold.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/898474
Title:
aptitud
** Attachment added: "strace log for aptitude show totem"
https://bugs.launchpad.net/qemu/+bug/898474/+attachment/2614332/+files/show.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/898474
Titl
me reason why libqemu is likely to be a bad fit that I haven't
spotted yet?
Cheers,
Matt
On Mon, Oct 4, 2010 at 8:00 PM, Jan Kiszka wrote:
> Am 04.10.2010 04:47, Matt Davis wrote:
>> Hello,
>> I am trying to debug a 32-bit linux kernel with gdb and qemu. My qemu
>> runs the 64-bit kernel as:
>> u...@host> qemu -kernel vmlinuz -S -s (not using k
I reported above. These
possibly cold be related:
http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00287.html
-Matt
From: Matt Waddel
Added support for the CP15c9-CR12 register(Performance Monitor Control
Register). Calls to this register are being implemented in the ARM Linux
kernel. The register has several bit fields, as described in the ARM
technical reference manual, but right now I only implemented it
"matt.kr...@amo.abbott.com", which I don't
think contains any invalid characters.
Matt
Hi,
I've submitted two trivial patches against QEMU in its bug tracker:
https://bugs.launchpad.net/qemu/+bug/568053
https://bugs.launchpad.net/qemu/+bug/568442
Is this sufficient or should I also submit them to the mailing list?
Matt
1 - 100 of 109 matches
Mail list logo
