Issue related with the xen

[Kandyala Saikumar]

Hello expert

I am facing the issue when I am booting the xen using qemu .Here I am
giving my steps how I did it.
 Firstly I downloaded the petalinux installer and then i have setup the
environment for the petalinux installer.And then i went to downloaded the
BSP OF ZCU102 I have created the project for it using the
petalinux-commands I did the menu-config and build the image. After
booting the builded image using petalinux-boot --qemu --prebuilt 2 i am
boot from the u-boot using this command Then now i check in the menu-config
for XEN there i enabled the XEN tools i re-builded the image again Now can
i see the xen boot scripts files and xen confg files Now i want to boot the
xen using the qemu could you please give anyone what was the command to
boot the xen.

with regards
k sai kumar

Re: Hello experts, please help me sort this out

[Frantisek Rysanek]

I've checked the posting at serverfault.com.
It seems that yours is a bit of a noob question, and you got some 
harsh love in return... :-)

I'm not sure how to read your question at serverfault.com.
There's a sequence of "ip ... " commands.
The last one is the addition of a default route, pointing to 
192.168.72.1. I suppose that's your router, physically reachable via 
eno1 in the HV/host machine.
If I understand correctly, these commands are executed on the host?
Would make sense.

I understand that the physical eno0 gets bridged together with the 
tap interfaces going to the VM guests, and your host/HV instance of 
Linux accesses the network via the "artificial" br0 interface.
I.e., the host/HV Linux instance and the VM/guest linux instances 
"sit side by side" on the same L2 network.
Good.

My counter-question is: exactly how did you set up the networking 
inside your VM guests?
Those guest OS environments are Ubuntu as well?
Note that Ubuntu (and modern Debian) can take network configuration 
in about two or three different styles, managed by different 
services. I recall the classic /etc/network/interfaces, or 
alternative config via the networkmanager's own config files, and I 
have a faint recollection of there being yet another way.
Yes you can just run "ip ... whatever" by hand from the command line, 

and it takes immediate effect - but note that you manipulate the 
runtime config, and your mods to the runtime config of IP networking 
will probably get clobbered / flushed the next time the 
networkmanager or the ifup/ifdown scripts have a go, based on their 
respective config and some "event" that triggers them.

And, one *specific* question:
do you have the default route set up in the VM guest OS instances?
A missing default route in the guests would explain your symptoms.
Can you ping the default GW from inside the VM guests?

In case you were wondering, note that you do *not* need specific 
routes to the VM guests, in the HV/host instance, nor at the firewall
- as the host/HV and the VM/guests and your default HW all sit on the 

same L2 segment = they share a locally connected IP subnet = ARP 
handles the nitty gritty of local reachability.

Frank


From:   Vishnupriya Karthy 
To: "qemu-discuss@nongnu.org" 
Subject:Hello experts, please help me sort this out
Date sent:  Wed, 5 Mar 2025 07:16:48 +

> 
> QEMU INTER-VM COMMUNICATION
> https://serverfault.com/q/1174304/1239769?sem=2 

Re: Timer quality

[Frantisek Rysanek]

Dear YangFeng,

thanks for the question :-)

Timekeeping is a complex topic.
Could you perhaps add more detail on what you are trying to achieve?
Linux offers various API functions for timing, in the kernel and in 
the user space - though oops, you haven't mentioned what guest VM you 
are considering...
Different timing functions serve different purposes, and under the 
hood, they tap into different hardware "resources" available (timers, 
counters, whatever). Such as, you can ask the guest OS:
- "wake me up after 20 ms, starting from now"
- Or, you can ask it "wake me up at 13:07:21.057 precisely". 
- Or, you may merely want to know "what time is it, right now as I'm 
asking?" 

Note that QEMU/KVM comes accompanied by a set of guest-side drivers. 
One of them presents a virtual PHC. This will provide a fairly 
precise answer to the question "what time is it right now", tapping 
into the host's timebase and hardware. Ordinarily, you would let your 
guest OS sync its timebase to that PHC, and your applications running 
in the guest would then get precise time just by asking their OS in 
the standard way.

If the question really is, "how precise are the emulated HW timers", 
e.g. the PC AT i8254 programmable timer, or some HPET (not sure if 
this even gets emulated) - obviously that emulation is not so rosy. 
Its precision boils down to event (interrupt) handling latency and 
jitter. Things are relatively good if you have a whole CPU core 
reserved to the particular VM guest instance - but if multiple guest 
VM instances share the time of a physical host CPU core, guess what's 
likely to happen... Same thing if the HV/host OS instance is busy, 
especially if busy serving other interrupts.

Please note that the PIT and HPET exist just once for the whole 
physical machine (are a part of the chipset) and therefore need to be 
emulated for each VM guest instance.
Modern x86 CPU's supposedly also have the "local APIC timer" - and 
the LAPIC supposedly is private to a CPU core. Not sure to what 
extent the LAPIC is beneficial to virtualization - you could argue 
that the VM guest could use it directly, if the CPU core is 
reserved/dedicated to a particular guest. Yet I wouldn't bet on this, 
and for the general case, the host / HV will likely want to keep a 
handle on the LAPIC timer per core (and maybe make it available to 
the VM guest through some virty encapsulation mechanism).
The one hardware counter that IMO needs no virty wrappers, is the TSC 
:-) It just counts forward, at some constant frequency, derived by 
multiplication from the physical CPU's external reference base.


I don't quite understand your note about the TCG *accelerator*.
I'm just a fellow user of QEMU, not conversant in the guts.
A quick google is telling me that the TCG is the code generator 
inside QEMU, that's able to emulate instructions not supported by 
your physical CPU.
In that vein, for optimal results, I would suggest to set the 
emulated CPU to "host" (=native). This should allow your guest OS to 
adapt to your host CPU's physical capabilities, thus all guest 
instructions get executed natively by bare metal, and thus the need 
to actually emulate instructions via the TCG gets minimized...

Frank

https://www.vmware.com/docs/vmware_timekeeping
https://wiki.osdev.org/APIC_Timer
https://airbus-seclab.github.io/qemu_blog/tcg_p1.html



Subject:Timer quality
From:   Yanfeng Liu 
To: qemu-discuss@nongnu.org
Date sent:  Wed, 05 Mar 2025 15:37:30 +0800

> Dear experts,
> 
> I am wondering how the precision of timers are with QEMU on x64 Ubuntu
> Linux and TCG accelerator?
> 
> Regards,
> yf
> 
> 
> 
> 

Re: Hello experts, please help me sort this out

[Howard Spoelstra]

On Wed, Mar 5, 2025 at 8:30 AM Kandyala Saikumar 
wrote:

> Hi Team
>
> we already raised this concern could you please anyone look on this issue
> for VM-VM communication
>
> On Wed, Mar 5, 2025 at 12:53 PM Vishnupriya Karthy <
> vishnupriya.kar...@multicorewareinc.com> wrote:
>
>> QEMU INTER-VM COMMUNICATION
>> https://serverfault.com/q/1174304/1239769?sem=2
>>
>
I don't know how the virtio-net-pci device works, but for other network
devices I guess you should also set different MAC addresses for them. If
you use an DHCP server it might give the same IP address to both devices.

This line cannot be correct:
sudo qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -hda ubuntu18.qcow2 -boot
d -cpu host -netdev tap,id=foo,ifname=tap0 -device
virtio-net-pci,netdev=foo0
as the id and netdev do no have the same name.

You might try with:
sudo qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -hda ubuntu18.qcow2 -boot
d -cpu host -netdev tap,id=foo0,ifname=tap0 -device virtio-net-pci,
mac=52:54:00:12:34:56 ,netdev=foo0

and
sudo qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -hda ubuntu22.qcow2 -boot
d -cpu host -netdev tap,id=foo1,ifname=tap1 -device virtio-net-pci,
mac=52:54:00:12:34:66,netdev=foo1

Re: Hello experts, please help me sort this out

[Frantisek Rysanek]

> I don't know how the virtio-net-pci device works, but for other 
> network devices I guess you should also set different MAC addresses
> for them. If you use an DHCP server it might give the same IP address
> to both devices.
>
...I actually suspect that QEMU (or the Linux kernel?) invents unique 
MAC addresses for the VM guest emulated NIC's... otherwise you'd see 
the warning in every tutorial, to set a unique MAC by hand.

And if the MAC addresses used by the VM guests were in fact indeed 
overlapping with each other, and possibly with the host, you'd get a 
problem with *ARP* even if DHCP is not in the game...

It should be trivial for the OP to learn the MAC address used by each 
VM guest. Just issue an ifconfig or "ip link show" inside the VM 
guest OS instance. And there are possibly other ways, such as using 
the qemu monitor command line or virsh... or just checking the BIOS 
SETUP inside the VM, or watching its PXE bootrom messages right after 
POST...

Frank

https://documentation.suse.com/de-de/sles/15-SP6/html/SLES-all/cha-qem
u-monitor.html

Simulating an NVMe device with multiple controllers

[David]

I'm trying to use Qemu to simulate an NMVe device with multiple 
controllers (is that the correct terminology?) to replicate some 
behavior that I'm seeing on a physical server.


On this server, I have two devices with a single namespace: nvme0n1 and 
a nvme1n1, but I also see a device named `nvme1c1n1` which is what I 
want to replicate.


How can I do that? Reading the NVMe documentation, I couldn't figure it out

The flags I tried were

|-device nvme,id=nvme-ctrl-0,serial=deadbeef \ -drive 
format=raw,file=disk.raw,if=none,id=nvm0 \ -device nvme-ns,drive=nvm0|


but when I do this, I the device is still "nvme0n1" without the controller


Thanks,

David