Re: [Qemu-devel] [PATCH 00/11] isa: preliminary work for multiple buses
Ping #2. Hervé Poussineau a écrit : Ping. Hervé Poussineau a écrit : Current patches are a rework of my patches already available at [1]. They don't provide full support for multiple ISA buses (yet), but add a ISABus or ISADevice argument to all ISA functions. They are mostly mechanically touching every instanciation of ISA devices, so number of lines is quite high even if impact is quite low. Some patches don't pass checkpass check due to spaces around parentheses, but malc asked to do so on files he maintains. Some more patches will be provided after Qemu 1.0 to support multiple ISA buses, but will mostly touch ISA bridges and hw/isa-bus.c file. I think that this first step can be applied now (before release), so ISA interface may be considered stable for devices and machine emulations. Please consider applying this before Qemu 1.0. Thanks [1] http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg00094.html Hervé Poussineau (11): isa: give ISABus/ISADevice to isa_create(), isa_bus_irqs() and isa_get_irq() functions isa: move ISABus structure definition to header file i8259: give ISA device to isa_register_ioport() pc: give ISA bus to ISA methods alpha: give ISA bus to ISA methods sun4u: give ISA bus to ISA methods fulong2e: give ISA bus to ISA methods malta: give ISA bus to ISA methods isa: always use provided ISA bus when creating an isa device isa: always use provided ISA bus in isa_bus_irqs() audio: remove unused parameter isa_pic arch_init.c| 10 +- arch_init.h|2 +- hw/adlib.c |2 +- hw/alpha_dp264.c | 12 +++- hw/alpha_sys.h |3 ++- hw/alpha_typhoon.c |9 + hw/audiodev.h |8 hw/cs4231a.c |4 ++-- hw/fdc.h |4 ++-- hw/gus.c |4 ++-- hw/i8254.c |2 +- hw/i8259.c | 10 +- hw/ide.h |2 +- hw/ide/isa.c |4 ++-- hw/ide/piix.c |2 +- hw/ide/via.c |2 +- hw/isa-bus.c | 33 - hw/isa.h | 16 +++- hw/m48t59.c|5 +++-- hw/mc146818rtc.c |4 ++-- hw/mc146818rtc.h |2 +- hw/mips_fulong2e.c | 20 ++-- hw/mips_jazz.c | 13 +++-- hw/mips_malta.c| 27 ++- hw/mips_r4k.c | 21 +++-- hw/nvram.h |3 ++- hw/pc.c| 30 +++--- hw/pc.h| 39 --- hw/pc_piix.c | 20 +++- hw/pcspk.c |2 +- hw/piix4.c |3 ++- hw/piix_pci.c |8 +--- hw/ppc_prep.c | 20 +++- hw/sb16.c |4 ++-- hw/sun4u.c | 24 +++- hw/vt82c686.c |4 ++-- hw/vt82c686.h |2 +- qemu-common.h |1 + 38 files changed, 205 insertions(+), 176 deletions(-)
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
On 11/04/2011 09:28 PM, Thomas Schmitt wrote: After i disabled SET STREAMING, i was able to write a thoroughly formatted DVD+RW. But when i inserted one that was never written up to its end, the attempt failed to (re-)start background formatting (Format Type = 26h): FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 01 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) I cannot spot an occurence of this sense code in the qemu sources. There are B 00 06 , B 29 07 , B 3E 01. Can you retry this running qemu as root or with CAP_SYS_RAWIO? Paolo
Re: [Qemu-devel] [PATCH 05/14] eepro100: Use PCI DMA stub functions
On Wed, Nov 02, 2011 at 09:16:34AM +0200, Michael S. Tsirkin wrote: On Mon, Oct 31, 2011 at 05:06:49PM +1100, David Gibson wrote: From: Eduard - Gabriel Munteanu [snip] @@ -744,21 +713,26 @@ static void dump_statistics(EEPRO100State * s) * values which really matter. * Number of data should check configuration!!! */ - cpu_physical_memory_write(s->statsaddr, &s->statistics, s->stats_size); - e100_stl_le_phys(s->statsaddr + 0, s->statistics.tx_good_frames); - e100_stl_le_phys(s->statsaddr + 36, s->statistics.rx_good_frames); - e100_stl_le_phys(s->statsaddr + 48, s->statistics.rx_resource_errors); - e100_stl_le_phys(s->statsaddr + 60, s->statistics.rx_short_frame_errors); + pci_dma_write(&s->dev, s->statsaddr, + (uint8_t *) &s->statistics, s->stats_size); + stl_le_pci_dma(&s->dev, s->statsaddr + 0, + s->statistics.tx_good_frames); + stl_le_pci_dma(&s->dev, s->statsaddr + 36, + s->statistics.rx_good_frames); + stl_le_pci_dma(&s->dev, s->statsaddr + 48, + s->statistics.rx_resource_errors); + stl_le_pci_dma(&s->dev, s->statsaddr + 60, + s->statistics.rx_short_frame_errors); This might introduce a bug: stlXX APIs assume aligned addresses, an address in statsaddr is user-controlled so I'm not sure it's always aligned. Why isn't the patch simply replacing cpu_physical_memory_read with pci_XXX ? Any cleanups should be done separately. Hello, I just sent a patch for eepro100.c which enforces aligned addresses for s->statsaddr, so most of David's changes are now safe. Please include the patch in QEMU 1.0. Thanks, Stefan Weil
[Qemu-devel] [PATCH v2] realview: fix reset bit depending on platform
Depending on the considered baseboard the bit used to
reset the platform is different.
Here is the list of considered Realview/Versatile platforms:
Realview/Versatile AB for ARM926EJ-S: BOARD_ID = 0x100 = BOARD_ID_PB926
http://infocenter.arm.com/help/topic/com.arm.doc.dui0225d/CACCIFGI.html
RealView Emulation Baseboard: BOARD_ID = 0x140 = BOARD_ID_EB
No reset register
RealView PB for ARM1176JZF-S: BOARD_ID = 0x147 = BOARD_ID_PB1176
http://infocenter.arm.com/help/topic/com.arm.doc.dui0425f/Caccifgi.html
RealView PB for ARM11 MPCore: BOARD_ID = 0x159 = BOARD_ID_PB11MP
http://infocenter.arm.com/help/topic/com.arm.doc.dui0351e/CACCHBFB.html
RealView PB for Cortex-A8: BOARD_ID = 0x178 = BOARD_ID_PBA8
http://infocenter.arm.com/help/topic/com.arm.doc.dui0417d/BBACIGAD.html
RealView PB for Cortex-A9: BOARD_ID = 0x182 = BOARD_ID_PBX
http://infocenter.arm.com/help/topic/com.arm.doc.dui0440b/CACCHBFB.html
Motherboard Express µATX: BOARD_ID = 0x190 = BOARD_ID_VEXPRESS
No reset register
v2:
- Add multiple boards support
- fix coding style
- Added a BOARD_ID descriptor for unsupported baseboards.
Signed-off-by: Jean-Christophe DUBOIS
---
hw/arm_sysctl.c | 43 ---
1 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/hw/arm_sysctl.c b/hw/arm_sysctl.c
index 17cf6f7..8f07fd5 100644
--- a/hw/arm_sysctl.c
+++ b/hw/arm_sysctl.c
@@ -63,6 +63,8 @@ static const VMStateDescription vmstate_arm_sysctl = {
*/
#define BOARD_ID_PB926 0x100
#define BOARD_ID_EB 0x140
+#define BOARD_ID_PB1176 0x147
+#define BOARD_ID_PB11MP 0x159
#define BOARD_ID_PBA8 0x178
#define BOARD_ID_PBX 0x182
#define BOARD_ID_VEXPRESS 0x190
@@ -143,7 +145,8 @@ static uint64_t arm_sysctl_read(void *opaque,
target_phys_addr_t offset,
case 0x58: /* BOOTCS */
return 0;
case 0x5c: /* 24MHz */
-return muldiv64(qemu_get_clock_ns(vm_clock), 2400,
get_ticks_per_sec());
+return muldiv64(qemu_get_clock_ns(vm_clock), 2400,
+get_ticks_per_sec());
case 0x60: /* MISC */
return 0;
case 0x84: /* PROCID0 */
@@ -184,7 +187,7 @@ static uint64_t arm_sysctl_read(void *opaque,
target_phys_addr_t offset,
return s->sys_cfgstat;
default:
bad_reg:
-printf ("arm_sysctl_read: Bad register offset 0x%x\n", (int)offset);
+printf("arm_sysctl_read: Bad register offset 0x%x\n", (int)offset);
return 0;
}
}
@@ -205,10 +208,11 @@ static void arm_sysctl_write(void *opaque,
target_phys_addr_t offset,
/* ??? */
break;
case 0x20: /* LOCK */
-if (val == LOCK_VALUE)
+if (val == LOCK_VALUE) {
s->lockval = val;
-else
+} else {
s->lockval = val & 0x7fff;
+}
break;
case 0x28: /* CFGDATA1 */
/* ??? Need to implement this. */
@@ -231,15 +235,32 @@ static void arm_sysctl_write(void *opaque,
target_phys_addr_t offset,
s->nvflags &= ~val;
break;
case 0x40: /* RESETCTL */
-if (board_id(s) == BOARD_ID_VEXPRESS) {
+switch (board_id(s)) {
+case BOARD_ID_PB926:
+case BOARD_ID_PB1176:
+if (s->lockval == LOCK_VALUE) {
+s->resetlevel = val;
+if (val & 0x100) {
+qemu_system_reset_request();
+}
+}
+break;
+case BOARD_ID_PBX:
+case BOARD_ID_PBA8:
+case BOARD_ID_PB11MP:
+if (s->lockval == LOCK_VALUE) {
+s->resetlevel = val;
+if (val & 0x04) {
+qemu_system_reset_request();
+}
+}
+break;
+case BOARD_ID_VEXPRESS:
+case BOARD_ID_EB:
+default:
/* reserved: RAZ/WI */
break;
}
-if (s->lockval == LOCK_VALUE) {
-s->resetlevel = val;
-if (val & 0x100)
-qemu_system_reset_request ();
-}
break;
case 0x44: /* PCICTL */
/* nothing to do. */
@@ -324,7 +345,7 @@ static void arm_sysctl_write(void *opaque,
target_phys_addr_t offset,
return;
default:
bad_reg:
-printf ("arm_sysctl_write: Bad register offset 0x%x\n", (int)offset);
+printf("arm_sysctl_write: Bad register offset 0x%x\n", (int)offset);
return;
}
}
--
1.7.5.4
[Qemu-devel] [PATCH v2] arm: Fix CP15 FSR (C5) domain setting
During Xvisor development, it was noted that qemu did not return
the correct domain value in the Cp15 [Data] FSR register (C5).
This patch is a proposal to fix it.
v2:
- fix coding style
- rebase on git.
Signed-off-by: Jean-Christophe DUBOIS
---
target-arm/helper.c | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 97af4d0..8133087 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -951,13 +951,14 @@ void do_interrupt(CPUARMState *env)
/* Check section/page access permissions.
Returns the page protection flags, or zero if the access is not
permitted. */
-static inline int check_ap(CPUState *env, int ap, int domain, int access_type,
- int is_user)
+static inline int check_ap(CPUState *env, int ap, int domain_prot,
+ int access_type, int is_user)
{
int prot_ro;
- if (domain == 3)
+ if (domain_prot == 3) {
return PAGE_READ | PAGE_WRITE;
+ }
if (access_type == 1)
prot_ro = 0;
@@ -1023,6 +1024,7 @@ static int get_phys_addr_v5(CPUState *env, uint32_t
address, int access_type,
int type;
int ap;
int domain;
+int domain_prot;
uint32_t phys_addr;
/* Pagetable walk. */
@@ -1030,13 +1032,14 @@ static int get_phys_addr_v5(CPUState *env, uint32_t
address, int access_type,
table = get_level1_table_address(env, address);
desc = ldl_phys(table);
type = (desc & 3);
-domain = (env->cp15.c3 >> ((desc >> 4) & 0x1e)) & 3;
+domain = (desc >> 5) & 0x0f;
+domain_prot = (env->cp15.c3 >> (domain * 2)) & 3;
if (type == 0) {
/* Section translation fault. */
code = 5;
goto do_fault;
}
-if (domain == 0 || domain == 2) {
+if (domain_prot == 0 || domain_prot == 2) {
if (type == 2)
code = 9; /* Section domain fault. */
else
@@ -1094,7 +1097,7 @@ static int get_phys_addr_v5(CPUState *env, uint32_t
address, int access_type,
}
code = 15;
}
-*prot = check_ap(env, ap, domain, access_type, is_user);
+*prot = check_ap(env, ap, domain_prot, access_type, is_user);
if (!*prot) {
/* Access permission fault. */
goto do_fault;
@@ -1117,6 +1120,7 @@ static int get_phys_addr_v6(CPUState *env, uint32_t
address, int access_type,
int type;
int ap;
int domain;
+int domain_prot;
uint32_t phys_addr;
/* Pagetable walk. */
@@ -1134,10 +1138,10 @@ static int get_phys_addr_v6(CPUState *env, uint32_t
address, int access_type,
domain = 0;
} else {
/* Section or page. */
-domain = (desc >> 4) & 0x1e;
+domain = (desc >> 5) & 0x0f;
}
-domain = (env->cp15.c3 >> domain) & 3;
-if (domain == 0 || domain == 2) {
+domain_prot = (env->cp15.c3 >> (domain * 2)) & 3;
+if (domain_prot == 0 || domain_prot == 2) {
if (type == 2)
code = 9; /* Section domain fault. */
else
@@ -1182,7 +1186,7 @@ static int get_phys_addr_v6(CPUState *env, uint32_t
address, int access_type,
}
code = 15;
}
-if (domain == 3) {
+if (domain_prot == 3) {
*prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
} else {
if (xn && access_type == 2)
@@ -1194,7 +1198,7 @@ static int get_phys_addr_v6(CPUState *env, uint32_t
address, int access_type,
code = (code == 15) ? 6 : 3;
goto do_fault;
}
-*prot = check_ap(env, ap, domain, access_type, is_user);
+*prot = check_ap(env, ap, domain_prot, access_type, is_user);
if (!*prot) {
/* Access permission fault. */
goto do_fault;
--
1.7.5.4
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, Paolo Bonzini wrote: > Can you retry this running qemu as root or with CAP_SYS_RAWIO? No improvement to see. On a new DVD+RW i do $ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include -- and still get FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 484 ms) The same with an attempt to reformat an already formatted DVD+RW. $ xorriso -scsi_log on -dev /dev/sr1 -format full The same with a write run attempt onto a partially formatted DVD+RW. The FORMAT UNIT command is slightly different: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 01 xorriso : UPDATE : Formatting. Working since 2 seconds +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 516 ms) The same with the attempt to format a sequential DVD-RW (details will be part of my next report installment about DVD-RW and DVD-R). qemu start command was: .../x86_64-softmmu/qemu-system-x86_64 \ -L .../pc-bios \ -enable-kvm \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg2,if=scsi \ -cdrom /dvdbuffer/pseudo_drive - A passthrough device based on /dev/sr would increase superuser safety. Running as superuser appears to be quite dangerous in conjunction with Linux happiness to permutate /dev/sg numbers at boot time. I first started it with the /dev/sg of the hard disk by mistake. qemu was stuck at 100% CPU, and the host system did not react on shutdown -h. Had to press the hardware reset button. To my luck, it still booted afterwards. I now let cdrskin check the /dev/sg file before starting qemu. So hopefully this will not happen again. Nevertheless i would prefer to run qemu as normal user. - Have a nice day :) Thomas
[Qemu-devel] SeaBIOS - Network Problem - LSI53C895A Interrupt problem
Hello, I'm having the following problem with Knoppix 6.2 since commit a65f417c8430ce6781cbbfe84381a97d60628d81 of seabios: Linux Call trace and AMD pcnet network interface doesn't work. Looks like that interrupt is disabled. 21.016946] irq 11: nobody cared (try booting with the "irqpoll" option) [ 21.016951] Pid: 2563, comm: NetworkManager Not tainted 2.6.31.6 #4 [ 21.016953] Call Trace: [ 21.016978] [] __report_bad_irq+0x2e/0x6f [ 21.016981] [] note_interrupt+0xed/0x14b [ 21.016985] [] handle_fasteoi_irq+0x8a/0xae [ 21.016989] [] handle_irq+0x1a/0x1f [ 21.016991] [] do_IRQ+0x40/0x96 [ 21.016993] [] common_interrupt+0x29/0x30 [ 21.016998] [] ? __do_softirq+0x47/0xe5 [ 21.017000] [] do_softirq+0x26/0x2b [ 21.017002] [] irq_exit+0x29/0x67 [ 21.017004] [] do_IRQ+0x80/0x96 [ 21.017006] [] common_interrupt+0x29/0x30 [ 21.017016] [] ? _spin_unlock_irqrestore+0x7/0x26 [ 21.017024] [] pcnet32_open+0x4c6/0x50b [pcnet32] [ 21.017029] [] ? notifier_call_chain+0x2b/0x4a [ 21.017036] [] dev_open+0x93/0xd3 [ 21.017038] [] dev_change_flags+0xa4/0x157 [ 21.017041] [] ? rtnl_setlink+0x0/0xe2 [ 21.017043] [] do_setlink+0x26b/0x323 [ 21.017045] [] ? nlmsg_parse+0x37/0x45 [ 21.017047] [] ? rtnl_setlink+0x0/0xe2 [ 21.017049] [] rtnl_setlink+0xdc/0xe2 [ 21.017052] [] rtnetlink_rcv_msg+0x18d/0x1a7 [ 21.017054] [] ? rtnetlink_rcv_msg+0x0/0x1a7 [ 21.017058] [] netlink_rcv_skb+0x30/0x78 [ 21.017060] [] rtnetlink_rcv+0x1c/0x24 [ 21.017062] [] netlink_unicast+0xc6/0x11c [ 21.017064] [] netlink_sendmsg+0x22e/0x23b [ 21.017070] [] sock_sendmsg+0xca/0xe1 [ 21.017074] [] ? autoremove_wake_function+0x0/0x33 [ 21.017077] [] ? autoremove_wake_function+0x0/0x33 [ 21.017079] [] ? verify_iovec+0x40/0x70 [ 21.017082] [] sys_sendmsg+0x13f/0x192 [ 21.017084] [] ? sys_sendto+0xa1/0xc0 [ 21.017086] [] ? _spin_unlock+0x19/0x24 [ 21.017096] [] ? fsnotify_clear_marks_by_inode+0x74/0xa9 [ 21.017099] [] ? sock_destroy_inode+0x10/0x12 [ 21.017103] [] ? generic_drop_inode+0x189/0x18d [ 21.017106] [] sys_socketcall+0x153/0x183 [ 21.017108] [] ? sys_time+0x10/0x39 [ 21.017110] [] syscall_call+0x7/0xb [ 21.017111] handlers: [ 21.017112] [] (sym53c8xx_intr+0x0/0x5f [sym53c8xx]) [ 21.017119] Disabling IRQ #11 I bisect it down to the following commit: a65f417c8430ce6781cbbfe84381a97d60628d81 is the first bad commit commit a65f417c8430ce6781cbbfe84381a97d60628d81 Author: Kevin O'Connor Date: Sun Sep 25 23:08:58 2011 -0400 Consolidate DSDT copy-and-paste PCI IRQ code into method calls. Use method calls in LNK[ABCDS] object methods - this reduces the cut-and-paste code. It also makes it simpler and the object size smaller. Signed-off-by: Kevin O'Connor Any ideas what the problem might be and how to fix it? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i completed my tests on DVD-RW (next will be DVD+R). Sequential DVD-RW can be written with write type Incremental (aka Packet) and be blanked. The write run commands of this DVD-RW profile 0x14 are the same as the ones for profile 0x11 DVD-R. So i boldly declare write success for both. Thoroughly formatted DVD-RW (profile 0x13) can be written. This state is achieved by formatting and writing data to all blocks (only possible on the host system for now). But i have failures with: - Write type DAO in sequential blank DVD-RW - Formatting sequential DVD-RW to overwritable profile 0x13 - Expanding of formatted area of a partially formatted DVD-RW - Inquiring blanking progress by REQUEST SENSE DVD-RW write type DAO makes the guest go stuck. qemu is on 100 % CPU after: MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 42 05 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 ms READ TRACK INFORMATION 52 01 00 00 00 01 00 00 14 00 From drive: 20b 00 26 01 01 00 04 41 01 00 00 00 00 00 00 00 00 00 23 12 80 4 ms START/STOP UNIT 1b 01 00 00 01 00 1808 ms TEST UNIT READY 00 00 00 00 00 00 0 ms START/STOP UNIT 1b 00 00 00 01 00 qemu can be killed (no -9 necessary). The drive is accessible by the host system afterwards. qemu can be restarted and the drive can be used, without the need for rebooting the host. So it is not as bad as with CD SAO. The next command after the stuck START/STOP UNIT would have been RESERVE TRACK. I suspect that it happened although i did not see its log message, because the medium is in unhealthy state afterwards. It pretends to be blank with only 195 MB free and refuses on RESERVE TRACK. 195 MiB is about the expected size of the failed session. Writing to the medium in this state on the host system made the drive mad. The drive did not get ready after all data were written. After about 3 minutes it began to make lots of noise. Only reboot did help. After reboot it was possible to blank the medium, and to write a DAO session on the host system. The attempt to format a DVD-RW to profile 0x13 "Restricted Overwrite" fails: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 00 23 10 20 00 00 08 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) Formatted DVD-RW behave like DVD+RW, except their hard alignment constraints to full 32 kiB ECC blocks (this is the "restriction"). They usually have a longer life than sequential DVD-RW. This FORMAT UNIT command can be performed without special preparations. DVD-RW with profile 0x13 are fully formatted only after they were entirely overwritten with data. In this case, formatting has to be restarted before writing further data onto medium. As the other FORMAT UNIT commands, it fails: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 00 20 71 e0 4c 00 00 10 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 544 ms) REQUEST SENSE does not behave as prescribed for blanking DVD-RW by BLANK a1 10 00 00 00 00 00 00 00 00 00 00 MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with Immed bit set to one: "In response to the REQUEST SENSE command, unless an error has occurred, the Drive shall return a SK/ASC/ASCQ values set to NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS, with the sense key specific bytes set for progress indication." But libburn gets on qemu TEST UNIT READY 00 00 00 00 00 00 +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B +++ key=2 asc=04h ascq=08h ( 0 ms) REQUEST SENSE 03 00 00 00 12 00 From drive: 18b f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 0 ms It is ok that TEST UNIT READY reports the sense data with 2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS But it is not ok that REQUEST SENSE does not do the same. On qemu it reports: 0 00 00 NO ADDITIONAL SENSE INFORMATION This causes libburn's progress meter to show no progress, although i can see the two last bytes of the sense data counting upwards. (0= 0 % done , 65335 = 100 % done) On the host system, i see: TEST UNIT READY 00 00 00 00 00 00 +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 00 00 +++ key=2 asc=04h ascq=08h ( 4 ms) REQUEST SENSE 03 00 00 00 12 00 From drive: 18b 70 00 02 00 00 00 00 0a 00 00 00 00 04 08 00 80 00 00 0 ms ... REQUEST SENSE 03 00 00 00 12 00 F
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
On 11/05/2011 03:37 PM, Thomas Schmitt wrote: MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with Immed bit set to one: "In response to the REQUEST SENSE command, unless an error has occurred, the Drive shall return a SK/ASC/ASCQ values set to NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS, with the sense key specific bytes set for progress indication." But libburn gets on qemu TEST UNIT READY 00 00 00 00 00 00 +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B +++ key=2 asc=04h ascq=08h ( 0 ms) REQUEST SENSE 03 00 00 00 12 00 From drive: 18b f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 0 ms It is ok that TEST UNIT READY reports the sense data with 2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS But it is not ok that REQUEST SENSE does not do the same. On qemu it reports: 0 00 00 NO ADDITIONAL SENSE INFORMATION This is because QEMU always emulates REQUEST SENSE and always returns the sense data from the last request. Is this git master or 0.15? For git master, I would have expected REQUEST SENSE to return the correct sense data, but without updating it. In general, it seems safer (and simpler?) if libburn uses TEST UNIT READY and its autosense data to report progress. REQUEST SENSE would be used if SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but modern OSes will always emulate autosense even if the HBA does not support it) and possibly if TEST UNIT READY returns GOOD which is allowed by deprecated in MMC. Paolo
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, > > [REQUEST SENSE while blanking] > > MMC-3 5.2 and MMC-5 6.2.3 > Is this git master or 0.15? It is a git clone obtained on November 2 by git clone git://git.qemu.org/qemu.git I see a file VERSION with date Nov 2 13:41 (+0100) $ cat VERSION 0.15.90 $ git describe fatal: No annotated tags can describe 'e072ea2fd8fdceef64159b9596d3c15ce01bea91'. However, there were unannotated tags: try --tags. $ git describe --tags v1.0-rc0 Should i run git pull git://git.qemu.org/qemu.git ? (My clone is still slightly altered. Will this be a problem ?) > This is because QEMU always emulates REQUEST SENSE and always returns the > sense data from the last request. Is this realistic enough for passthrough ? Shouldn't qemu forward all SCSI commands to the host operating system in this case ? > REQUEST SENSE would be used if > SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but modern OSes > will always emulate autosense even if the HBA does not support it) and > possibly if TEST UNIT READY returns GOOD which is allowed by deprecated in > MMC. Up to now it appeared better to use the explicitely prescribed method with REQUEST SENSE. It is not a showstopper anyway. Just a little beauty flaw. There are also some drives which do not report proper progress. I have this topic on my todo list, together with a more graceful handling if SET STREAMING fails. Currently i am at the item - Test all libburn write models of CD, DVD, and BD. Write a summary of all results. I plan to check DVD+R tonight. BD-R and BD-RE tomorrow. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, now for DVD+R burning. It works well if i avoid command RESERVE TRACK. RESERVE TRACK shows similar effects as the failed DVD-RW DAO run, resp. the failed CD SAO run: qemu gets stuck at 100 % CPU. No failed ioctl is indicated by my printfs. Details: As with all DVD types, READ DISC STRUCTURE formats 0x04 and 0x11 block until timeout. I disable them for these tests. Blank DVD+R $ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include -- makes the guest system block 11 seconds after RESERVE TRACK 53 00 00 00 00 00 00 0f 30 00 CPU 100 % , no life in SSH sessions. After killing qemu, the drive is usable from the host system. A track is reserved, no data were written. I could write another track to it, by avoiding RESERVE TRACK. But now libburn is lost in the woods. It wanted to close the session, but the first empty track causes this to fail. I will later have to try to write and close the first track. For now the medium is spoiled. New DVD+R. This time no RESERVE TRACK. For that i have to avoid that xorriso learns the size of the session in advance. Thus the cdrtools usage model: $ xorriso -as mkisofs -graft-points /usr/include=/usr/include \ --for_backup \ | xorriso -as cdrecord dev=/dev/sr1 -v -V -waiti -multi - This yields a readable track. I get a credible table-of-content. MD5 sums of files match correctly. Another session can be added cdrtools style. All is well. Table-of-content is readable, MD5 sums match. I add a third session, and order the medium to be closed, by omitting cdrecord option -multi. Works well. Passes all read checks. --- Since BD-R are very similar to DVD+R, but much more expensive, i will tomorrow only test the case without RESERVE TRACK. Have a nice day :) Thomas
Re: [Qemu-devel] [PATCH v7 0/2] PC system flash support
Cc: qemu-devel On Fri, Nov 4, 2011 at 22:37, Zhi Yong Wu wrote: > On Sat, Nov 5, 2011 at 12:11 AM, Jordan Justen wrote: >> On Fri, Nov 4, 2011 at 04:34, Zhi Yong Wu wrote: >>> BTW: what is the relationship between -bios and -pflash? >> >> Previously the QEMU/KVM PC system had no pflash support. You could >> specify a pflash drive, but it would not appear in the VM. >> >> Also, previously the -bios flag would cause the specified binary to be >> loaded by QEMU, and then it was put into a memory region to be used >> for the firmware. >> >> After this change, the pflash drive is used for firmware. So, it > This pflash drive is created with -pflash option, right? -pflash can be used, but I think it is just a short cut. -pflash /path/to/file is similar to: -drive if=pflash,file=/path/to/file And, after this change, -bios /path/to/file is similar to: -drive if=pflash,file=/path/to/file,readonly=on >> should be able to support qcow2, since qemu drives support the >> different formats. I confirmed that you can use a qcow2 image with -bios after this change. >> For backward compatibility, this change makes the -bios parameter be >> another way to specify the pflash drive. If -bios is used, then a >> read-only pflash drive is created. > Sorry, i don't fully understand this. How about -bios and -pflash are > both specified. In this case the -pflash will be used, and -bios will be ignored. I use -bios to create a pflash drive only if no pflash drive exists already. I think this should be okay, since -pflash has no use in the QEMU PC system before this patch, so it is unlikely that both -pflash and -bios will be used previously. >>> If your patch is applied to my source tree, can you know how to use -pflash? > Sorry, i made a mistake. I wanted to ask you how to use -pflash if > your patch is not applied. I don't think you can use pflash in a PC system when my patch is not applied. I think without the patch qemu will create the pflash drive internally, but it will not be hooked to a device that the emulated PC system can see. I attached a log of me interacting with the pflash device under the EFI shell on OVMF *with* the patch applied. Thanks, -Jordan Notes below refer to quoted item just above. > Device mapping table > blk0 :Floppy - Alias (null) > PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0) > blk1 :Floppy - Alias (null) > PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1) > blk2 :BlockDevice - Alias (null) > PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0) > > > Press ESC in 5 seconds to skip startup.nsh, any other key to continue. > Press ESC in 4 seconds to skip startup.nsh, any other key to continue. EFI shell started > Shell> mem fffe0 32 > Memory Address 000FFFE0 20 Bytes > 000FFFE0: EB C3 90 90 90 90 90 90-00 00 00 00 56 54 46 00 > *VTF.* > 0000: 90 90 EB AC 90 90 90 90-90 90 90 90 90 90 90 90 > ** Dump firmware range in legacy F000 segment > Shell> mem ffe0 32 > Memory Address FFE0 20 Bytes > FFE0: EB C3 90 90 90 90 90 90-00 00 00 00 56 54 46 00 > *VTF.* > FFF0: 90 90 EB AC 90 90 90 90-90 90 90 90 90 90 90 90 > ** Dump firmware range at top of 4GB. > Shell> mem fff0 32 > Memory Address FFF0 20 Bytes > FFF0: 01 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > ** > FFF00010: 78 E5 8C 8C 3D 8A 1C 4F-99 35 89 61 85 C3 2D D3 > *x...=..O.5.a..-.* Dump start of OVMF flash image. The first 16 bytes are reserved, and therefore we can program them without a negative side effect. Notice I have previously programmed the first byte from 00 to 01. > Shell> mm -mmio -w 1 -n fff0 > MMIO 0xFFF0 : 0x01 Read the data in the first byte of the rom. > Shell> mm -mmio -w 1 -n fff0 70 Request to read the pflash_cfi01 status register. (0x70 is the command written to address 0xfff0.) > Shell> mm -mmio -w 1 -n fff0 > MMIO 0xFFF0 : 0x00 Read the status register by reading address 0xfff0. > Shell> mm -mmio -w 1 -n fff0 ff Put the pflash_cfi01 back into read-data mode. (0xff is the command for putting the flash into read mode.) > Shell> mm -mmio -w 1 -n fff0 > MMIO 0xFFF0 : 0x01 Notice we read the proper data again... 0x01. > Shell> mm -mmio -w 1 -n fff1 > MMIO 0xFFF1 : 0x00 Now read the data at 0xfff1. It is 0x00. > Shell> mm -mmio -w 1 -n fff1 10 Put the pflash_cfi01 into programming mode. > Shell> mm -mmio -w 1 -n fff1 ab Program the data at 0xfff1. Data is 0xab. > Shell> mm -mmio -w 1 -n fff1 ff Put the pflash_cfi01 back into read-data mode. > Shell> mm -mmio -w 1 -n fff1 > MMIO 0xFFF1 : 0xAB 0xab was programmed into 0xfff1. > Shell> mm -mmio -w 1 -n fff1 70 Request to read the status register. > Shell> mm -mmio -w 1 -n fff1 > MMIO 0xFFF1 : 0x80 bit7 (0x80) indicates de
Re: [Qemu-devel] [Bug 885213] Re: Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
On Fri, Nov 4, 2011 at 10:22, Stefan Weil <885...@bugs.launchpad.net> wrote:
> Did you try compilation in a tree with old generated files from previous
> compilations? If there are several qmp-commands.h in subdirectories,
> you have such old files. There must be only one qmp-commands.h
> in the build root.
>
> The old files start with "{", the new files start with comment lines.
> The compiler error which you got comes from an old file.
>
> Create a new QEMU source tree and try compilation there.
Should 'make clean' take care of this? It didn't help me when I
stumbled upon this. :)
Or, since the old qmp-commands.h files are no longer targets, is this
not possible/desired?
Thanks,
-Jordan
[Qemu-devel] [Bug 885213] Re: Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
'make clean' won't remove the old qmp-commands.h files.
I think it did remove them before commit
e3193601c84558c303b1773379da76fce80c0a56,
so if you always had run 'make clean' before 'git pull', it would have worked.
Removing files which were build with older QEMU versions is not required,
so if you don't mind, I'll close this bug report.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/885213
Title:
Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
Status in QEMU:
New
Bug description:
The latest GIT version (e072ea2fd8fdceef64159b9596d3c15ce01bea91)
fails to compile.
Host: debian x86-64. gcc 4.6.2
...
CCcris-softmmu/pci-stub.o
...
In file included from /home/njh/src/qemu/hw/pci-stub.c:24:0:
./qmp-commands.h: At top level:
./qmp-commands.h:3:1: error: expected identifier or ‘(’ before ‘{’ token
.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/885213/+subscriptions
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels
On 24.08.2011, at 20:44, Américo Wang wrote: > On Thu, Aug 25, 2011 at 4:35 AM, Alexander Graf wrote: >> >> On 24.08.2011, at 00:31, Américo Wang wrote: >> >>> On Wed, Aug 24, 2011 at 1:19 PM, Pekka Enberg wrote: It's nice to see such an honest attempt at improving QEMU usability, Alexander! One comment: in my experience, having shell scripts under Documentation reduces the likelihood that people actually discover them so you might want to consider putting it under scripts or tools. >>> >>> I was going to give the same suggestion, +1 for tools/ directory. >> >> Well, scripts/ is a flat directory where I can just throw in the script. >> Tools however is split by tool and creating a full new directory for only a >> single script sounds a bit like overkill to me. I'll move it to scripts/ for >> now :) > > How about the directory tools/testing/ ? > > scripts/ is mainly for the tools/utilities we use to build kernel or > do kernel dev, > it is not so suitable for your script IMHO. Good idea! I talked to Steven about it as well and completely forgot your email pointing me to the same directory. I guess that one does fit it pretty well. Alex
[Qemu-devel] zaurus machine test kernel and initrd
Hello list, I build a zaurus kernel and a buildroot initrd image for 1.0 testing day. How can I put these images in the download section of the wiki ? Regards Benoît
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 25.08.2011, at 11:01, Blue Swirl wrote:
> On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf wrote:
>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>> would be doing and what he expects from it. Basically he wants a
>> small and simple tool he and other developers can run to try out and
>> see if the kernel they just built actually works.
>>
>> Fortunately, QEMU can do that today already! The only piece that was
>> missing was the "simple" piece of the equation, so here is a script
>> that wraps around QEMU and executes a kernel you just built.
>>
>> If you do have KVM around and are not cross-compiling, it will use
>> KVM. But if you don't, you can still fall back to emulation mode and
>> at least check if your kernel still does what you expect. I only
>> implemented support for s390x and ppc there, but it's easily extensible
>> to more platforms, as QEMU can emulate (and virtualize) pretty much
>> any platform out there.
>>
>> If you don't have qemu installed, please do so before using this script. Your
>> distro should provide a package for it (might even call it "kvm"). If not,
>> just compile it from source - it's not hard!
>>
>> To quickly get going, just execute the following as user:
>>
>>$ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>>
>> This will drop you into a shell on your rootfs.
>>
>> Happy hacking!
>>
>> Signed-off-by: Alexander Graf
>>
>> ---
>>
>> v1 -> v2:
>>
>> - fix naming of QEMU
>> - use grep -q for has_config
>> - support multiple -a args
>> - spawn gdb on execution
>> - pass through qemu options
>> - dont use qemu-system-x86_64 on i386
>> - add funny sentence to startup text
>> - more helpful error messages
>> ---
>> scripts/run-qemu.sh | 334
>> +++
>> 1 files changed, 334 insertions(+), 0 deletions(-)
>> create mode 100755 scripts/run-qemu.sh
>>
>> diff --git a/scripts/run-qemu.sh b/scripts/run-qemu.sh
>> new file mode 100755
>> index 000..5d4e185
>> --- /dev/null
>> +++ b/scripts/run-qemu.sh
>> @@ -0,0 +1,334 @@
>> +#!/bin/bash
>> +#
>> +# QEMU Launcher
>> +#
>> +# This script enables simple use of the KVM and QEMU tool stack for
>> +# easy kernel testing. It allows to pass either a host directory to
>> +# the guest or a disk image. Example usage:
>> +#
>> +# Run the host root fs inside a VM:
>> +#
>> +# $ ./scripts/run-qemu.sh -r /
>> +#
>> +# Run the same with SDL:
>> +#
>> +# $ ./scripts/run-qemu.sh -r / --sdl
>> +#
>> +# Or with a PPC build:
>> +#
>> +# $ ARCH=ppc ./scripts/run-qemu.sh -r /
>> +#
>> +# PPC with a mac99 model by passing options to QEMU:
>> +#
>> +# $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
>> +#
>> +
>> +USE_SDL=
>> +USE_VNC=
>> +USE_GDB=1
>> +KERNEL_BIN=arch/x86/boot/bzImage
>> +MON_STDIO=
>> +KERNEL_APPEND2=
>> +SERIAL=ttyS0
>> +SERIAL_KCONFIG=SERIAL_8250
>> +BASENAME=$(basename "$0")
>> +
>> +function usage() {
>> + echo "
>> +$BASENAME allows you to execute a virtual machine with the Linux kernel
>> +that you just built. To only execute a simple VM, you can just run it
>> +on your root fs with \"-r / -a init=/bin/bash\"
>> +
>> + -a, --append parameters
>> + Append the given parameters to the kernel command line.
>> +
>> + -d, --disk image
>> + Add the image file as disk into the VM.
>> +
>> + -D, --no-gdb
>> + Don't run an xterm with gdb attached to the guest.
>> +
>> + -r, --root directory
>> + Use the specified directory as root directory inside the
>> guest.
>> +
>> + -s, --sdl
>> + Enable SDL graphical output.
>> +
>> + -S, --smp cpus
>> + Set number of virtual CPUs.
>> +
>> + -v, --vnc
>> + Enable VNC graphical output.
>> +
>> +Examples:
>> +
>> + Run the host root fs inside a VM:
>> + $ ./scripts/run-qemu.sh -r /
>> +
>> + Run the same with SDL:
>> + $ ./scripts/run-qemu.sh -r / --sdl
>> +
>> + Or with a PPC build:
>> + $ ARCH=ppc ./scripts/run-qemu.sh -r /
>> +
>> + PPC with a mac99 model by passing options to QEMU:
>> + $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
>> +"
>> +}
>> +
>> +function require_config() {
>> + if [ "$(grep CONFIG_$1=y .config)" ]; then
>> + return
>> + fi
>> +
>> + echo "You need to enable CONFIG_$1 for run-qemu to work properly"
>> + exit 1
>> +}
>> +
>> +function has_config() {
>> + grep -q "CONFIG_$1=y" .config
>> +}
>> +
>> +function drive_if() {
>> + if has_config VIRTIO_BLK; then
>> + echo virtio
>> + elif has_config ATA_PIIX; then
>> + echo ide
>> + else
>> + echo "\
>> +Your kernel must have either VIRTIO_BLK or ATA_PIIX
>> +enabled for block device assignment" >&2
>> + exit 1
>> + fi
>> +}
>> +
>> +GETOPT=`getopt -o a:d:Dhr:sS:v --long
>> append,disk:,no-gdb,help,root:,sdl,s
[Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
would be doing and what he expects from it. Basically he wants a
small and simple tool he and other developers can run to try out and
see if the kernel they just built actually works.
Fortunately, QEMU can do that today already! The only piece that was
missing was the "simple" piece of the equation, so here is a script
that wraps around QEMU and executes a kernel you just built.
If you do have KVM around and are not cross-compiling, it will use
KVM. But if you don't, you can still fall back to emulation mode and
at least check if your kernel still does what you expect. I only
implemented support for s390x and ppc there, but it's easily extensible
to more platforms, as QEMU can emulate (and virtualize) pretty much
any platform out there.
If you don't have qemu installed, please do so before using this script. Your
distro should provide a package for it (might even call it "kvm"). If not,
just compile it from source - it's not hard!
To quickly get going, just execute the following as user:
$ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
This will drop you into a shell on your rootfs.
Happy hacking!
Signed-off-by: Alexander Graf
---
v1 -> v2:
- fix naming of QEMU
- use grep -q for has_config
- support multiple -a args
- spawn gdb on execution
- pass through qemu options
- dont use qemu-system-x86_64 on i386
- add funny sentence to startup text
- more helpful error messages
v2 -> v3:
- move to tools/testing
- fix running: message
( sorry for sending this version so late - I got caught up in
random other stuff )
---
tools/testing/run-qemu/run-qemu.sh | 338
1 files changed, 338 insertions(+), 0 deletions(-)
create mode 100755 tools/testing/run-qemu/run-qemu.sh
diff --git a/tools/testing/run-qemu/run-qemu.sh
b/tools/testing/run-qemu/run-qemu.sh
new file mode 100755
index 000..70f194f
--- /dev/null
+++ b/tools/testing/run-qemu/run-qemu.sh
@@ -0,0 +1,338 @@
+#!/bin/bash
+#
+# QEMU Launcher
+#
+# This script enables simple use of the KVM and QEMU tool stack for
+# easy kernel testing. It allows to pass either a host directory to
+# the guest or a disk image. Example usage:
+#
+# Run the host root fs inside a VM:
+#
+# $ ./scripts/run-qemu.sh -r /
+#
+# Run the same with SDL:
+#
+# $ ./scripts/run-qemu.sh -r / --sdl
+#
+# Or with a PPC build:
+#
+# $ ARCH=ppc ./scripts/run-qemu.sh -r /
+#
+# PPC with a mac99 model by passing options to QEMU:
+#
+# $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
+#
+
+USE_SDL=
+USE_VNC=
+USE_GDB=1
+KERNEL_BIN=arch/x86/boot/bzImage
+MON_STDIO=
+KERNEL_APPEND2=
+SERIAL=ttyS0
+SERIAL_KCONFIG=SERIAL_8250
+BASENAME=$(basename "$0")
+
+function usage() {
+ echo "
+$BASENAME allows you to execute a virtual machine with the Linux kernel
+that you just built. To only execute a simple VM, you can just run it
+on your root fs with \"-r / -a init=/bin/bash\"
+
+ -a, --append parameters
+ Append the given parameters to the kernel command line.
+
+ -d, --disk image
+ Add the image file as disk into the VM.
+
+ -D, --no-gdb
+ Don't run an xterm with gdb attached to the guest.
+
+ -r, --root directory
+ Use the specified directory as root directory inside the guest.
+
+ -s, --sdl
+ Enable SDL graphical output.
+
+ -S, --smp cpus
+ Set number of virtual CPUs.
+
+ -v, --vnc
+ Enable VNC graphical output.
+
+Examples:
+
+ Run the host root fs inside a VM:
+ $ ./scripts/run-qemu.sh -r /
+
+ Run the same with SDL:
+ $ ./scripts/run-qemu.sh -r / --sdl
+
+ Or with a PPC build:
+ $ ARCH=ppc ./scripts/run-qemu.sh -r /
+
+ PPC with a mac99 model by passing options to QEMU:
+ $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
+"
+}
+
+function require_config() {
+ if [ "$(grep CONFIG_$1=y .config)" ]; then
+ return
+ fi
+
+ echo "You need to enable CONFIG_$1 for run-qemu to work properly"
+ exit 1
+}
+
+function has_config() {
+ grep -q "CONFIG_$1=y" .config
+}
+
+function drive_if() {
+ if has_config VIRTIO_BLK; then
+ echo virtio
+ elif has_config ATA_PIIX; then
+ echo ide
+ else
+ echo "\
+Your kernel must have either VIRTIO_BLK or ATA_PIIX
+enabled for block device assignment" >&2
+ exit 1
+ fi
+}
+
+GETOPT=`getopt -o a:d:Dhr:sS:v --long
append,disk:,no-gdb,help,root:,sdl,smp:,vnc \
+ -n "$(basename \"$0\")" -- "$@"`
+
+if [ $? != 0 ]; then
+ echo "Terminating..." >&2
+ exit 1
+fi
+
+eval set -- "$GETOPT"
+
+while true; do
+ case "$1" in
+ -a|--append)
+ KERNEL_APPEND2="$KERNEL_APPEND2 $KERNEL_APPEND2"
+ shift
+ ;;
+ -d|--disk)
+
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Am 06.11.2011 02:35, schrieb Alexander Graf: > On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool > would be doing and what he expects from it. Basically he wants a > small and simple tool he and other developers can run to try out and > see if the kernel they just built actually works. > > Fortunately, QEMU can do that today already! The only piece that was > missing was the "simple" piece of the equation, so here is a script > that wraps around QEMU and executes a kernel you just built. > > If you do have KVM around and are not cross-compiling, it will use > KVM. But if you don't, you can still fall back to emulation mode and > at least check if your kernel still does what you expect. I only > implemented support for s390x and ppc there, but it's easily extensible > to more platforms, as QEMU can emulate (and virtualize) pretty much > any platform out there. > > If you don't have qemu installed, please do so before using this script. Your > distro should provide a package for it (might even call it "kvm"). If not, > just compile it from source - it's not hard! > > To quickly get going, just execute the following as user: > > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash Path needs updating. > > This will drop you into a shell on your rootfs. > > Happy hacking! > > Signed-off-by: Alexander Graf > > --- > diff --git a/tools/testing/run-qemu/run-qemu.sh > b/tools/testing/run-qemu/run-qemu.sh > new file mode 100755 > index 000..70f194f > --- /dev/null > +++ b/tools/testing/run-qemu/run-qemu.sh > +# Try to find the KVM accelerated QEMU binary > + > +[ "$ARCH" ] || ARCH=$(uname -m) > +case $ARCH in > +x86_64) > + KERNEL_BIN=arch/x86/boot/bzImage > + # SUSE and Red Hat call the binary qemu-kvm > + [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null) > + > + # Debian and Gentoo call it kvm > + [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null) > + > + # QEMU's own build system calls it qemu-system-x86_64 > + [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null) > + ;; > +i*86) > + KERNEL_BIN=arch/x86/boot/bzImage > + # SUSE and Red Hat call the binary qemu-kvm > + [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null) > + > + # Debian and Gentoo call it kvm > + [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null) > + > + KERNEL_BIN=arch/x86/boot/bzImage Copy&paste? > + # i386 version of QEMU QEMU's own build system calls it qemu-system-i386 now. :) > + [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null) We should first test for qemu-system-i386, then fall back to old qemu. Andreas P.S. You're still ahead of time... -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v7 0/2] PC system flash support
On Sun, Nov 6, 2011 at 5:30 AM, Jordan Justen wrote: > Cc: qemu-devel > > On Fri, Nov 4, 2011 at 22:37, Zhi Yong Wu wrote: >> On Sat, Nov 5, 2011 at 12:11 AM, Jordan Justen wrote: >>> On Fri, Nov 4, 2011 at 04:34, Zhi Yong Wu wrote: BTW: what is the relationship between -bios and -pflash? >>> >>> Previously the QEMU/KVM PC system had no pflash support. You could >>> specify a pflash drive, but it would not appear in the VM. >>> >>> Also, previously the -bios flag would cause the specified binary to be >>> loaded by QEMU, and then it was put into a memory region to be used >>> for the firmware. >>> >>> After this change, the pflash drive is used for firmware. So, it >> This pflash drive is created with -pflash option, right? > > -pflash can be used, but I think it is just a short cut. > > -pflash /path/to/file > is similar to: > -drive if=pflash,file=/path/to/file > > And, after this change, > -bios /path/to/file > is similar to: > -drive if=pflash,file=/path/to/file,readonly=on > >>> should be able to support qcow2, since qemu drives support the >>> different formats. > > I confirmed that you can use a qcow2 image with -bios after this change. > >>> For backward compatibility, this change makes the -bios parameter be >>> another way to specify the pflash drive. If -bios is used, then a >>> read-only pflash drive is created. >> Sorry, i don't fully understand this. How about -bios and -pflash are >> both specified. > > In this case the -pflash will be used, and -bios will be ignored. I > use -bios to create a pflash drive only if no pflash drive exists > already. > > I think this should be okay, since -pflash has no use in the QEMU PC > system before this patch, so it is unlikely that both -pflash and > -bios will be used previously. > If your patch is applied to my source tree, can you know how to use -pflash? >> Sorry, i made a mistake. I wanted to ask you how to use -pflash if >> your patch is not applied. > > I don't think you can use pflash in a PC system when my patch is not > applied. I think without the patch qemu will create the pflash drive > internally, but it will not be hooked to a device that the emulated PC > system can see. > > I attached a log of me interacting with the pflash device under the > EFI shell on OVMF *with* the patch applied. > Great, thanks a lot. Let me try next week. > Thanks, > > -Jordan > -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4] block:add-cow file format
Do you have any comments?
Thanks.
2011/10/27 Dong Xu Wang :
> Provide a new file format: add-cow. The usage can be found in add-cow.txt of
> this patch.
>
> Signed-off-by: Dong Xu Wang
> ---
> Makefile.objs | 1 +
> block.c | 2 +-
> block.h | 1 +
> block/add-cow.c | 405
>
> block_int.h | 1 +
> docs/specs/add-cow.txt | 45 ++
> 6 files changed, 454 insertions(+), 1 deletions(-)
> create mode 100644 block/add-cow.c
> create mode 100644 docs/specs/add-cow.txt
>
> diff --git a/Makefile.objs b/Makefile.objs
> index 01587c8..208c12c 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -31,6 +31,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
>
> block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o
> vpc.o vvfat.o
> block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
> qcow2-cache.o
> +block-nested-y += add-cow.o
> block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
> block-nested-y += qed-check.o
> block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
> diff --git a/block.c b/block.c
> index 70aab63..e343995 100644
> --- a/block.c
> +++ b/block.c
> @@ -105,7 +105,7 @@ int is_windows_drive(const char *filename)
> #endif
>
> /* check if the path starts with ":" */
> -static int path_has_protocol(const char *path)
> +int path_has_protocol(const char *path)
> {
> #ifdef _WIN32
> if (is_windows_drive(path) ||
> diff --git a/block.h b/block.h
> index 5a042c9..dff5197 100644
> --- a/block.h
> +++ b/block.h
> @@ -271,6 +271,7 @@ char *bdrv_snapshot_dump(char *buf, int buf_size,
> QEMUSnapshotInfo *sn);
>
> char *get_human_readable_size(char *buf, int buf_size, int64_t size);
> int path_is_absolute(const char *path);
> +int path_has_protocol(const char *path);
> void path_combine(char *dest, int dest_size,
> const char *base_path,
> const char *filename);
> diff --git a/block/add-cow.c b/block/add-cow.c
> new file mode 100644
> index 000..93d5b13
> --- /dev/null
> +++ b/block/add-cow.c
> @@ -0,0 +1,405 @@
> +#include "qemu-common.h"
> +#include "block_int.h"
> +#include "module.h"
> +
> +#define ADD_COW_MAGIC (((uint64_t)'A' << 56) | ((uint64_t)'D' << 48) | \
> + ((uint64_t)'D' << 40) | ((uint64_t)'_' << 32) | \
> + ((uint64_t)'C' << 24) | ((uint64_t)'O' << 16) | \
> + ((uint64_t)'W' << 8) | 0xFF)
> +#define ADD_COW_VERSION 1
> +#define ADD_COW_FILE_LEN 1024
> +
> +typedef struct AddCowHeader {
> + uint64_t magic;
> + uint32_t version;
> + char backing_file[ADD_COW_FILE_LEN];
> + char image_file[ADD_COW_FILE_LEN];
> + uint64_t size;
> +} QEMU_PACKED AddCowHeader;
> +
> +typedef struct BDRVAddCowState {
> + char image_file[ADD_COW_FILE_LEN];
> + BlockDriverState *image_hd;
> + uint8_t *bitmap;
> + uint64_t bitmap_size;
> + CoMutex lock;
> +} BDRVAddCowState;
> +
> +static int add_cow_probe(const uint8_t *buf, int buf_size, const char
> *filename)
> +{
> + const AddCowHeader *header = (const void *)buf;
> +
> + if (be64_to_cpu(header->magic) == ADD_COW_MAGIC &&
> + be32_to_cpu(header->version) == ADD_COW_VERSION) {
> + return 100;
> + } else {
> + return 0;
> + }
> +}
> +
> +static int add_cow_open(BlockDriverState *bs, int flags)
> +{
> + AddCowHeader header;
> + int64_t size;
> + char image_filename[ADD_COW_FILE_LEN];
> + int image_flags;
> + BlockDriver *image_drv = NULL;
> + int ret;
> + BDRVAddCowState *state = (BDRVAddCowState *)(bs->opaque);
> +
> + ret = bdrv_pread(bs->file, 0, &header, sizeof(header));
> + if (ret != sizeof(header)) {
> + goto fail;
> + }
> +
> + if (be64_to_cpu(header.magic) != ADD_COW_MAGIC ||
> + be32_to_cpu(header.version) != ADD_COW_VERSION) {
> + ret = -1;
> + goto fail;
> + }
> +
> + size = be64_to_cpu(header.size);
> + bs->total_sectors = size / BDRV_SECTOR_SIZE;
> +
> + QEMU_BUILD_BUG_ON(sizeof(state->image_file) !=
> sizeof(header.image_file));
> + pstrcpy(bs->backing_file, sizeof(bs->backing_file),
> + header.backing_file);
> + pstrcpy(state->image_file, sizeof(state->image_file),
> + header.image_file);
> +
> + state->bitmap_size = ((bs->total_sectors + 7) >> 3);
> + state->bitmap = g_malloc0(state->bitmap_size);
> +
> + ret = bdrv_pread(bs->file, sizeof(header), state->bitmap,
> + state->bitmap_size);
> + if (ret != state->bitmap_size) {
> + goto fail;
> + }
> + /* If there is a image_file, must be together with backing_file */
> + if (state->image_file[0] != '\0') {
> + state->image_hd = bdrv_new("");
> + /* Relative to image or working dir, need discussion */
> + if (path_has_protocol(state->image_file)) {
> +
