Wed, 9 Jun 2021, at 05:42, Berto Furth wrote:
> Hi Asif,
>
> It looks like your guest OS is in a different IP subnet than your virbr0
> interface.
>
> The host virbr0 is using 192.168.122.1/255.255.255.0 but the guest seems to
> have 192.168.1.2/255.255.255.0 (Notice the 3rd
Hi Asif,
It looks like your guest OS is in a different IP subnet than your virbr0
interface.
The host virbr0 is using 192.168.122.1/255.255.255.0 but the guest seems to
have 192.168.1.2/255.255.255.0 (Notice the 3rd octet is different)
Can you see what happens if you setup the guest as 192.168
Hi Chan,
Thanks for documenting the information below. I note you mention "you need
cache flush in the guest for this to work."
Do you know how to trigger this from the host side? That is, how do you make
QEMU running on the host force the guest CPU to flush it's cache? Is there a
QEMU functio
qemu_test/qemu-5.2.0/qemu-5.2.0/build/../etc/qemu/bridge.conf'
> qemu-system-aarch64: bridge helper failed
>
> Any inputs on this ? How can i resolve failed to parse default acl file ?
>
> Regards
> Asif
>
> On Wed, May 26, 2021 at 2:06 AM Berto Furth wrote:
>
regards,
> Daniele
>
> Il giorno mar 13 apr 2021 alle ore 02:56 Berto Furth ha
> scritto:
>> __
>> Hi Daniele,
>>
>> Thanks for collecting all that data. Very thorough. You certainly know what
>> you're doing!
>>
>> As you said the ARP
aniele,
Berto.
On Tue, 13 Apr 2021, at 08:25, Daniele Palmisano wrote:
> Hi Berto,
> Thanks for your reply. I'll add the info requested inline. Please find them
> below.
>
>
> Il giorno lun 12 apr 2021 alle ore 01:22 Berto Furth ha
> scritto:
>> __
>>
Hi Daniele,
Is it possible to get a "brctl showmacs br0" on the host while QEMU is running
to confirm that the mac address of the guest (which is distinct from the MAC
address of the tap0 interface) is showing up in the bridge table? Please also
ensure that the MAC address of your router is in
Hi Nikhil,
In my view the best and easiest way to accomplish tracing which machine level
instructions are being executed and what address (PC) is being executed is to
use gdb in conjunction with QEMU. Here's a brief writeup I've done on the
process cut and paste from another email I sent on the
There's no problem running a system as both a router and a host/desktop/server
of any other kind.
On Mon, 22 Mar 2021, at 19:05, Steve Litt wrote:
> Berto Furth said on Sun, 21 Mar 2021 08:32:28 +1100
>
> >Hi Steve,
> >
> >I'll let Peter reply but here's
Hi Steve,
I'll let Peter reply but here's my brief thought.
On Sun, 21 Mar 2021, at 02:57, Steve Litt wrote:
> pe...@easthope.ca said on Fri, 19 Mar 2021 09:33:07 -0700
>
>
> >(4) Q: Why does qemu involve a bridge rather than only routing?
> >
> >A: My hypothesis. Routing requires adjustment o
Hi Peter,
> Berto & all,
>
> The qemu guest here now has full connectivity.
Brilliant. Thanks for going to the effort of documenting exactly what you did
and how you got it to work. I'm sure that will help lots of people in the
future.
> These are my notes about differences from "ordinary" q
Just a correction. Make sure that
#!bin/sh
is the first line in the qemu-ifup file. I got the "#" and the "!" in the
wrong order in my email below. I'm sure it's already correct in your setup
anyway.
Thanks Peter.
On Fri, 19 Mar 2021, at 07:59, Berto Furth w
Hi Peter,
So just to get to your last point first again
"network script /etc/qemu-ifup failed with status 256"
might mean that qemu couldn't find the script or the file isn't executable.
Can you try again making sure that the /etc/qemu-ifup script exists, that it's
first line is "!#/bin/sh" a
Hi Peter,
On Thu, 18 Mar 2021, at 06:45, pe...@easthope.ca wrote:
> br0 received addresses here.
Awesome!
> > This is a long email. In answering your question I got on a roll and
> ended up writing an essay.
>
> A very helpful essay. I wonder whether you might incorporate it into
> the QEMU
to the "real" network.
If you accidentally get these services running on an interface connecting to
your real network they will conflict with the already running services and your
real network will be in chaos!!
There's no need for setting up your host as a DHCP or "radvd" serv
Hi Peter,
I'm assuming you're also using dynamically created "tap" interfaces in your
setup. That is, when QEMU starts it's creating a tap interface to funnel
Ethernet traffic to and from the guest...so a command line something like
-netdev type=tap,id=testnet,script="./qemu-tap-up",downscript=
I'm afraid I don't know the precise answer to your question but have you
considered using gdb to remotely debug the guest in QEMU to accomplish this?
With gdb running remotely you can step though assembly instructions being
executed by the guest one at a time and keep tabs on registers and so fo
2021, at 14:20, Sawyer Liu wrote:
> Hello Berto,
> Please see attached files are log. I have done "make clean" before
> "make".
> Thanks.
>
> Best Regards
> Sawyer Liu(刘维峰)
>
> -Original Message-
> From: Berto Furth
>
ed libssh(./configure --disable-libssh), but the
> result is the same as before. Cannot compile QEMU.
> Thanks.
>
> Best Regards
> Sawyer Liu(刘维峰)
>
> -Original Message-
> From: Berto Furth
> Sent: Monday, January 25, 2021 19:38
> To: Sawyer Liu ; Nerij
I believe we're talking about when you run "configure" to compile QEMU from the
source code. It's not a parameter you pass to QEMU itself.
So when you compile QEMU from the source code you first run something like...
configure --disable-libssh
make
Run "configure --help" to see all the availab
is same, cannot
> compile qemu.
>Thanks.
>
>
> Best Regards
> Sawyer Liu(刘维峰)
>
> *From:* Berto Furth
> *Sent:* Friday, January 22, 2021 14:18
> *To:* Sawyer Liu ; qemu-discuss@nongnu.org
> *Subject:* [EXT] Re: Bugs in SSH module
>
&g
I think the thing is that it seem to compile fine on systems other than Ubuntu
18 that have libssh installed so the problem is presumably with that particular
version of Ubuntu rather than QEMU.
Can you make sure that the "lib-sshdev" package is installed and up to date on
your system?
I can c
t an idea of what's going on.
Again, I guess all I can suggest is perhaps seeing if you can remove the
soundhw or if possible change the soundhw parameter. (Try -soundhw help" to see
what other options are available.)
Good luck!
On Sun, 17 Jan 2021, at 20:07, Tomas By wrote:
> On
Hi Tomas,
Is this related to the same "-kernel" question or is this a new topic?
Can you post the complete command line and parameters you're using to start
QEMU?
Interrupt 0x1E seems to be related to "SYSTEM DATA - DISKETTE PARAMETERS"
according to Ralf Brown's interrupt list. Could a disk dr
Hi Chan,
I don't think so. At least it doesn't seem to with the ARM machines I've used.
We probably need to know what machine/architecture you're using because I think
it can be different for different setups.
I wouldn't have thought it would matter though because if one boot loader sets
regis
Hi qemu friends,
I have noticed that when debugging a 32 bit arm (AA32) kvm guest running in a
64 bit ARM (aarch64 / AA64) host with "qemu-system-aarch64" and the
"aarch64=off" flag set that a remote gdb debugger still thinks that it's
debugging ARM64. This results in GDB being unable to proper
26 matches
Mail list logo
