[Qemu-devel] How to detect a stopped guest os?
Hello, I know, this is not the right place to ask, but I wasn't abled to find a users mailing list. The question: is there any qemu (monitor) command to detect if the guest os has stopped / poweroff? -- Wilhelm
[Qemu-devel] Dumb question using qemu in full-screen mode
Hi, this is surely an often asked question, but i did not find an appropriate answer: I have a ubuntu 10.04 host on which I would like to use qemu in full-screen mode at minumum 1024x768. On the host I start the xorg-server directly, that gives me video modes up to 1280x1024. Then I start qemu -full-screen, what switches the host-xserver back to 720x400 and later on to 800x600, when the guest starts X. In the guest I use an OpenBSD. If I use xrandr -q in the guest it gives me only 800x600 and 640x480. Any hints? -- Wilhelm
[Qemu-devel] Solaris 8 SPARC, Web Start Launcher Crashing
In late May of 2011, Brian Vandenberg queried this group about failures he was having trying to install Solaris 8 SPARC 02/04 on a Qemu VM. The interaction seemed to have ended with Blue Swirl indicating that Brian should run with "-d in_ascm,int" and that the debug output would likely be useful near the end of the output. I did searches on the mailing list from Brian's name but did not find another thread where his original was followed up on. Recently and without knowledge of the above, I began trying to to install Solaris 8 SPARC 10/01 into a Qemu VM using the git head (as of 10/25/2014) and openBIOS r1321. After struggling for a while, I found that the installations were failing during install when java was called to create the sysidcfg file. The error I am seeing is much like some of those posted in May 2011 by Brian V. I am running with the following command line options: qemu-system-sparc \ -bios openbios-builtin-sparc32.elf \ -hda test.disk \ -cdrom Solaris8Install.iso \ -prom-env 'auto-boot?=false' -m 256 -nographic The hard drive is a qcow2 image formatted using Solaris 8 install CD (booted Qemu in single user mode from CD) 'format' command to create a 36G Solaris disk. The initial format and software load appears to work without problem. Then after reboot using the hard disk to boot, "Web Start Solaris Command Line installation" comes up and says that it will ask about system identification information (Network, Name Service, Date and Time, etc.). It tells me to "Press Return to continue". I hit return and am greeted with: /sbin/disk0_install[60]: 125 Abort(coredump) Looking at the /tmp/disk0_install.log file shows that there was a fault during execution of "java sysid -nodisplay". The message from java in the install log was: signal fault in critical section signal number: 11, signal code: 1, fault address: 0xeac3, pc: 0xef2cd448, sp: 0xeb232c58 libthread panic: fault in libthread critical section : dumping core stacktrace: ef2cd43c ef2cf0d4 ef2c8d98 0 I created a debug log as suggested by Blue Swirl in his response to Brian V. in May 2011. I am able to find in the file where there is a Data Access Fault when the pc is at the above noted location. However, I am uncertain what to do with this information. Is this something where I should take a couple of hundred lines of the logfile before the above pc and Data Access Fault and include it here? Is there is an RTFM I missed? If so, oops, sorry (maybe just point me where I should go?). Respectfully, Paul W.
[Qemu-devel] Sparc Softmmu
I've been able to install Solaris 8 using CDs on the Sparc Softmmu client system. Kudos to those responsible for Sparc development! I've been able to run a number of applications without problems on the client machine. I noticed something odd, however, and have been trying to isolate the cause. Hopefully, someone here will have an idea or two for me to try. The issue: The syslogd seems to accept and post to the appropriate log file only a small number of messages before no longer updating the log file when further messages are posted, the syslogd seems to hang. The symptom does not appear to be different when rebooting or restarting the syslog daemon. The daemon will post a couple of message to the log file and then stop accepting any more. Why ask here? I've done a couple of things to see if I can isolate the source of the oddity and they seem to point to qemu. What I've done so far: 1) I've tried using "logger" and a C program I wrote to use the syslog() function. - Both have the same issue noted above. 2) I've used both the OpenBios and SS5.bin bios. - Symptom does not change between the two. 3) I checked my /etc/syslog.conf on real hardware running the same version of Solaris 8. Syslogging works as you'd expect there. (Note - I don't have real SparcStation 5 hardware. I've been using an old Sun4u machine, Ultra-1 -- hopefully, that does not invalidate my "real hardware" checks.). 4) I ran syslogd in debug mode on both the client and the real hardware, but did not see anything in the output from each that gave a clue as to the issue. Generally, the output confirmed that I had syslogd configured the same way on both. How to proceed? I am a reasonably adept software developer, however, I do not have experience at the guts-level of Solaris OS or Sparc hardware. My work on Solaris/Sparc has been at the application level, but I have worked at the hardware level on other (proprietary) systems. If I had access to syslogd source code, I'd be comfortable working from there, but I am fairly certain that is not available - let me know if I am wrong. I've thought about looking for an open source syslog daemon and trying to use it instead of the Solaris version. Any thoughts about next steps are appreciated. Respectfully, Paul
Re: [Qemu-devel] [offtopic] Sparc Softmmu
We use the old Solaris/Sparc in a medical device we produce where I work. Since we can't get new Sparc hardware any longer (many countries no longer accept "refurbished" devices - so we can't sell this product to them when we use refurbish IT parts) that is reasonable cost for our application, we need to find a way to continue to produce our product. The application is moderately complicated and will take some effort/time to port to another OS / processor. I was just evaluating the possibility of using an emulated Sparc machine to replace the Solaris box. The thought behind using Qemu was that we can reduce hardware obsolescence issues in the future with this layer of abstraction. Conceivably, future hardware changes would be easier to do with less regulatory overhead. My evaluation was exciting because I was able to, with just a couple of days of work, get our application up and running and talking to the other hardware associated our product. However, given the maturity level of Qemu for Solaris on Sparc, we'll almost certainly do a port of our application to other hardware and OS. With the evaluation work, my interest was piqued, so I've continued to play around with Solaris / Sparc on Qemu on my own time. Since I had a fairly well encapsulated symptom, I thought I might be able to help identify a fix or two for Qemu. Respectfully, Paul On 2/21/2012 12:49 PM, Artyom Tarasenko wrote: Hi Paul, may I ask you why do you need Solaris 8/sparc? I spent really a lot of time on sparc emulation in qemu, it was fun and I would probably do it further, but I saw no projects where it would be useful. Somehow it looked that all the apps available for Solaris are available for Linux/Windows as well... Do you by any chance have an example of an app which would be worth the efforts? Artyom On Sun, Feb 19, 2012 at 4:45 PM, P. Wilhelm wrote: I've been able to install Solaris 8 using CDs on the Sparc Softmmu client system. Kudos to those responsible for Sparc development! I've been able to run a number of applications without problems on the client machine. I noticed something odd, however, and have been trying to isolate the cause. Hopefully, someone here will have an idea or two for me to try. The issue: The syslogd seems to accept and post to the appropriate log file only a small number of messages before no longer updating the log file when further messages are posted, the syslogd seems to hang. The symptom does not appear to be different when rebooting or restarting the syslog daemon. The daemon will post a couple of message to the log file and then stop accepting any more. Why ask here? I've done a couple of things to see if I can isolate the source of the oddity and they seem to point to qemu. What I've done so far: 1) I've tried using "logger" and a C program I wrote to use the syslog() function. - Both have the same issue noted above. 2) I've used both the OpenBios and SS5.bin bios. - Symptom does not change between the two. 3) I checked my /etc/syslog.conf on real hardware running the same version of Solaris 8. Syslogging works as you'd expect there. (Note - I don't have real SparcStation 5 hardware. I've been using an old Sun4u machine, Ultra-1 -- hopefully, that does not invalidate my "real hardware" checks.). 4) I ran syslogd in debug mode on both the client and the real hardware, but did not see anything in the output from each that gave a clue as to the issue. Generally, the output confirmed that I had syslogd configured the same way on both. How to proceed? I am a reasonably adept software developer, however, I do not have experience at the guts-level of Solaris OS or Sparc hardware. My work on Solaris/Sparc has been at the application level, but I have worked at the hardware level on other (proprietary) systems. If I had access to syslogd source code, I'd be comfortable working from there, but I am fairly certain that is not available - let me know if I am wrong. I've thought about looking for an open source syslog daemon and trying to use it instead of the Solaris version. Any thoughts about next steps are appreciated. Respectfully, Paul
[Qemu-devel] Sparc-softmmu -- Debugging Results and Suggestions Request
Sirs, I've been trying to debug a problem with Solaris 8 running on sparc-softmmu. The syslog daemon in very unreliable (about 7 of 8 starts of the syslog daemon end in a daemon hang - the daemon can be "killed" and restarted manually). *Background:* I looked at the syslogd.c code on the Oracle web site to see what syslogd is doing. As part of initialization, syslogd tries to parse syslog.conf. To read the syslog.conf file, syslogd creates a pipe for output from m4. m4 is used to parse the syslog.conf file. Output from m4 is put into the pipe that is then read by the parent process. *Here is what I've done so far / learned:* After boot, I log in and stop the syslogd. I then truss (using -a -f and -sall flags) syslogd with the "-d" flag. On Qemu, the syslog daemon stops after the child process exits. No information generated by the child process and put into the pipe gets to the parent process before the hang. When I send SIGINT twice (hit ctrl-c twice -- one ctrl-c does not unblock pipe), the parent job sees the data in the pipe and completes reading data in the pipe before the syslog daemon exits due to the SIGINT. I thought the issue might be related to something that m4 was doing, so I replaced it with a shell script that output text like that actually output by m4 (I manually parsed the syslog.conf file). I saw the same behaviour - the syslogd parent process hung about the time the child process exited. I tried this on real Sparc hardware with the same OS. On real Sparc hardware the data appears in the pipe for use by the parent process about the time the child process exits. I thought the Qemu parent process might not be getting a SIGCLD or the SIGCLD might not be sent by the child when it exits. So I have tried sending SIGCLD manually using "kill". If I send SIGCLD twice (once does not unblock the pipe, but I do see system activity from truss with this first signal), the pipe is unblocked. The results are not consistent after the pipe is unblocked. Syslogd may post messages to the log file, it may take injecting new messages using "logger" to cause the backlog of messages to get to the log file, or I may need to restart syslog daemon (and SIGCLD again) to get messages to the log file. *What to do next?* I am not sure what to do next to help isolate what is going on (or not going on that needs to be). It looks like something with signals is not working correctly. I could try putting together a simple program to create a pipe much as is done in syslogd to try to replicate the issue with pipes in a simple way. But, I'm not sure how to dig deeper even if I were able to replicate the issue with a small program. Another thought is to create a Linux / Sparc32 machine to see if this issue is apparent there, as well. Having a simple program as noted above might help with this. *Suggestions?* Other Info: QEMU-1.1.0rc2 Openbios-1057 SunOS Release 5.8 Version Generic_108528-11 32-bit Respectfully, Paul
[PATCH] add option for a multislot usb ccid device
Signed-off-by: Wilhelm Golz
hw/usb/dev-smartcard-reader.c:
add option for a multislot usb ccid device, similar to audio multi.
---
hw/usb/dev-smartcard-reader.c | 106 +-
1 file changed, 103 insertions(+), 3 deletions(-)
diff --git a/hw/usb/dev-smartcard-reader.c b/hw/usb/dev-smartcard-
reader.c
index be0a4fc3bc..30d8892b4e 100644
--- a/hw/usb/dev-smartcard-reader.c
+++ b/hw/usb/dev-smartcard-reader.c
@@ -90,10 +90,13 @@ OBJECT_DECLARE_SIMPLE_TYPE(USBCCIDState,
USB_CCID_DEV)
* usbccid.sys (winxp, others untested) is a class driver so it
doesn't care.
* linux has a number of class drivers, but openct filters based on
* vendor/product (/etc/openct.conf under fedora), hence Gemplus.
+ * Use a Omnikey/HID 3121 with multislot for distinction.
*/
#define CCID_VENDOR_ID 0x08e6
#define CCID_PRODUCT_ID 0x4433
#define CCID_DEVICE_VERSION 0x
+#define CCID_VENDOR_ID_MULTI0x076b
+#define CCID_PRODUCT_ID_MULTI 0x3021
/*
* BULK_OUT messages from PC to Reader
@@ -312,7 +315,9 @@ struct USBCCIDState {
uint8_t bmSlotICCState;
uint8_t powered;
uint8_t notify_slot_change;
+/* properties */
uint8_t debug;
+bool multi;
};
/*
@@ -411,6 +416,34 @@ static const uint8_t qemu_ccid_descriptor[] = {
0x01, /* u8 bMaxCCIDBusySlots; */
};
+static const uint8_t qemu_ccid_descriptor_multi[] = {
+/* Smart Card Device Class Descriptor */
+0x36, /* u8 bLength; */
+0x21, /* u8 bDescriptorType; Functional */
+0x10, 0x01, /* u16 bcdCCID; CCID Specification Release Number.
*/
+0x0e, /* u8 bMaxSlotIndex; 14, as 16 slots can cause
trouble. */
+0x07, /* u8 bVoltageSupport; 01h - 5.0v, 02h - 3.0, 03
- 1.8 */
+
+0x01, 0x00, /* u32 dwProtocols; . = h.*/
+0x00, 0x00, /* : see above */
+0xa0, 0x0f, 0x00, 0x00, /* u32 dwMaximumClock; */
+0x00, 0x00, 0x01, 0x00,
+0x00, /* u8 bNumClockSupported; see above */
+0x80, 0x25, 0x00, 0x00, /* u32 dwMaxDataRate ; see above */
+0x00, 0xC2, 0x01, 0x00,
+0x00, /* u8 bNumDataRatesSupported; see above */
+0xfe, 0x00, 0x00, 0x00, /* u32 dwMaxIFSD; see above */
+0x00, 0x00, 0x00, 0x00, /* u32 dwSyncProtocols; see above */
+0x00, 0x00, 0x00, 0x00, /* u32 dwMechanical; see above */
+0xfe, 0x04, 0x04, 0x00, /* u32 dwFeatures; 400 for better
compat. */
+0x12, 0x00, 0x01, 0x00, /* u32 dwMaxCCIDMessageLength; see
above */
+0xFF, /* u8 bClassGetResponse; see above */
+0xFF, /* u8 bClassEnvelope; see above */
+0x00, 0x00, /* u16 wLcdLayout; see above */
+0x01, /* u8 bPINSupport; see above */
+0x0f, /* u8 bMaxCCIDBusySlots; modified from 1 */
+};
+
enum {
STR_MANUFACTURER = 1,
STR_PRODUCT,
@@ -457,6 +490,38 @@ static const USBDescIface desc_iface0 = {
}
};
+static const USBDescIface desc_iface0_multi = {
+.bInterfaceNumber = 0,
+.bNumEndpoints = 3,
+.bInterfaceClass = USB_CLASS_CSCID,
+.bInterfaceSubClass= USB_SUBCLASS_UNDEFINED,
+.bInterfaceProtocol= 0x00,
+.iInterface= STR_INTERFACE,
+.ndesc = 1,
+.descs = (USBDescOther[]) {
+{
+/* smartcard descriptor */
+.data = qemu_ccid_descriptor_multi,
+},
+},
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress = USB_DIR_IN | CCID_INT_IN_EP,
+.bmAttributes = USB_ENDPOINT_XFER_INT,
+.bInterval = 255,
+.wMaxPacketSize= 64,
+},{
+.bEndpointAddress = USB_DIR_IN | CCID_BULK_IN_EP,
+.bmAttributes = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 64,
+},{
+.bEndpointAddress = USB_DIR_OUT | CCID_BULK_OUT_EP,
+.bmAttributes = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 64,
+},
+}
+};
+
static const USBDescDevice desc_device = {
.bcdUSB= 0x0110,
.bMaxPacketSize0 = 64,
@@ -474,6 +539,23 @@ static const USBDescDevice desc_device = {
},
};
+static const USBDescDevice desc_device_multi = {
+.bcdUSB= 0x0110,
+.bMaxPacketSize0 = 64,
+.bNumConfigurations= 1,
+.confs = (USBDescConfig[]) {
+{
+.bNumInterfaces= 1,
+.bConfigurationValue = 1,
+.bmAttributes = USB_CFG_ATT_ONE |
USB_CFG_ATT_SELFPOWER |
+ USB_CFG_ATT_WAKEUP,
+.bMaxPower = 50,
+.nif = 1,
+
