In theory, external interrupts of guest VM are injected by KVM through "interrupt window", then what do handle_external_interrupt (in vmx.c) do? From the perspective of source code, it does nothing but recording.
One possible use is to trigger a vmexit for remote guest tlb flush IPIs.
You can check the kvm_vcpu_kick function in the kvm kernel module.
Related
Just start using XenServer. Doing some experiment for my company. Installed XenServer 7.4 on a Box and created a Centos 6.9 VMU. Using XenCenter.
Got to the point when I can run the virtual operating system but when I try to use the "Advanced Micro Devices, Inc. [AMD/ATI] Tonga XT GL [FirePro S7150]" graphic card with the command:
xe vgpu-create vm-uuid=xxx-xxx-xxx-xxx gpu-group-uuid=xxx-xxx-xxx-xxx
I receive the following error message:
The use of this feature is restricted.
I have also tried to install the graphic interface (Xen-Center) using a licensed Xen-Server to enable the AMD card using the Tools->Install Update: downloaded and selected the mxgpu-1.0.5.amd.iso to enable the Graphic card but I cannot complete the process as I receive the error message:
The attempt to create a VDI failed
I am running out of option. The CentOS is running but I cannot use the machine AMD graphic card. Can you help?
Could you try running the VM with the virtual disk stored on the same Local Storage repository located on that card's host, and removed from any pools. This is the default configuration, but I'd thought I'd mention these tips in case you have this box somehow mixed in a heterogenous pool. If the machine is part of a pool, make sure that you are not selecting the video adapter to passthrough to the VM of another host's adapter.
I'm studying SDNs and using different controllers (Floodlight 1.1, OpenDaylight Lithium-SR2). I have 2 VMs which can communicate via a private network. In the first VM there is the SDN controller, while in the second VM I can setup a network topology with Mininet via a Python script.
My goal is to find out the controller behaviour: given a topology with 5 switches (with loops) and only 2 hosts, after a "ping" command, which switch does the controller select for the path between hosts?
A "ping" command in Mininet implies ARP traffic (discovering hosts' MAC addresses) and ICMP echo requests/replies.
After a ARP_REPLY we see a PACKET_IN from the switch linked to the answering host and the controller sends a FLOW_MOD message to all the switches it selects for the path, according with OpenFlow 1.0 protocol. Look at this Sequence Diagram for an example.
I captured the traffic with "tcpdump" tool and studied it with Wireshark.
Using Floodlight I can see FLOW_MOD messages which include "src" and "dst" MAC addresses (to create the path), but not with OpenDaylight (there are FLOW_MOD messages, but only before ARP traffic and only with broadcast "src" and "dst" MAC addresses).
I would like to understand why I'm not able to see FLOW_MOD messages with correct MAC addresses "src" and "dst" AFTER ARP replies (and not BEFORE). I don't know if it depends on controller's code or on OpenFlow protocol.
Thanks in advance for your help.
I found the problem: ODL works in Proactive mode as default, so I wasn't able to see Flow_Mod messages with attached MAC addresses after ARP traffic. I set ODL in Reactive mode modifying some configuration files which are located in the [ODL-folder]/etc/opendaylight/karaf/ directory of the Controller folder:
54-arphandler.xml: by default, the property <is-proactive-flood-mode>
is setted to true, so ODL works in Proactive mode. If you want Hybrid
mode set that property to false and <is-hybrid-mode> to true. If both
properties are setted to false ODL works in Reactive mode.
58-l2switchmain.xml: set the property <is-install-dropall-flow> to
false. In this way switches send packets that don't have a match (in
the switch flow table) to the controller without dropping.
Now I can see Flow_Mod messages with attached MAC addresses and check which switch is choosen by ODL to build the path between hosts.
I'm working on an iMX23 cpu with linux-2.6.35.3 and wondering if this is even possible to implement.
I can build g_serial and g_multi and use the serial port function, which uses /dev/ttyGS0.
Do I just have to change [console=ttyS0] to [console=ttyGS0] on the kernel command line?
Thanks
Yes, it should be that simple. Just change your kernel command line to "console=ttyGS0,115200" or similar. You'll find it even works with usb ports ie "console=ttyUSB0" for example.
It seems you can easily add another console port just by adding another setting in [/etc/inittab]
::respawn:/sbin/getty -L ttyAM0 115200 vt100
::respawn:/sbin/getty -L ttyGS0 115200 vt100
Adding another line as above will enable you to use USB serial as console too(/dev/ttyGS0).
I have this USB Relay:
http://www.ebay.com/itm/5V-USB-Relay-2-Channel-Programmable-Computer-Control-For-Smart-Home-/141097843081?pt=LH_DefaultDomain_0&hash=item20da163989
Al I need is to send close/open to the device (to turn on & off an LED light)
How can I do that using C# or C++?
Thanks
Boaz
Here's what you need (tested on Linux) :
HIDAPI from http://www.signal11.us/oss/hidapi/
USBRELAY from https://github.com/darrylb123/usbrelay/blob/master/README.md
Use it like :
usbrelay ZG4HU_1=1
usbrelay ZG4HU_1=0
to switch the first relay on and off. ZG4HU_2 addresses the second relay and without arguments you even get the relay status.
-- Hans
The 26484 26483.rar is what I needed for Windows. .exe files for graphic and for command line for testing and .dll for my own development.
Found here: http://files.elektroda.net/794975,26484++26483+usbrelayextlib.html
This is sort of related to a previous, yet so far unsuccessful question of mine. I have a daemon that is placed in the LaunchAgents folder (on Mac) and it should run perpetually in the background, but after a couple of days it just stops for no apparent reason. I have no idea why and thus my question:
What are the reasons that a daemon might randomly stop?
Thanks for the help!
A Daemon is just a long lasting (forked) process. The reason a Daemon crashes is the same any other program crashes:
attempting to read or write memory
that is not allocated for reading or
writing by that application
(segmentation fault) or x86 specific
(general protection fault)
attempting to execute privileged or
invalid instructions
attempting to perform I/O operations
on hardware devices to which it does
not have permission to access
passing invalid arguments to system
calls
attempting to access other system
resources to which the application
does not have permission to access
(bus error)
attempting to execute machine
instructions with bad arguments
(depending on CPU architecture):
divide by zero, operations on denorms
or NaN values, memory access to
unaligned addresses, etc.
Since it's a LaunchAgent, it runs as part of your login session, and hence will be killed if you log out.
On the other hand, if it's dying before you log out, and you can't find/fix whatever is causing it to crash/exit, or you can tell launchd to automatically restart it by adding
<key>KeepAlive</key>
</true>
to its .plist