On 9/11/24 03:28, Peter Maydell wrote:
> On Wed, 11 Sept 2024 at 07:27, Jacob Abrams wrote:
>> On 9/10/24 02:34, Peter Maydell wrote:
>>> If we make the .impl and .valid changes, then the result is
>>> that we permit 16 bit writes to come through to the read
>&g
On 9/10/24 02:34, Peter Maydell wrote:
> On Mon, 9 Sept 2024 at 18:40, Philippe Mathieu-Daudé
> wrote:
>>
>> Hi,
>>
>> (Cc'ing Arnaud & Inès who are listed as maintainers)
>>
>> On 6/9/24 18:12, Peter Maydell wrote:
>>> On Mon
read and write")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2540
Signed-off-by: Jacob Abrams
---
hw/char/stm32l4x5_usart.c | 16 +
tests/qtest/stm32l4x5_usart-test.c | 36 +-
2 files changed, 51 insertions(+), 1 deletion(-)
diff
On 9/9/24 10:40, Philippe Mathieu-Daudé wrote:
> Hi,
>
> (Cc'ing Arnaud & Inès who are listed as maintainers)
>
> On 6/9/24 18:12, Peter Maydell wrote:
>> On Mon, 2 Sept 2024 at 14:38, Jacob Abrams wrote:
>>>
>>> These changes allow th
should restore ISR to default value.
Fixes: 87b77e6e01ca ("hw/char/stm32l4x5_usart: Enable serial read and write")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2540
Signed-off-by: Jacob Abrams
---
Changes since version 1:
- Add qtest_quit to end of new test
hw/char/stm32l4
On 9/6/24 09:12, Peter Maydell wrote:
> On Mon, 2 Sept 2024 at 14:38, Jacob Abrams wrote:
>>
>> These changes allow the official STM32L4xx HAL UART driver to function
>> properly with the b-l475e-iot01a machine.
>>
>> Modifying USART_CR1 TE bit should alter USA
should restore ISR to default value.
Fixes: 87b77e6e01ca ("hw/char/stm32l4x5_usart: Enable serial read and write")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2540
Signed-off-by: Jacob Abrams
---
hw/char/stm32l4x5_usart.c | 29 +++---
tests/qtest/stm32
Thank you for the info.
Current issues tracking this bug:
https://gitlab.com/qemu-project/qemu/-/issues/675
https://gitlab.com/qemu-project/qemu/-/issues/1468
https://gitlab.com/qemu-project/qemu/-/issues/1802
--
You received this bug notification because you are a member of qemu-
devel-ml, whic
Tested and this issue still affects the latest version of QEMU (8.2.0)
compiled for Windows.
Instructions in original post are still sufficient to reproduce the problem on
Windows 7 x64.
Both i386 and x86_64 were tested and both result in a hung QEMU process, except
on my system the GUI for QEMU
Understood, thanks. Will stick to GUI app.
On Mon, 6 Feb 2023 at 11:19, Bin Meng wrote:
> On Mon, Feb 6, 2023 at 5:55 PM Philippe Mathieu-Daudé
> wrote:
> >
> > Cc'ing Yonggang & Stefan.
> >
> > On 5/2/23 13:01, Jacob A wrote:
> > > Hello,
>
Hello,
After installing Qemu on Win, I don't see any shortcut to run it? There is
only a link to 'uninstall'. launching exe files doesn't do anything. Can
you please explain how to launch this application?
Thanks,
J.
Please see the attached image.
Public bug reported:
>From HD audio spec, section 3.3.35:
"Stream Reset (SRST): Writing a 1 causes the corresponding stream to be
reset. [...] After the stream hardware has completed sequencing into the
reset state, it will report a 1 in this bit. Software must read a 1 from
this bit to verify th
Public bug reported:
According to HDA specification, "3.1.2 General Register Behaviors and
Access Requirements":
"All controller registers must be addressable as byte, Word, and Dword
quantities."
But e.g. if you try the following to reset and enable the CORB, assuming
es:esi contains the base M
. The host OS is RHEL 7. Currently, I have the VM
connected to a macvtap interface for the physical device I want to sniff, but I
am not seeing any data on Wireshark.
Any help/advice is greatly appreciated.
Regards,
Jacob
Sent with [ProtonMail](https://protonmail.com) Secure Email.
I see you point. Just close this issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1775366
Title:
[Feature request] qemu-ga - Allow unexpected parameter
Status in QEMU:
New
Bug description:
Public bug reported:
It whould be nice if the qemu-ga allowed received messages to contain
fields which is not part of the spec. In my example I have a host which
sends the following request:
{"execute":"guest-exec","arguments":{"path":"prl_nettool","capture-
output":true,"execute-in-shell":false
t; > To: Liu, Yi L
> > > > Cc: Jean-Philippe Brucker ;
> > > > Tian, Kevin ; Liu, Yi L
> > > > ; Lan, Tianyu ;
> > > > Raj, Ashok ; k...@vger.kernel.org;
> > > > jasow...@redhat.com; Will Deacon ;
> > > > pet...@redhat.co
gt; + intel_iommu_get_pts(iommu));
> > + ret = -EINVAL;
> > + goto out;
>
> equal is not valid?
you are right, equal is valid. I was thinking of shared PASID space
between guest and host but that is not the case here.
The rest of your comments are taken too, thanks for the review.
Jacob
On Wed, 26 Apr 2017 17:56:45 +0100
Jean-Philippe Brucker wrote:
> Hi Yi, Jacob,
>
> On 26/04/17 11:11, Liu, Yi L wrote:
> > From: Jacob Pan
> >
> > Virtual IOMMU was proposed to support Shared Virtual Memory (SVM)
> > use case in the guest:
> > https:
On Tue, Mar 24, 2015 at 10:53 AM, Shannon Nelson
wrote:
> On Tue, Mar 24, 2015 at 7:13 AM, jacob jacob wrote:
>> After update to latest firmware and using version 1.2.37 of i40e
>> driver, things are looking better with PCI passthrough.
>>
>> ]# ethtool -i eth3
>>
27;ll post further updates as i make progress.
Thanks for all the help.
On Mon, Mar 23, 2015 at 3:19 AM, Stefan Assmann wrote:
> On 20.03.2015 21:55, jacob jacob wrote:
>> On Thu, Mar 19, 2015 at 10:18 AM, Stefan Assmann wrote:
>>> On 19.03.2015 15:04, jacob jacob wrote:
>&g
On Thu, Mar 19, 2015 at 10:18 AM, Stefan Assmann wrote:
> On 19.03.2015 15:04, jacob jacob wrote:
>> Hi Stefan,
>> have you been able to get PCI passthrough working without any issues
>> after the upgrade?
>
> My XL710 fails to transfer regular TCP traffic (netperf). I
On Thu, Mar 19, 2015 at 5:53 PM, jacob jacob wrote:
> On Thu, Mar 19, 2015 at 5:42 PM, Shannon Nelson
> wrote:
>> On Thu, Mar 19, 2015 at 2:04 PM, jacob jacob wrote:
>>> I have updated to latest firmware and still no luck.
>>
>> [...]
>>
>>> [
On Thu, Mar 19, 2015 at 5:42 PM, Shannon Nelson
wrote:
> On Thu, Mar 19, 2015 at 2:04 PM, jacob jacob wrote:
>> I have updated to latest firmware and still no luck.
>
> [...]
>
>> [ 61.554132] i40e :00:06.0 eth2: the driver failed to link
>> because an u
ch hw issues..
On Thu, Mar 19, 2015 at 4:15 AM, Stefan Assmann wrote:
> On 18.03.2015 23:06, Shannon Nelson wrote:
>> On Wed, Mar 18, 2015 at 3:01 PM, Shannon Nelson
>> wrote:
>>>
>>>
>>> On Wed, Mar 18, 2015 at 8:40 AM, jacob jacob wrote:
>>>>
Hi Stefan,
have you been able to get PCI passthrough working without any issues
after the upgrade?
Thanks
Jacob
On Thu, Mar 19, 2015 at 4:15 AM, Stefan Assmann wrote:
> On 18.03.2015 23:06, Shannon Nelson wrote:
>> On Wed, Mar 18, 2015 at 3:01 PM, Shannon Nelson
>> wrote:
>
I was going to try this on fedora 21...now not very sure if that makes
much sense..
On Thu, Mar 19, 2015 at 4:15 AM, Stefan Assmann wrote:
> On 18.03.2015 23:06, Shannon Nelson wrote:
>> On Wed, Mar 18, 2015 at 3:01 PM, Shannon Nelson
>> wrote:
>>>
>>>
>>&
On Wed, Mar 18, 2015 at 11:24 AM, Bandan Das wrote:
> [Ccing netdev and Stefan]
> Bandan Das writes:
>
>> jacob jacob writes:
>>
>>> On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das wrote:
>>>> jacob jacob writes:
>>>>
>>>>> I
On Mon, Mar 16, 2015 at 3:49 PM, Bandan Das wrote:
> jacob jacob writes:
>
>> On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das wrote:
>>> jacob jacob writes:
>>>
>>>> I also see the following in dmesg in the VM.
>>>>
>>>> [
On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das wrote:
> jacob jacob writes:
>
>> I also see the following in dmesg in the VM.
>>
>> [0.095758] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-ff])
>> [0.096006] acpi PNP0A03:00: ACPI _OSC support notification
)
[0.097072] acpi PNP0A03:00: fail to add MMCONFIG information,
can't access extended PCI configuration space under this bridge.
Does this indicate any issue related to PCI passthrough?
Would really appreciate any input on how to bebug this further.
On Fri, Mar 13, 2015 at 10:08 AM, jacob
rough i see issues. It
is always pointing to some issue with packet transmission. Receive
seems to work ok.
On Thu, Mar 12, 2015 at 8:02 PM, Bandan Das wrote:
> jacob jacob writes:
>
>> On Thu, Mar 12, 2015 at 3:07 PM, Bandan Das wrote:
>>> jacob jacob writes:
>&g
On Thu, Mar 12, 2015 at 3:07 PM, Bandan Das wrote:
> jacob jacob writes:
>
>> Hi,
>>
>> Seeing failures when trying to do PCI passthrough of Intel XL710 40G
>> interface to KVM vm.
>> 0a:00.1 Ethernet controller: Intel Corporation Ethernet
>>
: 2.fc21
Kernel 3.18.7-200.fc21.x86_64
Rgds
Jacob
On Thu, Mar 12, 2015 at 12:26 PM, Alex Williamson
wrote:
> On Thu, 2015-03-12 at 12:17 -0400, jacob jacob wrote:
>> Hi,
>>
>> Seeing failures when trying to do PCI passthrough of Intel XL710 40G
>> interface to KV
e
passthrough.
Thanks
Jacob
] i40e :00:05.0 eth1: NIC Link is Down
> [ 43.011610] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full
Duplex, Flow Control: None
> [ 43.059976] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full
Duplex, Flow Control: None
>
>
> Would appreciate any information on how to debug this issue further and
if the "unhandled rdmsr" logs from KVM indicate some issues with the device
passthrough.
>
> Thanks
> Jacob
0: PF 40 attempted to control timestamp mode
> on port 1, which is owned by PF 1
> [ 39.892822] i40e :00:05.0 eth1: NIC Link is Down
> [ 43.011610] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full Duplex,
> Flow Control: None
> [ 43.059976] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full Duplex,
> Flow Control: None
Would appreciate any information on how to debug this issue further
and if the "unhandled rdmsr" logs from KVM indicate some issues with
the device passthrough.
Thanks
Jacob
Got this message:
unknown keycodes `empty_aliases(qwerty)', please report to
qemu-devel@nongnu.org
I opened Qemu to run an operating system that I'm building for a class,
before pressing Ctrl Alt Whatever to exit grab, I pressed alt tab, which
displayed that message. Hope this helps
Jacob
Hi Stefan,
On Thu, Feb 21, 2013 at 7:25 AM, Stefan Weil wrote:
> Am 21.02.2013 00:49, schrieb Jacob Kroon:
>> On Wed, Feb 20, 2013 at 9:46 PM, Jacob Kroon wrote:
>>> Paolo,
>>>
>>> Just a heads up, I tried the patched qemu (1+2+3) on my laptop at
>>>
On Wed, Feb 20, 2013 at 9:46 PM, Jacob Kroon wrote:
> Paolo,
>
> Just a heads up, I tried the patched qemu (1+2+3) on my laptop at
> home, which is running Windows 7 64-bit. I'm seeing qemu "lockups"
> appearing randomly.. Will try to debug it.
> On the other han
Paolo,
Just a heads up, I tried the patched qemu (1+2+3) on my laptop at
home, which is running Windows 7 64-bit. I'm seeing qemu "lockups"
appearing randomly.. Will try to debug it.
On the other hand, plain vanilla 1.4.0 in Windows 7 seems to run fine
with my VxWorks image..
Re
For linux, the build is done by the native Fedora 18 gcc, 4.7.2
For Win32, the build is done by Fedora 18's mingw compiler, 4.7.2
Configuration for Win32 (from config.log):
# Configured with: './configure' '--disable-guest-agent' '--disable-vnc'
'--disable-werror' '--extra-cflags=-pg' '--extra-ld
** Attachment added: "qemu-perf-win32.txt"
https://bugs.launchpad.net/qemu/+bug/1129957/+attachment/3536182/+files/qemu-perf-win32.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1129957
Title:
Public bug reported:
I'm seeing performance issues when booting a guest image on qemu 1.4.0 compiled
for the Win32 platform.
The same image boots a lot faster on the same computer running qemu/linux on
Fedora via VmWare, and even running the Win32 exectuable via Wine performs
better than runnin
** Attachment added: "qemu-perf-wine.txt"
https://bugs.launchpad.net/qemu/+bug/1129957/+attachment/3536183/+files/qemu-perf-wine.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1129957
Title:
call.
> This usually results in an unresolved symbol "ffs" at link time.
>
> The patch enforces inline code for this special case.
>
> Cc: Jacob Kroon
> Signed-off-by: Stefan Weil
> ---
>
> Hi Jacob,
>
> please try the patch below. If it does not fix t
eletor temp]$ i686-w64-mingw32-nm test.o
b .bss
d .data
N .debug_abbrev
N .debug_aranges
N .debug_frame
N .debug_info
N .debug_line
N .debug_loc
U _ffs
T _main
U ___main
t .text
Regards
Jacob
Hi Andreas,
On Fri, Feb 15, 2013 at 7:03 PM, Andreas Färber wrote:
> Hi Jacob,
>
> Am 06.02.2013 14:12, schrieb Jacob Kroon:
>> I'm trying to cross-build qemu for win64 on a Fedora 18/x86_64 system,
>> using all the necessary mingw64 packages from Fedora. Usi
qemu'
make: *** [qemu-build] Error 2
Same problem happens when linking qemu-io.exe and qemu-system-i386w.exe.
If necessary, please CC me as I am not a subscriber to the mailing list.
Regards
Jacob
this was not a qemu bug, i hate linux disk labels.
** Changed in: qemu
Assignee: (unassigned) => Adam Jacob Muller
(78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvk-launchpad)
** Changed in: qemu
Status: New => I
Public bug reported:
This seems inexplicable but has been verified in a number of ways.
Given the following domain XML (from libvirt):
/usr/bin/kvm
creates the following qemu command line:
LC_ALL=C
P
Hi Andy
When i look at your w7 partition table output, then there seems to be a
problem with start/end cylinders.
Your first partitions last cylinder is 13, but also the start cylinder
of your second partition is 13. two partitions should not share the same
cylinder/sector! Something seems to be
I run into the same problem, but the workaround regarding editing the
number of heads in the ntfs partition boot sector did it for me. Little
Howto:
Asume: A raw complete harddisc image within a bootable NTFS partition
with XP or 2k3 on it
Incident: when using these image with kvm based qemu, the
On Sun, Feb 14, 2010 at 01:04:31PM +0100, Paolo Bonzini wrote:
> On 02/14/2010 08:23 AM, Blue Swirl wrote:
> >On OpenBSD, pkg-config sdl --cflags forgets to add -I/usr/local/include
> >which is needed for iconv.h (included from SDL.h). This makes SDL
> >detection fail.
> >
> >Try sdl-config first,
Hello,
I am experiencing a crash in qemu when trying to load an existing
known-working image:
[EMAIL PROTECTED] gdb /usr/local/bin/qemu qemu.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
55 matches
Mail list logo
