[Qemu-devel] [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Hi everyone, Sheepdog is a distributed storage system for KVM/QEMU. It provides highly available block level storage volumes to VMs like Amazon EBS. Sheepdog supports advanced volume management features such as snapshot, cloning, and thin provisioning. Sheepdog runs on several tens or hundreds of nodes, and the architecture is fully symmetric; there is no central node such as a meta-data server. The following list describes the features of Sheepdog. * Linear scalability in performance and capacity * No single point of failure * Redundant architecture (data is written to multiple nodes) - Tolerance against network failure * Zero configuration (newly added machines will join the cluster automatically) - Autonomous load balancing * Snapshot - Online snapshot from qemu-monitor * Clone from a snapshot volume * Thin provisioning - Amazon EBS API support (to use from a Eucalyptus instance) (* = current features, - = on our todo list) More details and download links are here: http://www.osrg.net/sheepdog/ Note that the code is still in an early stage. There are some critical TODO items: - VM image deletion support - Support architectures other than X86_64 - Data recoverys - Free space management - Guarantee reliability and availability under heavy load - Performance improvement - Reclaim unused blocks - More documentation We hope finding people interested in working together. Enjoy! Here are examples: - create images $ kvm-img create -f sheepdog "Alice's Disk" 256G $ kvm-img create -f sheepdog "Bob's Disk" 256G - list images $ shepherd info -t vdi 4 : Alice's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 16:17:18, tag:0, current 8 : Bob's Disk256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 16:29:20, tag:0, current - start up a virtual machine $ kvm --drive format=sheepdog,file="Alice's Disk" - create a snapshot $ kvm-img snapshot -c name sheepdog:"Alice's Disk" - clone from a snapshot $ kvm-img create -b sheepdog:"Alice's Disk":0 -f sheepdog "Charlie's Disk" Thanks. -- MORITA, Kazutaka NTT Cyber Space Labs OSS Computing Project Kernel Group E-mail: morita.kazut...@lab.ntt.co.jp
[Qemu-devel] Re: [PATCH 0/9] S390x KVM support
Alexander Graf wrote:
This is the resulting code. Please comment on things you like and also on the
ones you don't :-).
I've reviewed and tested it, great work Alex :-)
Also to actually run this code you need a patch for an ugly bug in the kernel
module: http://alex.csgraf.de/psw.patch
Well, it was not exactly a bug. Kuli does'nt need the psw to be updated
in kvm_run at all times. Your hotfix updates the psw in a union, even if
the exit reason indicates that s390_sieic is not valid. The patch at the
end of this mail moves the PSW out of the union. I think it makes most
sense if Avi picks this patch and you adopt your series to it. This way
the user interface of the kvm module works for both kuli and qemu.
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
Signed-off-by: Carsten Otte
---
arch/s390/kvm/kvm-s390.c | 14 --
include/linux/kvm.h |8 ++--
2 files changed, 14 insertions(+), 8 deletions(-)
Index: kvm/include/linux/kvm.h
===
--- kvm.orig/include/linux/kvm.h2009-10-20 15:00:40.0 +0200
+++ kvm/include/linux/kvm.h 2009-10-20 16:51:48.0 +0200
@@ -7,6 +7,7 @@
* Note: you must update KVM_API_VERSION if you change this interface.
*/
+#include
#include
#include
#include
@@ -116,6 +117,11 @@
__u64 cr8;
__u64 apic_base;
+#ifdef CONFIG_S390
+ /* the processor status word for s390 */
+ __u64 psw_mask; /* psw upper half */
+ __u64 psw_addr; /* psw lower half */
+#endif
union {
/* KVM_EXIT_UNKNOWN */
struct {
@@ -167,8 +173,6 @@
/* KVM_EXIT_S390_SIEIC */
struct {
__u8 icptcode;
- __u64 mask; /* psw upper half */
- __u64 addr; /* psw lower half */
__u16 ipa;
__u32 ipb;
} s390_sieic;
Index: kvm/arch/s390/kvm/kvm-s390.c
===
--- kvm.orig/arch/s390/kvm/kvm-s390.c 2009-10-20 15:01:02.0 +0200
+++ kvm/arch/s390/kvm/kvm-s390.c2009-10-20 18:13:45.0 +0200
@@ -421,7 +421,8 @@
if (atomic_read(&vcpu->arch.sie_block->cpuflags) & CPUSTAT_RUNNING)
rc = -EBUSY;
else
- vcpu->arch.sie_block->gpsw = psw;
+ vcpu->run->psw_mask = psw.mask;
+ vcpu->run->psw_addr = psw.addr;
vcpu_put(vcpu);
return rc;
}
@@ -509,9 +510,6 @@
switch (kvm_run->exit_reason) {
case KVM_EXIT_S390_SIEIC:
- vcpu->arch.sie_block->gpsw.mask = kvm_run->s390_sieic.mask;
- vcpu->arch.sie_block->gpsw.addr = kvm_run->s390_sieic.addr;
- break;
case KVM_EXIT_UNKNOWN:
case KVM_EXIT_INTR:
case KVM_EXIT_S390_RESET:
@@ -520,6 +518,9 @@
BUG();
}
+ vcpu->arch.sie_block->gpsw.mask = kvm_run->psw_mask;
+ vcpu->arch.sie_block->gpsw.addr = kvm_run->psw_addr;
+
might_fault();
do {
@@ -539,8 +540,6 @@
/* intercept cannot be handled in-kernel, prepare kvm-run */
kvm_run->exit_reason = KVM_EXIT_S390_SIEIC;
kvm_run->s390_sieic.icptcode = vcpu->arch.sie_block->icptcode;
- kvm_run->s390_sieic.mask = vcpu->arch.sie_block->gpsw.mask;
- kvm_run->s390_sieic.addr = vcpu->arch.sie_block->gpsw.addr;
kvm_run->s390_sieic.ipa = vcpu->arch.sie_block->ipa;
kvm_run->s390_sieic.ipb = vcpu->arch.sie_block->ipb;
rc = 0;
@@ -552,6 +551,9 @@
rc = 0;
}
+ kvm_run->psw_mask = vcpu->arch.sie_block->gpsw.mask;
+ kvm_run->psw_addr = vcpu->arch.sie_block->gpsw.addr;
+
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &sigsaved, NULL);
[Qemu-devel] Re: [PATCH 2/9] Add KVM support for S390x
Alexander Graf wrote:
++static int s390_cpu_initial_reset(CPUState *env)
+{
+/* XXX */
+fprintf(stderr, "XXX SIGP init\n");
+return -1;
+}
That one will really break SMP. Most of the initial reset is handled
in-kernel for your convenience, therefore please think about using Kuli
as inspiration on how to do this one ;-).
Other then that, the s390 specifics in this patch look really nice.
[Qemu-devel] Re: [PATCH 1/9] Export function for VA defined ram allocation
Alexander Graf wrote: S390 requires vmas for guests to be < 256 GB. So we need to directly export mmaps "try to use this vma as start address" feature to not accidently get over that limit. Hmmh, now that x86 has solved all the problems we should probably move away from using the same page table for userspace and guest too. That would make this "workaround" superfluous and memslots would work just the same on s390 as they do on x86. I've put it on my todo list. For now, this looks good to me.
[Qemu-devel] Re: Release plan for 0.12.0
Hello, 2009/9/30 Anthony Liguori : > Hi, > > Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > o storage live migration Sorry for a bit off topic. But, my special NBD server can do this independently of VMM implementations. See http://bitbucket.org/hirofuchi/xnbd/wiki/Home if interested. Takahiro
Re: [Qemu-devel] [PATCH v9 3/3] virtio-console: Add a new virtserialport device for generic serial port support
On (Tue) Oct 20 2009 [16:02:16], Gerd Hoffmann wrote:
> On 10/20/09 11:48, Amit Shah wrote:
>> On (Tue) Oct 20 2009 [10:51:30], Gerd Hoffmann wrote:
@@ -107,3 +107,41 @@ static void virtcon_register(void)
virtio_serial_port_qdev_register(&virtcon_info);
}
device_init(virtcon_register)
>>>
+static VirtIOSerialPortInfo virtserial_port_info = {
+.qdev.name = "virtserialport",
+.qdev.size = sizeof(VirtConsole),
+.init = virtserial_port_initfn,
+.have_data = flush_buf,
+.qdev.props = (Property[]) {
+DEFINE_PROP_CHR("chardev", VirtConsole, chr),
+DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
>>>
>>> likewise: DEFINE_PROP_STRING("name", VirtConsole, port.name),
>>
>> The 'name' field is common to all ports, so it makes sense to put it in
>> the VirtIOSerialPort struct. (Internal users can pre-define it to their
>> liking, eg, org.qemu.vnc)
>
> Sure. I don't want to move it out there. But the driver state struct
> is 'VirtConsole' so all properties should use that. Note that the field
> changed too: from "name" to "port.name", so everything keeps working ;)
Ah; I understand it now. Sorry for the confusion.
Thanks Gerd for the reviews.
Amit
[Qemu-devel] CPU switch timing question
Hi, Suppose I use two cores, smp environment.I am wondering when QEMU switches CPUs and the time when the interrupt is raised.I've observed that every time cpu_interrupt is executed, there will be a cpu switch.CPU switch means the current running vCPU will stop and the other vCPU will run, since QEMU runs on 1 physical CPU. (The term "CPU" I mention in the following is vCPU).That means the CPU cannot handle the interrupt right after the interrupt is raised even the interrupt goes to it, but it needs to switch to the second CPU.And next time when the CPU is switched again, it can start to handle the pending interrupt.Is that right? Once the CPU executes cpu_interrupt function, is it forced to switch to anther CPU immediately? Or it can continues to run its TB before it consumes all its instructions counts.A more general question is what triggers CPU switch? I know there is an upper bound for instruction counts (not 100% sure). What else?Any information and guidance is very appreciated.Thanks. Regards,Tommy _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/
[Qemu-devel] Re: [PATCH 12/16] vmware_vga: remove !EMBED_STDVGA code
Hi, sorry for replying late, 2009/10/14 Juan Quintela : > I have another problem with the driver: depth. > > I have to change s->depth to 32 in vmsvga_reset() to make it work > correctly on my setup (default qemu.git tree, i.e. nothing fancy), > running with sdl. Any clue here? > > Anthony thinks that the problem happens at the memcpy() in > vmsvga_update_rect(), but I haven't had the time to look at how to fix > it. Any idea here? There's a thread about this issue at http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg00835.html Cheers
[Qemu-devel] Should MSR EFER and MSR STAR be saved to vmstate on target-i386?
I saw MSR EFER and MSR STAR were saved to vmstate on target-x86_64 only.But MSR EFER and MSR STAR can be accessed on target-i386,so should MSR EFER and MSR STAR be saved to vmstate on target-i386 too? -- View this message in context: http://www.nabble.com/Should-MSR-EFER-and-MSR-STAR-be-saved-to-vmstate-on-target-i386--tp25985483p25985483.html Sent from the QEMU - Dev mailing list archive at Nabble.com.
[Qemu-devel] [PATCH] vmstate: fix breakage by 7e72abc382b700a72549e8147bdea413534eeedc
cirrus_post_load() will be executed twice when loading vm states and then the
wrong physical memory will be registered. This issue may lead to crash qemu.
---
hw/cirrus_vga.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9dfe76a..262ba9c 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3017,7 +3017,6 @@ static const VMStateDescription vmstate_pci_cirrus_vga
= {
.version_id = 2,
.minimum_version_id = 2,
.minimum_version_id_old = 2,
-.post_load = cirrus_post_load,
.fields = (VMStateField []) {
VMSTATE_PCI_DEVICE(dev, PCICirrusVGAState),
VMSTATE_STRUCT(cirrus_vga, PCICirrusVGAState, 0,
--
View this message in context:
http://www.nabble.com/-PATCH--vmstate%3A-fix-breakage-by-7e72abc382b700a72549e8147bdea413534eeedc-tp25985345p25985345.html
Sent from the QEMU - Dev mailing list archive at Nabble.com.
Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM
Hi... On Wed, Oct 21, 2009 at 12:08 AM, Daniel P. Berrange wrote: > The problem with adding lots of magic key-sequences, is that the more > you add, the more likely they are to clash with something that the > guest OS wants to use. You may make this use case work, but break > someone else's use case. Thus, IMHO, magic key sequences should be kept > to the bare minimum neccessary to access functionality for which there > is no other viable access method. Thanks for the insights from all of you. The rule "to keep the magic keys at the bare minimum" is something I fairly agree. So probably in maintenance and development robustness's point of view, this patch should just live outside of main tree... well unless there are lot of supporter -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
[Qemu-devel] Re: [PATCH] qemu: work around for "posix-aio-compat"
On 10/20/2009 08:39 PM, Mark McLoughlin wrote: On Thu, 2009-10-08 at 22:37 +0200, Michael S. Tsirkin wrote: With commit ee3993069ff55fa6f1c64daf1e09963e340db8e4, "posix-aio-compat: avoid signal race when spawning a thread" winxp installation on a raw format file fails during disk format, with a message "your disk may be damaged". This commit moved signal mask from aio thread to creating thread. It turns out if we keep the mask in aio thread as well, the problem disappears. It should not be needed, but since this is harmless, let's keep it around until someone inclined to debug pthread library internals can check this issue. While we are at it, convert sigprocmask to pthread_sigmask as per posix. FWIW, I just started hitting a boot hang with qemu.git and --enable-kvm on a Fedora 11 machine with a Fedora 11 guest. I bisected it back to malc's commit, found this thread, applied Michael's patch and confirmed that it fixes the problem for me too. If anybody can send me the output of compiling the "strange" file with and without the patch, both with "-fdump-tree-all -fdump-rtl-all -O2 --save-temps -g" flags, I could try debugging it in GCC. It will be huge, so bz/gz/lzip it. Paolo
Re: [Qemu-devel] [PATCH] qemu: work around for "posix-aio-compat"
On Thu, 2009-10-08 at 22:37 +0200, Michael S. Tsirkin wrote: > With commit ee3993069ff55fa6f1c64daf1e09963e340db8e4, > "posix-aio-compat: avoid signal race when spawning a thread" > winxp installation on a raw format file fails > during disk format, with a message "your > disk may be damaged". > > This commit moved signal mask from aio thread to creating thread. > It turns out if we keep the mask in aio thread as well, the problem > disappears. It should not be needed, but since this is harmless, let's > keep it around until someone inclined to debug pthread library internals > can check this issue. > > While we are at it, convert sigprocmask to pthread_sigmask > as per posix. FWIW, I just started hitting a boot hang with qemu.git and --enable-kvm on a Fedora 11 machine with a Fedora 11 guest. I bisected it back to malc's commit, found this thread, applied Michael's patch and confirmed that it fixes the problem for me too. Cheers, Mark.
Re: [Qemu-devel] [PATCH 2/2] multiboot: Limit number of multiboot modules
Hi,
On Mon Oct 19, 2009 at 10:30:12 +0200, Kevin Wolf wrote:
> Am 14.10.2009 18:11, schrieb Adam Lackorzynski:
> > Subject: [PATCH 3/3] multiboot: Support arbitrary number of modules
> >
> > Signed-off-by: Adam Lackorzynski
>
> Looks good in general. I'm adding some minor comments inline.
>
> > +
> > +#define MULTIBOOT_FLAGS_MEMORY (1 << 0)
> > +#define MULTIBOOT_FLAGS_BOOT_DEVICE (1 << 1)
> > +#define MULTIBOOT_FLAGS_CMDLINE (1 << 2)
> > +#define MULTIBOOT_FLAGS_MODULES (1 << 3)
> > +#define MULTIBOOT_FLAGS_MMAP (1 << 6)
>
> You could align the (1 << n) to the same column.
Moved to the enum altogether.
> > +static void *mb_buf;
> > +static uint32_t mb_buf_phys; /* address in target */
> > +static int mb_buf_size; /* size of mb_buf in bytes */
> > +static int mb_mods_avail; /* available slots for mb_mods */
> > +static int mb_mods_count;
> > +static int mb_cmdlines_pos;
>
> Maybe it's just me, but I don't like using global variables for this.
> You could put them into a struct and pass it as a parameter to the
> functions.
Done.
> > +cur_end += TARGET_PAGE_ALIGN(cur_end + mb_buf_size);
>
> Sure that this isn't one cur_end too much if you're using += ?
Yes, well spotted, thanks.
> > +asprintf(&kcmdline, "%s %s",
> > kernel_filename, kernel_cmdline);
>
> Use snprintf instead of asprintf, the latter isn't available everywhere.
Done. New version follows
Subject: [PATCH] multiboot: Support arbitrary number of modules
Signed-off-by: Adam Lackorzynski
---
hw/pc.c | 182 ++-
1 files changed, 121 insertions(+), 61 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 408d6d6..e229cf6 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -588,6 +588,72 @@ static long get_file_size(FILE *f)
#error multiboot struct needs to fit in 16 bit real mode
#endif
+enum {
+/* Multiboot info */
+MBI_FLAGS = 0,
+MBI_MEM_LOWER = 4,
+MBI_MEM_UPPER = 8,
+MBI_BOOT_DEVICE = 12,
+MBI_CMDLINE = 16,
+MBI_MODS_COUNT = 20,
+MBI_MODS_ADDR = 24,
+MBI_MMAP_ADDR = 48,
+
+MBI_SIZE= 88,
+
+/* Multiboot modules */
+MB_MOD_START= 0,
+MB_MOD_END = 4,
+MB_MOD_CMDLINE = 8,
+
+MB_MOD_SIZE = 16,
+
+/* Region offsets */
+ADDR_E820_MAP = MULTIBOOT_STRUCT_ADDR + 0,
+ADDR_MBI = ADDR_E820_MAP + 0x500,
+
+/* Multiboot flags */
+MULTIBOOT_FLAGS_MEMORY = 1 << 0,
+MULTIBOOT_FLAGS_BOOT_DEVICE = 1 << 1,
+MULTIBOOT_FLAGS_CMDLINE = 1 << 2,
+MULTIBOOT_FLAGS_MODULES = 1 << 3,
+MULTIBOOT_FLAGS_MMAP= 1 << 6,
+};
+
+struct mb_state {
+void *mb_buf;
+uint32_t mb_buf_phys; /* address in target */
+int mb_buf_size; /* size of mb_buf in bytes */
+int mb_mods_avail; /* available slots for mb_mods */
+int mb_mods_count;
+int mb_cmdlines_pos;
+};
+
+static uint32_t mb_add_cmdline(struct mb_state *s, const char *cmdline)
+{
+int len = strlen(cmdline) + 1;
+uint32_t p = s->mb_cmdlines_pos;
+
+assert(p + len <= s->mb_buf_size);
+pstrcpy((char *)s->mb_buf + p, len, cmdline);
+s->mb_cmdlines_pos += len;
+return s->mb_buf_phys + p;
+}
+
+static void mb_add_mod(struct mb_state *s,
+ uint32_t start, uint32_t end,
+ uint32_t cmdline_phys)
+{
+char *p;
+assert(s->mb_mods_count < s->mb_mods_avail);
+
+p = (char *)s->mb_buf + MB_MOD_SIZE * s->mb_mods_count;
+stl_p(p + MB_MOD_START, start);
+stl_p(p + MB_MOD_END, end);
+stl_p(p + MB_MOD_CMDLINE, cmdline_phys);
+s->mb_mods_count++;
+}
+
static int load_multiboot(void *fw_cfg,
FILE *f,
const char *kernel_filename,
@@ -600,11 +666,9 @@ static int load_multiboot(void *fw_cfg,
uint32_t mh_entry_addr;
uint32_t mh_load_addr;
uint32_t mb_kernel_size;
-uint32_t mmap_addr = MULTIBOOT_STRUCT_ADDR;
-uint32_t mb_bootinfo = MULTIBOOT_STRUCT_ADDR + 0x500;
-uint32_t mb_mod_end;
-uint8_t bootinfo[0x500];
-uint32_t cmdline = 0x200;
+uint32_t cur_end;
+struct mb_state mbs;
+uint8_t bootinfo[MBI_SIZE];
/* Ok, let's see if it is a multiboot image.
The header is 12x32bit long, so the latest entry may be 8192 - 48. */
@@ -628,6 +692,7 @@ static int load_multiboot(void *fw_cfg,
fprintf(stderr, "qemu: I believe we found a multiboot image!\n");
#endif
memset(bootinfo, 0, sizeof(bootinfo));
+memset(&mbs, 0, sizeof(mbs));
if (flags & 0x0004) { /* MULTIBOOT_HEADER_HAS_VBE */
fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n");
@@ -687,90 +752,82 @@ static int load_multiboot(void *fw_cfg,
fclose(f);
}
-/* blob size is only the kernel for now */
-mb_mod_end = mh_load_addr + mb_kernel_size;
+cur_end = TARGET_PAGE_ALIGN(mh_load_addr + mb_kernel_size);
+
+/* Calculate space for cmdlines and mb_mods */
+mbs.mb
[Qemu-devel] Re: [PATCH] Makefile: Change make to be quiet again when doing nothing
On 10/20/2009 06:17 PM, Stefan Weil wrote: This patch makes make quiet again. There is already a similar patch from Juan Quintela, but maybe this shorter form is preferred. This patch would reintroduce an ordering problem between building config*.h and building the tools, whose fix is what made "make" noisy in the first place. Paolo
Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM
On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote: > Am 20.10.2009 00:20, schrieb Anthony Liguori: > > Mulyadi Santosa wrote: > >> IMO, it would be faster if we provide keyboard shortcuts that will > >> stop and resume VM execution right from SDL guest interface, rather > >> than switching to console monitor first and type "s" or "c" > >> respectively. > >> > > > > Is this really common of an operation that you would need an escape key > > for it? > > > > Why are you so frequently stopping and continuing a guest? > > Why are you all trying to explain to him that actually he doesn't want > to have this feature? I could have used it, too, at times (stop the > guest to have enough time to attach gdb, for example). There are other > ways to do it (although they are not as simple) and I used them, but > that doesn't make this feature less useful. > > Does it take anything away for you? Or do you have plans to use those > keys otherwise? If not, why not add a feature that some might find > useful, even though others don't? The problem with adding lots of magic key-sequences, is that the more you add, the more likely they are to clash with something that the guest OS wants to use. You may make this use case work, but break someone else's use case. Thus, IMHO, magic key sequences should be kept to the bare minimum neccessary to access functionality for which there is no other viable access method. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM
Kevin Wolf wrote: Am 20.10.2009 00:20, schrieb Anthony Liguori: Mulyadi Santosa wrote: IMO, it would be faster if we provide keyboard shortcuts that will stop and resume VM execution right from SDL guest interface, rather than switching to console monitor first and type "s" or "c" respectively. Is this really common of an operation that you would need an escape key for it? Why are you so frequently stopping and continuing a guest? Why are you all trying to explain to him that actually he doesn't want to have this feature? I could have used it, too, at times (stop the guest to have enough time to attach gdb, for example). There are other ways to do it (although they are not as simple) and I used them, but that doesn't make this feature less useful. Does it take anything away for you? Or do you have plans to use those keys otherwise? If not, why not add a feature that some might find useful, even though others don't? There is such a thing as feature bloat. It leads to very confusing behavior for users. It also increases the testing matrix. As it turns out, there's a better way to do what he's looking for that requires no changes. Had we just taken this patch, then that's another feature that has to be tested for SDL whenever there's a change there. It also means there will be differing behavior for VNC so it probably needs to be supported there. But then for something like libvirt, it's not going to expect that something else pauses/starts a VM. Features are not free. They have long term maintenance costs so we should consider whether a feature really offers value. Regards, Anthony Liguori
[Qemu-devel] [PATCH] Makefile: Change make to be quiet again when doing nothing
This patch makes make quiet again. There is already a similar patch from Juan Quintela, but maybe this shorter form is preferred. Signed-off-by: Stefan Weil --- Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index e78a3d0..4d9908c 100644 --- a/Makefile +++ b/Makefile @@ -40,8 +40,8 @@ config-all-devices.mak: $(SUBDIR_DEVICES_MAK) -include config-all-devices.mak -build-all: config-host.h config-all-devices.h - $(call quiet-command, $(MAKE) $(SUBDIR_MAKEFLAGS) $(TOOLS) $(DOCS) recurse-all,) +build-all: config-host.h config-all-devices.h $(DOCS) $(TOOLS) + $(call quiet-command, $(MAKE) $(SUBDIR_MAKEFLAGS) recurse-all,) config-host.h: config-host.h-timestamp config-host.h-timestamp: config-host.mak -- 1.5.6.5
[Qemu-devel] [PATCH 2/2] lsi_scsi: port to vmstate
Signed-off-by: Juan Quintela
---
hw/lsi53c895a.c | 242 +++
1 files changed, 83 insertions(+), 159 deletions(-)
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index a4d3a57..156727f 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -1959,173 +1959,97 @@ static void lsi_mmio_mapfunc(PCIDevice *pci_dev, int
region_num,
cpu_register_physical_memory(addr + 0, 0x400, s->mmio_io_addr);
}
-static void lsi_scsi_save(QEMUFile *f, void *opaque)
+static void lsi_pre_save(void *opaque)
{
LSIState *s = opaque;
assert(s->dma_buf == NULL);
assert(s->current_dma_len == 0);
assert(s->active_commands == 0);
-
-pci_device_save(&s->dev, f);
-
-qemu_put_sbe32s(f, &s->carry);
-qemu_put_sbe32s(f, &s->sense);
-qemu_put_sbe32s(f, &s->msg_action);
-qemu_put_sbe32s(f, &s->msg_len);
-qemu_put_buffer(f, s->msg, sizeof (s->msg));
-qemu_put_sbe32s(f, &s->waiting);
-
-qemu_put_be32s(f, &s->dsa);
-qemu_put_be32s(f, &s->temp);
-qemu_put_be32s(f, &s->dnad);
-qemu_put_be32s(f, &s->dbc);
-qemu_put_8s(f, &s->istat0);
-qemu_put_8s(f, &s->istat1);
-qemu_put_8s(f, &s->dcmd);
-qemu_put_8s(f, &s->dstat);
-qemu_put_8s(f, &s->dien);
-qemu_put_8s(f, &s->sist0);
-qemu_put_8s(f, &s->sist1);
-qemu_put_8s(f, &s->sien0);
-qemu_put_8s(f, &s->sien1);
-qemu_put_8s(f, &s->mbox0);
-qemu_put_8s(f, &s->mbox1);
-qemu_put_8s(f, &s->dfifo);
-qemu_put_8s(f, &s->ctest2);
-qemu_put_8s(f, &s->ctest3);
-qemu_put_8s(f, &s->ctest4);
-qemu_put_8s(f, &s->ctest5);
-qemu_put_8s(f, &s->ccntl0);
-qemu_put_8s(f, &s->ccntl1);
-qemu_put_be32s(f, &s->dsp);
-qemu_put_be32s(f, &s->dsps);
-qemu_put_8s(f, &s->dmode);
-qemu_put_8s(f, &s->dcntl);
-qemu_put_8s(f, &s->scntl0);
-qemu_put_8s(f, &s->scntl1);
-qemu_put_8s(f, &s->scntl2);
-qemu_put_8s(f, &s->scntl3);
-qemu_put_8s(f, &s->sstat0);
-qemu_put_8s(f, &s->sstat1);
-qemu_put_8s(f, &s->scid);
-qemu_put_8s(f, &s->sxfer);
-qemu_put_8s(f, &s->socl);
-qemu_put_8s(f, &s->sdid);
-qemu_put_8s(f, &s->ssid);
-qemu_put_8s(f, &s->sfbr);
-qemu_put_8s(f, &s->stest1);
-qemu_put_8s(f, &s->stest2);
-qemu_put_8s(f, &s->stest3);
-qemu_put_8s(f, &s->sidl);
-qemu_put_8s(f, &s->stime0);
-qemu_put_8s(f, &s->respid0);
-qemu_put_8s(f, &s->respid1);
-qemu_put_be32s(f, &s->mmrs);
-qemu_put_be32s(f, &s->mmws);
-qemu_put_be32s(f, &s->sfs);
-qemu_put_be32s(f, &s->drs);
-qemu_put_be32s(f, &s->sbms);
-qemu_put_be32s(f, &s->dbms);
-qemu_put_be32s(f, &s->dnad64);
-qemu_put_be32s(f, &s->pmjad1);
-qemu_put_be32s(f, &s->pmjad2);
-qemu_put_be32s(f, &s->rbc);
-qemu_put_be32s(f, &s->ua);
-qemu_put_be32s(f, &s->ia);
-qemu_put_be32s(f, &s->sbc);
-qemu_put_be32s(f, &s->csbc);
-qemu_put_buffer(f, (uint8_t *)s->scratch, sizeof (s->scratch));
-qemu_put_8s(f, &s->sbr);
-
-qemu_put_buffer(f, (uint8_t *)s->script_ram, sizeof (s->script_ram));
}
-static int lsi_scsi_load(QEMUFile *f, void *opaque, int version_id)
-{
-LSIState *s = opaque;
-int ret;
-
-if (version_id > 0) {
-return -EINVAL;
+static const VMStateDescription vmstate_lsi_scsi = {
+.name = "lsiscsi",
+.version_id = 0,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
+.pre_save = lsi_pre_save,
+.fields = (VMStateField []) {
+VMSTATE_PCI_DEVICE(dev, LSIState),
+
+VMSTATE_INT32(carry, LSIState),
+VMSTATE_INT32(sense, LSIState),
+VMSTATE_INT32(msg_action, LSIState),
+VMSTATE_INT32(msg_len, LSIState),
+VMSTATE_BUFFER(msg, LSIState),
+VMSTATE_INT32(waiting, LSIState),
+
+VMSTATE_UINT32(dsa, LSIState),
+VMSTATE_UINT32(temp, LSIState),
+VMSTATE_UINT32(dnad, LSIState),
+VMSTATE_UINT32(dbc, LSIState),
+VMSTATE_UINT8(istat0, LSIState),
+VMSTATE_UINT8(istat1, LSIState),
+VMSTATE_UINT8(dcmd, LSIState),
+VMSTATE_UINT8(dstat, LSIState),
+VMSTATE_UINT8(dien, LSIState),
+VMSTATE_UINT8(sist0, LSIState),
+VMSTATE_UINT8(sist1, LSIState),
+VMSTATE_UINT8(sien0, LSIState),
+VMSTATE_UINT8(sien1, LSIState),
+VMSTATE_UINT8(mbox0, LSIState),
+VMSTATE_UINT8(mbox1, LSIState),
+VMSTATE_UINT8(dfifo, LSIState),
+VMSTATE_UINT8(ctest2, LSIState),
+VMSTATE_UINT8(ctest3, LSIState),
+VMSTATE_UINT8(ctest4, LSIState),
+VMSTATE_UINT8(ctest5, LSIState),
+VMSTATE_UINT8(ccntl0, LSIState),
+VMSTATE_UINT8(ccntl1, LSIState),
+VMSTATE_UINT32(dsp, LSIState),
+VMSTATE_UINT32(dsps, LSIState),
+VMSTATE_UINT8(dmode, LSIState),
+VMSTATE_UINT8(dcntl, LSIState),
+VMSTATE_UINT8(scntl0, LSIState),
+VMSTATE_UINT8(scntl1, LSIState),
+VMSTATE_UINT8(scntl2, LSIState),
+VMSTATE
[Qemu-devel] [PATCH 1/2] vmstate: Add VMSTATE_BUFFER_UNSAFE
Just sent as a buffer. We put the pointer and the size
code does the rest.
Signed-off-by: Juan Quintela
---
hw/hw.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index b98f0c9..9e6ef09 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -484,6 +484,15 @@ extern const VMStateInfo vmstate_info_unused_buffer;
.offset = vmstate_offset_buffer(_state, _field) + _start,\
}
+#define VMSTATE_BUFFER_UNSAFE(_field, _state, _version, _size) { \
+.name = (stringify(_field)), \
+.version_id = (_version),\
+.size = (_size), \
+.info = &vmstate_info_buffer, \
+.flags = VMS_BUFFER,\
+.offset = offsetof(_state, _field), \
+}
+
#define VMSTATE_UNUSED_BUFFER(_test, _version, _size) { \
.name = "unused",\
.field_exists = (_test), \
--
1.6.2.5
[Qemu-devel] [PATCH 0/2] Port LSI SCSI to vmstate
It just needs to be able to transmit uint32_t as buffers. I tried to change code to UINT32_ARRAY, but then we broke backwards compatibilty. Later, Juan. Juan Quintela (2): vmstate: Add VMSTATE_BUFFER_UNSAFE lsi_scsi: port to vmstate hw/hw.h |9 ++ hw/lsi53c895a.c | 242 +++ 2 files changed, 92 insertions(+), 159 deletions(-)
[Qemu-devel] Re: [PATCH 00/25] VMState cleanups and conversion of network drivers
On 10/19/2009 09:15 PM, Jamie Lokier wrote: __builtin_types_compatible_p(), __builtin_choose_exper and __attribute__((__error__)) are good for informative error messages. Unfortunately __attribute__((__error__)) cannot be applied in this case for several reasons: 1) it cannot apply to types so you cannot do extern void compile_error (void); #define raise_compile_error(x) \ (((void __attribute__ ((error(x))) (*) (void)) x) ()) 2) it only operates for calls, so you cannot use it in initializers I whipped up a patch to add to GCC __builtin_compile_error, to be used inside __builtin_choose_expr: #define typecheck(t1, t2) \ __builtin_choose_expr (__builtin_types_compatible(t1, t2), (void)0, \ __builtin_compile_error (#t1 " and " #t2 \ "are not compatible types")) #define if_types_compatible(t1, t2, value) (typecheck (t1, t2), value) and I will send it upstream, but it will be a long time before it is in a released version (especially since GCC is currently in bug-fixing-only mode)---anyway Jamie got the array case to work, AFAIU. Paolo
Re: [Qemu-devel] QEMU Target CPU support for PowerPC MPC8270
On Tue, Oct 20, 2009 at 08:25:27AM +0200, Johnny Giacomoni wrote: > Hi everybody ! > > I currently work on Linux (Open SUSE) to emulate a CPU (MC8270, FreeScale). > > I know that QEMU is designed to simulate Operating Systems, but I just want > to emulate a CPU. It seem to be possible with QEMU. > > So, by seeing on http://www.qemu.org/status.html that PowerPC target is > testing, I wonder if it's not supported yet. > > For example, I've created a HelloWorld program which has to be executed on a > PowerPC CPU. To reach this goal, I first cross-compiled it (thanks to > crosstools) with a powerpc-powerpc-linux-gnu TARGET. So, when I use qemu-ppc > -cpu MPC8270 it works, but just because it's running on Linux. I just want a > program being sure that it runs only on a PowerPC CPU. > > > Can I do that with QEMU ? How can I do ? > > I looked on some forums (mainly those of qemu) but I didn't find my answer > -> http://qemu-forum.ipi.fi/viewforum.php?f=25 > > Can you help me please ? > > Thanks. Have a nice day ! You could use qemu-system-ppc and emulate a powermac and install a ppc linux distribution in it, and run your program there. That works fine. -- Len Sorensen
[Qemu-devel] [PATCH] properly save kvm system time msr registers
Currently, the msrs involved in setting up pvclock are not saved over
migration and/or save/restore. This patch puts their value in special
fields in our CPUState, and deal with them using vmstate.
kvm also has to account for it, by including them in the msr list
for the ioctls.
This is a backport from qemu-kvm.git
Signed-off-by: Glauber Costa
Signed-off-by: Marcelo Tosatti
---
target-i386/cpu.h |2 ++
target-i386/kvm.c | 13 +
target-i386/machine.c |3 +++
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 5929d28..f589044 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -651,6 +651,8 @@ typedef struct CPUX86State {
target_ulong fmask;
target_ulong kernelgsbase;
#endif
+uint64_t system_time_msr;
+uint64_t wall_clock_msr;
uint64_t tsc;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0e69b57..8a6fa29 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include "qemu-common.h"
#include "sysemu.h"
@@ -500,6 +501,9 @@ static int kvm_put_msrs(CPUState *env)
kvm_msr_entry_set(&msrs[n++], MSR_LSTAR, env->lstar);
}
#endif
+kvm_msr_entry_set(&msrs[n++], MSR_KVM_SYSTEM_TIME, env->system_time_msr);
+kvm_msr_entry_set(&msrs[n++], MSR_KVM_WALL_CLOCK, env->wall_clock_msr);
+
msr_data.info.nmsrs = n;
return kvm_vcpu_ioctl(env, KVM_SET_MSRS, &msr_data);
@@ -634,6 +638,9 @@ static int kvm_get_msrs(CPUState *env)
msrs[n++].index = MSR_LSTAR;
}
#endif
+msrs[n++].index = MSR_KVM_SYSTEM_TIME;
+msrs[n++].index = MSR_KVM_WALL_CLOCK;
+
msr_data.info.nmsrs = n;
ret = kvm_vcpu_ioctl(env, KVM_GET_MSRS, &msr_data);
if (ret < 0)
@@ -670,6 +677,12 @@ static int kvm_get_msrs(CPUState *env)
case MSR_IA32_TSC:
env->tsc = msrs[i].data;
break;
+case MSR_KVM_SYSTEM_TIME:
+env->system_time_msr = msrs[i].data;
+break;
+case MSR_KVM_WALL_CLOCK:
+env->wall_clock_msr = msrs[i].data;
+break;
}
}
diff --git a/target-i386/machine.c b/target-i386/machine.c
index b13eff4..f6fe216 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -475,6 +475,9 @@ const VMStateDescription vmstate_cpu = {
VMSTATE_UINT64_ARRAY_V(mce_banks, CPUState, MCE_BANKS_DEF *4, 10),
/* rdtscp */
VMSTATE_UINT64_V(tsc_aux, CPUState, 11),
+/* KVM pvclock msr */
+VMSTATE_UINT64_V(system_time_msr, CPUState, 11),
+VMSTATE_UINT64_V(wall_clock_msr, CPUState, 11),
VMSTATE_END_OF_LIST()
}
};
--
1.6.2.5
Re: [Qemu-devel] [PATCH v9 3/3] virtio-console: Add a new virtserialport device for generic serial port support
On 10/20/09 11:48, Amit Shah wrote:
On (Tue) Oct 20 2009 [10:51:30], Gerd Hoffmann wrote:
@@ -107,3 +107,41 @@ static void virtcon_register(void)
virtio_serial_port_qdev_register(&virtcon_info);
}
device_init(virtcon_register)
+static VirtIOSerialPortInfo virtserial_port_info = {
+.qdev.name = "virtserialport",
+.qdev.size = sizeof(VirtConsole),
+.init = virtserial_port_initfn,
+.have_data = flush_buf,
+.qdev.props = (Property[]) {
+DEFINE_PROP_CHR("chardev", VirtConsole, chr),
+DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
likewise: DEFINE_PROP_STRING("name", VirtConsole, port.name),
The 'name' field is common to all ports, so it makes sense to put it in
the VirtIOSerialPort struct. (Internal users can pre-define it to their
liking, eg, org.qemu.vnc)
Sure. I don't want to move it out there. But the driver state struct
is 'VirtConsole' so all properties should use that. Note that the field
changed too: from "name" to "port.name", so everything keeps working ;)
cheers,
Gerd
Re: [Qemu-devel] [RFC] in-kernel irqchip : split devices
Specially Avi,
comments on this one?
2009/10/14 Glauber Costa :
> Hello people,
>
> As I promised, I am sending a very brief PoC wrt split devices and in-kernel
> irqchip.
> In this mail, I am including only the ioapic version for apreciation. I also
> have i8259,
> and apic will take me a little bit more. This is just to try to bind the
> discussion to real
> code.
>
> Note that we end up with a very slim representation of the device, and the
> code is much less
> confusing, IMHO.
>
>
>
> Index: qemu/Makefile.target
> ===
> --- qemu.orig/Makefile.target
> +++ qemu/Makefile.target
> @@ -197,6 +197,8 @@ obj-i386-y += usb-uhci.o vmmouse.o vmpor
> obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
> obj-i386-y += ne2000-isa.o
>
> +obj-i386-$(CONFIG_KVM) += ioapic-kvm.o
> +
> # shared objects
> obj-ppc-y = ppc.o ide/core.o ide/qdev.o ide/isa.o ide/pci.o ide/macio.o
> obj-ppc-y += vga.o vga-pci.o $(sound-obj-y) dma.o openpic.o
> Index: qemu/hw/ioapic-kvm.c
> ===
> --- /dev/null
> +++ qemu/hw/ioapic-kvm.c
> @@ -0,0 +1,81 @@
> +#include "hw.h"
> +#include "pc.h"
> +#include "qemu-timer.h"
> +#include "host-utils.h"
> +#include "kvm.h"
> +
> +#define IOAPIC_NUM_PINS 0x18
> +#define IOAPIC_DEFAULT_BASE_ADDRESS 0xfec0
> +
> +static void ioapic_reset(void *opaque)
> +{
> + struct kvm_ioapic_state *s = opaque;
> + struct kvm_irqchip *chip;
> + int i;
> +
> + chip = container_of(s, struct kvm_irqchip, chip.ioapic);
> +
> + chip->chip_id = KVM_IRQCHIP_IOAPIC;
> +
> + memset(s, 0, sizeof(*s));
> + s->base_address = IOAPIC_DEFAULT_BASE_ADDRESS;
> + for(i = 0; i < IOAPIC_NUM_PINS; i++)
> + s->redirtbl[i].bits = 1 << 16; /* mask LVT */
> +
> + kvm_set_irqchip(chip);
> +}
> +
> +static void ioapic_pre_save(void *opaque)
> +{
> + struct kvm_ioapic_state *s = opaque;
> + struct kvm_irqchip *chip;
> +
> + chip = container_of(s, struct kvm_irqchip, chip.ioapic);
> +
> + kvm_get_irqchip(chip);
> +}
> +
> +static int ioapic_post_load(void *opaque, int version_id)
> +{
> + struct kvm_ioapic_state *s = opaque;
> + struct kvm_irqchip *chip;
> +
> + chip = container_of(s, struct kvm_irqchip, chip.ioapic);
> +
> + return kvm_set_irqchip(chip);
> +}
> +
> +static const VMStateDescription vmstate_kvm_ioapic = {
> + .name = "ioapic-kvm",
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .post_load = ioapic_post_load,
> + .pre_save = ioapic_pre_save,
> + .fields = (VMStateField []) {
> + VMSTATE_U64(base_address, struct kvm_ioapic_state),
> + VMSTATE_UINT32(id, struct kvm_ioapic_state),
> + VMSTATE_UINT32(ioregsel, struct kvm_ioapic_state),
> + VMSTATE_UINT32(irr, struct kvm_ioapic_state),
> + VMSTATE_ARRAY_UNSAFE(redirtbl, struct kvm_ioapic_state,
> IOAPIC_NUM_PINS, 0, vmstate_info_u64, __u64),
> + VMSTATE_END_OF_LIST()
> + }
> +};
> +
> +
> +static void kvm_ioapic_set_irq(void *opaque, int vector, int level)
> +{
> +}
> +
> +qemu_irq *kvm_ioapic_init(void)
> +{
> + struct kvm_irqchip *s;
> +
> + s = qemu_mallocz(sizeof(*s));
> +
> + ioapic_reset(&s->chip.ioapic);
> +
> + vmstate_register(0, &vmstate_kvm_ioapic, &s->chip.ioapic);
> + qemu_register_reset(ioapic_reset, &s->chip.ioapic);
> +
> + return qemu_allocate_irqs(kvm_ioapic_set_irq, &s->chip.ioapic,
> IOAPIC_NUM_PINS);
> +}
> Index: qemu/hw/pc.h
> ===
> --- qemu.orig/hw/pc.h
> +++ qemu/hw/pc.h
> @@ -48,6 +48,8 @@ void ioapic_set_irq(void *opaque, int ve
> void apic_reset_irq_delivered(void);
> int apic_get_irq_delivered(void);
>
> +qemu_irq *kvm_ioapic_init(void);
> +
> /* i8254.c */
>
> #define PIT_FREQ 1193182
> Index: qemu/kvm-all.c
> ===
> --- qemu.orig/kvm-all.c
> +++ qemu/kvm-all.c
> @@ -411,6 +411,26 @@ int kvm_check_extension(KVMState *s, uns
> return ret;
> }
>
> +#ifdef KVM_CAP_IRQCHIP
> +int kvm_set_irqchip(struct kvm_irqchip *chip)
> +{
> + if (!kvm_state->irqchip_in_kernel) {
> + return 0;
> + }
> +
> + return kvm_vm_ioctl(kvm_state, KVM_SET_IRQCHIP, chip);
> +}
> +
> +int kvm_get_irqchip(struct kvm_irqchip *chip)
> +{
> + if (!kvm_state->irqchip_in_kernel) {
> + return 0;
> + }
> +
> + return kvm_vm_ioctl(kvm_state, KVM_GET_IRQCHIP, chip);
> +}
> +#endif
> +
> int kvm_init(int smp_cpus)
> {
> static const char upgrade_note[] =
> Index: qemu/kvm.h
> ===
> --- qemu.orig/kvm.h
> +++ qemu/kvm.h
> @@ -16,6 +16,7 @@
>
> #include "config.h"
> #include "qemu-queue.h"
> +#include
>
> #ifdef CONFIG_KVM
> extern int kvm_allowed;
> @@ -63,6 +64,9 @@ int kvm_update_guest_debug(CPUState *env
> int kvm_pit_in_kernel(vo
Re: [Qemu-devel] [PATCH v9 2/3] virtio-console: Add a virtio-serial bus, support for multiple ports
On (Tue) Oct 20 2009 [13:05:59], Richard W.M. Jones wrote: > On Tue, Oct 20, 2009 at 05:31:23PM +0530, Amit Shah wrote: > > How about (deprecated)? (We need to have this in some general policy of > > deprecating command-line options.) > > No, the important thing is that we can detect somehow that multiport > virtio console is possible for some random version of qemu that we > have to work with. > > The only feasible way we've been able to discover is to poke qemu with > various arguments (usually, "qemu -help") and then match on substrings > in the output. Hm, probing with -device '?' will get you the new devices: -device virtio-serial-pci and -device virtserialport are two new devices added (along with -device virtconsole). > If there's a better way to do this, please let me know. I'm not sure of that, but there should be. > But for now, having "(multiport)" there allows us to detect that > multiport virtio console is supported. But suggesting -virtioconsole supports multiport is misleading and further usage of -virtioconsole is not to be encouraged as well.. > > > I think you mean -device virtconsole here. > > > > Yeah; thanks. Will fix. > > So is this documentation correct or not? > > http://www.linux-kvm.org/page/VMchannel_Requirements#Invocation Yes, that's updated very recently and is according to what we have now. Amit
Re: [Qemu-devel] [PATCH v9 2/3] virtio-console: Add a virtio-serial bus, support for multiple ports
On Tue, Oct 20, 2009 at 05:31:23PM +0530, Amit Shah wrote: > How about (deprecated)? (We need to have this in some general policy of > deprecating command-line options.) No, the important thing is that we can detect somehow that multiport virtio console is possible for some random version of qemu that we have to work with. The only feasible way we've been able to discover is to poke qemu with various arguments (usually, "qemu -help") and then match on substrings in the output. If there's a better way to do this, please let me know. But for now, having "(multiport)" there allows us to detect that multiport virtio console is supported. > > I think you mean -device virtconsole here. > > Yeah; thanks. Will fix. So is this documentation correct or not? http://www.linux-kvm.org/page/VMchannel_Requirements#Invocation Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
Re: [Qemu-devel] [PATCH v9 0/3] virtio-console: Add support for multiple ports for generic guest-host communication
On (Tue) Oct 20 2009 [13:54:33], Dor Laor wrote: > On 10/20/2009 09:13 AM, Amit Shah wrote: >> Hello, >> >> This patch series fixes a few problems since the last send, mainly in >> the save/restore code and a few bugs shown by the automated test suite >> (located in a separate git repo, link below). >> >> The automated test suite and a standalone interactive test program are >> located at >> >> http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git > > Why not keep it in-tree? Out of tree it will soon break, especially for > new releases and it'll be harder for autotest to pick it up. The code is best integrated within autotest and I'm talking with Lucas for integrating it. BTW if a test breaks, it's generally not a good sign :-) Amit
Re: [Qemu-devel] [PATCH v9 2/3] virtio-console: Add a virtio-serial bus, support for multiple ports
On (Tue) Oct 20 2009 [12:08:06], Richard W.M. Jones wrote:
> On Tue, Oct 20, 2009 at 12:43:44PM +0530, Amit Shah wrote:
> > DEF("virtioconsole", HAS_ARG, QEMU_OPTION_virtiocon, \
> > "-virtioconsole c\n" \
> > -"set virtio console\n")
> > +"define virtio console\n")
>
> It would be much better to add a detectable string here so we
> (libguestfs) can tell if multiport is supported. Something like:
>
>"set virtio console (multiport)\n"
How about (deprecated)? (We need to have this in some general policy of
deprecating command-line options.)
> > STEXI
> > @item -virtioconsole @var{c}
> > Set virtio console.
> > +
> > +This option is maintained for backward compatibility.
> > +
> > +Please use @code{-device virtioconsole} for the new way of invocation
>
> I think you mean -device virtconsole here.
Yeah; thanks. Will fix.
Amit
Re: [Qemu-devel] [PATCH v9 0/3] virtio-console: Add support for multiple ports for generic guest-host communication
On 10/20/2009 09:13 AM, Amit Shah wrote: Hello, This patch series fixes a few problems since the last send, mainly in the save/restore code and a few bugs shown by the automated test suite (located in a separate git repo, link below). The automated test suite and a standalone interactive test program are located at http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Why not keep it in-tree? Out of tree it will soon break, especially for new releases and it'll be harder for autotest to pick it up. These patches are based on top of the char patches I've sent
Re: [Qemu-devel] [PATCH v9 2/3] virtio-console: Add a virtio-serial bus, support for multiple ports
On Tue, Oct 20, 2009 at 12:43:44PM +0530, Amit Shah wrote:
> DEF("virtioconsole", HAS_ARG, QEMU_OPTION_virtiocon, \
> "-virtioconsole c\n" \
> -"set virtio console\n")
> +"define virtio console\n")
It would be much better to add a detectable string here so we
(libguestfs) can tell if multiport is supported. Something like:
"set virtio console (multiport)\n"
> STEXI
> @item -virtioconsole @var{c}
> Set virtio console.
> +
> +This option is maintained for backward compatibility.
> +
> +Please use @code{-device virtioconsole} for the new way of invocation
I think you mean -device virtconsole here.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
[Qemu-devel] Add iterative phase to qemu_savevm_state to allow live storage migration
qemu_savevm_state will call all registered components with 3 phases: START, PART, END. Only the PART phase is iterative. In case of storage live migration we have lot more data to copy then memory and usually the dirty rate is much less then memory dirty rate. I thought about adding an iterative phase before PART for iterating massive data transfer that we want to transfer before starting to transfer memory data. The new phase will be iterative and will step to the next phase only when all registered components will agree. What do you think? - Liran
Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM
Am 20.10.2009 00:20, schrieb Anthony Liguori: > Mulyadi Santosa wrote: >> IMO, it would be faster if we provide keyboard shortcuts that will >> stop and resume VM execution right from SDL guest interface, rather >> than switching to console monitor first and type "s" or "c" >> respectively. >> > > Is this really common of an operation that you would need an escape key > for it? > > Why are you so frequently stopping and continuing a guest? Why are you all trying to explain to him that actually he doesn't want to have this feature? I could have used it, too, at times (stop the guest to have enough time to attach gdb, for example). There are other ways to do it (although they are not as simple) and I used them, but that doesn't make this feature less useful. Does it take anything away for you? Or do you have plans to use those keys otherwise? If not, why not add a feature that some might find useful, even though others don't? Kevin
[Qemu-devel] Re: [PATCH] raw/linux-aio: Also initialize POSIX AIO
Am 20.10.2009 11:33, schrieb Kevin Wolf: > When using Linux AIO raw still falls back to POSIX AIO sometimes, so we should > initialize it. > > Not initializing it happens to work if POSIX AIO is used by another drive, or > if the format is not specified (probing the format uses POSIX AIO) or by pure > luck (e.g. it doesn't seem to happen any more with qcow2 since we have > re-added > synchronous qcow2 functions). On that note, falling back to POSIX AIO means that paio_submit is called with a Linux AIO aio_ctx. Which works because this parameter is unused anyway, but am I the only one to find this ugly? What is the public interface of paio_submit meant to look like at all? If aio_ctx is guaranteed to be unused, why not drop it or pass NULL at least? And if it could be used some time in the future, the raw block driver needs to be fixed. That said, I don't even think that the raw block driver is the right place to distinguish between different AIO variants. Having a generic aio_submit that calls the right AIO driver depending on the context would be much cleaner. This would also mean that laio_submit handles the fallback to paio_submit on its own, which I think is much cleaner than teaching raw about the capabilities of each driver. Does this make sense or is there this little detail that is too easy to miss? Kevin
Re: [Qemu-devel] Starting QEMU by PHP/Apache
On Tue, Oct 13, 2009 at 01:26:25PM +0200, Bolle wrote: > Did anybody had success to start a QEMU instance by a PHP script under > the Apache web server ? > > I allow the Apache user with the help of sudoers to start the QEMU binary > as root. I've hacked the "qemu-socket.c" to set the access mode to allow > communication for the monitor socket (only add "chmod(path, mode bits>)"). I don't understand why you want to start qemu as root. It doesn't need to be root (even for KVM support) and we run it as non-root all the time in http://libguestfs.org/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Re: [Qemu-devel] [PATCH v9 0/3] virtio-console: Add support for multiple ports for generic guest-host communication
On (Tue) Oct 20 2009 [10:56:40], Gerd Hoffmann wrote: > Hi, > >> This patch series fixes a few problems since the last send, mainly in >> the save/restore code and a few bugs shown by the automated test suite >> (located in a separate git repo, link below). > > A bit hard to review in this form, especially the virtio-console.c > changes, because you put everything upside down in that file. Hard to > do better though given the massive code reorganization ... Top-down is the usual way of writing code, isn't it (avoids fwd declarations too). Also, I've arranged the code according to some grouping: functions useful to outside users first, then functions using some outside facilities, and then intialisation functions. > So I applied the bits and looked at the resulting tree instead. Looks > good overall, just a few minor nits, check the replies to the individual > patches. I think we are ready to go as soon as the linux kernel side is > on the way to mainline. Yeah; waiting for Rusty's comments. Amit
Re: [Qemu-devel] [PATCH v9 3/3] virtio-console: Add a new virtserialport device for generic serial port support
On (Tue) Oct 20 2009 [10:51:30], Gerd Hoffmann wrote:
>> @@ -107,3 +107,41 @@ static void virtcon_register(void)
>> virtio_serial_port_qdev_register(&virtcon_info);
>> }
>> device_init(virtcon_register)
>
>> +static VirtIOSerialPortInfo virtserial_port_info = {
>> +.qdev.name = "virtserialport",
>> +.qdev.size = sizeof(VirtConsole),
>> +.init = virtserial_port_initfn,
>> +.have_data = flush_buf,
>> +.qdev.props = (Property[]) {
>> +DEFINE_PROP_CHR("chardev", VirtConsole, chr),
>> +DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
>
> likewise: DEFINE_PROP_STRING("name", VirtConsole, port.name),
The 'name' field is common to all ports, so it makes sense to put it in
the VirtIOSerialPort struct. (Internal users can pre-define it to their
liking, eg, org.qemu.vnc)
>> +static void virtserial_port_register(void)
>> +{
>> +virtio_serial_port_qdev_register(&virtserial_port_info);
>> +}
>> +device_init(virtserial_port_register)
>
> You can simply stick two register calls into the existing init function ...
The console init function has extra init'ing to do, like disable buffer
caching, set is_console to true, etc., so there are two init fns.
Amit
[Qemu-devel] [PATCH] raw/linux-aio: Also initialize POSIX AIO
When using Linux AIO raw still falls back to POSIX AIO sometimes, so we should
initialize it.
Not initializing it happens to work if POSIX AIO is used by another drive, or
if the format is not specified (probing the format uses POSIX AIO) or by pure
luck (e.g. it doesn't seem to happen any more with qcow2 since we have re-added
synchronous qcow2 functions).
Signed-off-by: Kevin Wolf
---
block/raw-posix.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 20b37a7..5547fb5 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -173,6 +173,10 @@ static int raw_open_common(BlockDriverState *bs, const
char *filename,
#ifdef CONFIG_LINUX_AIO
if ((bdrv_flags & (BDRV_O_NOCACHE|BDRV_O_NATIVE_AIO)) ==
(BDRV_O_NOCACHE|BDRV_O_NATIVE_AIO)) {
+
+/* We're falling back to POSIX AIO in some cases */
+paio_init();
+
s->aio_ctx = laio_init();
if (!s->aio_ctx) {
goto out_free_buf;
--
1.6.2.5
Re: [Qemu-devel] [PATCH v9 0/3] virtio-console: Add support for multiple ports for generic guest-host communication
Hi, This patch series fixes a few problems since the last send, mainly in the save/restore code and a few bugs shown by the automated test suite (located in a separate git repo, link below). A bit hard to review in this form, especially the virtio-console.c changes, because you put everything upside down in that file. Hard to do better though given the massive code reorganization ... So I applied the bits and looked at the resulting tree instead. Looks good overall, just a few minor nits, check the replies to the individual patches. I think we are ready to go as soon as the linux kernel side is on the way to mainline. cheers, Gerd
Re: [Qemu-devel] [PATCH v9 3/3] virtio-console: Add a new virtserialport device for generic serial port support
@@ -107,3 +107,41 @@ static void virtcon_register(void)
virtio_serial_port_qdev_register(&virtcon_info);
}
device_init(virtcon_register)
+static VirtIOSerialPortInfo virtserial_port_info = {
+.qdev.name = "virtserialport",
+.qdev.size = sizeof(VirtConsole),
+.init = virtserial_port_initfn,
+.have_data = flush_buf,
+.qdev.props = (Property[]) {
+DEFINE_PROP_CHR("chardev", VirtConsole, chr),
+DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
likewise: DEFINE_PROP_STRING("name", VirtConsole, port.name),
+static void virtserial_port_register(void)
+{
+virtio_serial_port_qdev_register(&virtserial_port_info);
+}
+device_init(virtserial_port_register)
You can simply stick two register calls into the existing init function ...
cheers,
Gerd
Re: [Qemu-devel] [PATCH v9 2/3] virtio-console: Add a virtio-serial bus, support for multiple ports
+static VirtIOSerialPortInfo virtcon_info = {
+.qdev.name = "virtconsole",
+.qdev.size = sizeof(VirtConsole),
+.init = vcon_initfn,
+.have_data = flush_buf,
+.qdev.props = (Property[]) {
+DEFINE_PROP_CHR("chardev", VirtConsole, chr),
+DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
DEFINE_PROP_STRING("name", VirtConsole, port.name)
cheers,
Gerd
[Qemu-devel] Re: [PATCH 2/9] Add KVM support for S390x
On 20.10.2009, at 10:36, Carsten Otte wrote:
Alexander Graf wrote:
++static int s390_cpu_initial_reset(CPUState *env)
+{
+/* XXX */
+fprintf(stderr, "XXX SIGP init\n");
+return -1;
+}
That one will really break SMP. Most of the initial reset is
handled in-kernel for your convenience, therefore please think about
using Kuli as inspiration on how to do this one ;-).
Yes, SMP support is missing still. I ran into some problem
implementing it.
Qemu by default doesn't allow -smp > 1 anyways, so I figured it's not
too much of a problem for starters.
Other then that, the s390 specifics in this patch look really nice.
Thanks :-)
Alex
Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM
On Tue, Oct 20, 2009 at 10:16:09AM +0700, Mulyadi Santosa wrote: > Hi Anthony... > > On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori > wrote: > > Mulyadi Santosa wrote: > >> > >> IMO, it would be faster if we provide keyboard shortcuts that will > >> stop and resume VM execution right from SDL guest interface, rather > >> than switching to console monitor first and type "s" or "c" > >> respectively. > >> > > > > Is this really common of an operation that you would need an escape key for > > it? > > > > Why are you so frequently stopping and continuing a guest? > > Thanks for giving a review. > > One of the use case is to pause guest at a specific moment relatively > fast. For example, I boot a guest and I want to capture at a certain > moment when the guest kernel initialize and print something in the > screen. > > As these message scrolls fast, I find it more intuitive if we could > just press a key to pause the guest, giving us enough time to capture > the display and resume the execution. If we switch to qemu monitor > first, most of the time we already lost the moment. If its too slow to switch to the monitor virtual console,then don't configure the monitor in that way. Set it up to be on stdio, or one of the other backends. That lets you have both the monitor & SDL display visible at the same time & would be just as fast to type in 'stop' at the appropriate time. If its kernel text output you need to see then a serial port + logging is the best option here as Gerd suggests. If its video output you need to see, then VNC along with something like vnc2swf which will record the entire VNC data stream to a movie, which you can then play back and easily pause at any point. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM
On 10/20/09 05:16, Mulyadi Santosa wrote: As these message scrolls fast, I find it more intuitive if we could just press a key to pause the guest, giving us enough time to capture the display and resume the execution. If we switch to qemu monitor first, most of the time we already lost the moment. I'd find it more intuitive to setup a serial console in the guest, then simply log everything to a file ... cheers, Gerd
[Qemu-devel] [PATCH v9 3/3] virtio-console: Add a new virtserialport device for generic serial port support
This patch adds generic serial ports over the virtio serial bus.
These ports have a few more options that are not relevant for
virtio console ports: the ability to cache buffers that are
received for a port while it's disconnected, setting of limits
to the bytes that are cached so as to prevent OOM conditions,
etc.
Sample uses for such a device can be obtaining info from the
guest like the file systems used, apps installed, etc. for
offline usage and logged-in users, clipboard copy-paste, etc.
for online usage.
For requirements, use-cases, test cases and some history see
http://www.linux-kvm.org/page/VMchannel_Requirements
Signed-off-by: Amit Shah
---
hw/virtio-console.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index ef32820..fec346c 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -107,3 +107,41 @@ static void virtcon_register(void)
virtio_serial_port_qdev_register(&virtcon_info);
}
device_init(virtcon_register)
+
+
+/* Generic Virtio Serial Ports */
+static int virtserial_port_initfn(VirtIOSerialDevice *dev)
+{
+VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, &dev->qdev);
+VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
+
+port->info = dev->info;
+
+if (vcon->chr) {
+qemu_chr_add_handlers(vcon->chr, chr_can_read, chr_read, chr_event,
+ vcon);
+}
+return 0;
+}
+
+static VirtIOSerialPortInfo virtserial_port_info = {
+.qdev.name = "virtserialport",
+.qdev.size = sizeof(VirtConsole),
+.init = virtserial_port_initfn,
+.have_data = flush_buf,
+.qdev.props = (Property[]) {
+DEFINE_PROP_CHR("chardev", VirtConsole, chr),
+DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
+DEFINE_PROP_INT32("cache_buffers", VirtIOSerialPort, cache_buffers, 1),
+DEFINE_PROP_UINT64("byte_limit", VirtIOSerialPort, byte_limit, 0),
+DEFINE_PROP_UINT64("guest_byte_limit", VirtIOSerialPort,
+ guest_byte_limit, 0),
+DEFINE_PROP_END_OF_LIST(),
+},
+};
+
+static void virtserial_port_register(void)
+{
+virtio_serial_port_qdev_register(&virtserial_port_info);
+}
+device_init(virtserial_port_register)
--
1.6.2.5
[Qemu-devel] [PATCH v9 2/3] virtio-console: Add a virtio-serial bus, support for multiple ports
This patch migrates virtio-console to the qdev infrastructure and
creates a new virtio-serial bus on which multiple ports are exposed as
devices. The bulk of the code now resides in a new file with
virtio-console.c being just a simple qdev device.
This interface enables spawning of multiple virtio consoles as well as generic
serial ports.
The older -virtconsole argument still works, but when using the new
functionality, it is recommended to use
-device virtio-serial-pci -device virtconsole,...
The virtconsole device type accepts a chardev as an argument and a 'name'
argument to identify the corresponding consoles on the host as well as the
guest. The name, if given, is exposed via the 'name' sysfs attribute.
Care has been taken to ensure compatibility with kernels that do not
support multiple ports as well as accepting incoming migrations from older
qemu versions.
Signed-off-by: Amit Shah
---
Makefile.target|2 +-
hw/pc.c|9 -
hw/ppc440_bamboo.c |7 -
hw/qdev.c |8 +-
hw/virtio-console.c| 180 +---
hw/virtio-console.h| 19 --
hw/virtio-pci.c|8 +-
hw/virtio-serial-bus.c | 764
hw/virtio-serial.h | 227 ++
hw/virtio.h|2 +-
qemu-options.hx|6 +-
sysemu.h |6 -
vl.c | 65 +++--
13 files changed, 1118 insertions(+), 185 deletions(-)
delete mode 100644 hw/virtio-console.h
create mode 100644 hw/virtio-serial-bus.c
create mode 100644 hw/virtio-serial.h
diff --git a/Makefile.target b/Makefile.target
index 8d146c5..fd86eeb 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -157,7 +157,7 @@ ifdef CONFIG_SOFTMMU
obj-y = vl.o monitor.o pci.o machine.o gdbstub.o
# virtio has to be here due to weird dependency between PCI and virtio-net.
# need to fix this properly
-obj-y += virtio-blk.o virtio-balloon.o virtio-net.o virtio-console.o
virtio-pci.o
+obj-y += virtio-blk.o virtio-balloon.o virtio-net.o virtio-serial-bus.o
virtio-console.o virtio-pci.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
LIBS+=-lz
diff --git a/hw/pc.c b/hw/pc.c
index 408d6d6..3dbe718 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1319,15 +1319,6 @@ static void pc_init1(ram_addr_t ram_size,
pci_create_simple(pci_bus, -1, "lsi53c895a");
}
}
-
-/* Add virtio console devices */
-if (pci_enabled) {
-for(i = 0; i < MAX_VIRTIO_CONSOLES; i++) {
-if (virtcon_hds[i]) {
-pci_create_simple(pci_bus, -1, "virtio-console-pci");
-}
-}
-}
}
static void pc_init_pci(ram_addr_t ram_size,
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index a488240..1ab9872 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -108,13 +108,6 @@ static void bamboo_init(ram_addr_t ram_size,
env = ppc440ep_init(&ram_size, &pcibus, pci_irq_nrs, 1, cpu_model);
if (pcibus) {
-/* Add virtio console devices */
-for(i = 0; i < MAX_VIRTIO_CONSOLES; i++) {
-if (virtcon_hds[i]) {
-pci_create_simple(pcibus, -1, "virtio-console-pci");
-}
-}
-
/* Register network interfaces. */
for (i = 0; i < nb_nics; i++) {
/* There are no PCI NICs on the Bamboo board, but there are
diff --git a/hw/qdev.c b/hw/qdev.c
index 20f931c..374d2d0 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -321,13 +321,9 @@ void qdev_machine_creation_done(void)
CharDriverState *qdev_init_chardev(DeviceState *dev)
{
static int next_serial;
-static int next_virtconsole;
+
/* FIXME: This is a nasty hack that needs to go away. */
-if (strncmp(dev->info->name, "virtio", 6) == 0) {
-return virtcon_hds[next_virtconsole++];
-} else {
-return serial_hds[next_serial++];
-}
+return serial_hds[next_serial++];
}
BusState *qdev_get_parent_bus(DeviceState *dev)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 57f8f89..ef32820 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -1,143 +1,109 @@
/*
- * Virtio Console Device
+ * Virtio Console and Generic Port Devices
*
- * Copyright IBM, Corp. 2008
+ * Copyright Red Hat, Inc. 2009
*
* Authors:
- * Christian Ehrhardt
+ * Amit Shah
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
- *
*/
-#include "hw.h"
#include "qemu-char.h"
-#include "virtio.h"
-#include "virtio-console.h"
-
+#include "virtio-serial.h"
-typedef struct VirtIOConsole
-{
-VirtIODevice vdev;
-VirtQueue *ivq, *ovq;
+typedef struct VirtConsole {
+VirtIOSerialPort port;
CharDriverState *chr;
-} VirtIOConsole;
+} VirtConsole;
-static VirtIOConsole *to_virtio_console(VirtIODevice *vdev)
-{
-return (VirtIOConsole *)vdev;
-}
-static void virtio_console_handle_output(VirtIODevice *v
[Qemu-devel] [PATCH v9 1/3] qdev: add string property.
From: Gerd Hoffmann
Signed-off-by: Gerd Hoffmann
Signed-off-by: Amit Shah
---
hw/qdev-properties.c | 28
hw/qdev.h|4
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 5c627fa..8ca345a 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -193,6 +193,34 @@ PropertyInfo qdev_prop_hex64 = {
.print = print_hex64,
};
+/* --- string --- */
+
+static int parse_string(DeviceState *dev, Property *prop, const char *str)
+{
+char **ptr = qdev_get_prop_ptr(dev, prop);
+
+if (*ptr)
+qemu_free(*ptr);
+*ptr = qemu_strdup(str);
+return 0;
+}
+
+static int print_string(DeviceState *dev, Property *prop, char *dest, size_t
len)
+{
+char **ptr = qdev_get_prop_ptr(dev, prop);
+if (!*ptr)
+return snprintf(dest, len, "");
+return snprintf(dest, len, "\"%s\"", *ptr);
+}
+
+PropertyInfo qdev_prop_string = {
+.name = "string",
+.type = PROP_TYPE_STRING,
+.size = sizeof(char*),
+.parse = parse_string,
+.print = print_string,
+};
+
/* --- drive --- */
static int parse_drive(DeviceState *dev, Property *prop, const char *str)
diff --git a/hw/qdev.h b/hw/qdev.h
index 6d61b3a..b79f3e3 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -79,6 +79,7 @@ enum PropertyType {
PROP_TYPE_MACADDR,
PROP_TYPE_DRIVE,
PROP_TYPE_CHR,
+PROP_TYPE_STRING,
PROP_TYPE_PTR,
};
@@ -186,6 +187,7 @@ extern PropertyInfo qdev_prop_int32;
extern PropertyInfo qdev_prop_uint64;
extern PropertyInfo qdev_prop_hex32;
extern PropertyInfo qdev_prop_hex64;
+extern PropertyInfo qdev_prop_string;
extern PropertyInfo qdev_prop_chr;
extern PropertyInfo qdev_prop_ptr;
extern PropertyInfo qdev_prop_macaddr;
@@ -227,6 +229,8 @@ extern PropertyInfo qdev_prop_pci_devfn;
DEFINE_PROP(_n, _s, _f, qdev_prop_ptr, void*)
#define DEFINE_PROP_CHR(_n, _s, _f) \
DEFINE_PROP(_n, _s, _f, qdev_prop_chr, CharDriverState*)
+#define DEFINE_PROP_STRING(_n, _s, _f) \
+DEFINE_PROP(_n, _s, _f, qdev_prop_string, char*)
#define DEFINE_PROP_DRIVE(_n, _s, _f) \
DEFINE_PROP(_n, _s, _f, qdev_prop_drive, DriveInfo*)
#define DEFINE_PROP_MACADDR(_n, _s, _f) \
--
1.6.2.5
[Qemu-devel] [PATCH v9 0/3] virtio-console: Add support for multiple ports for generic guest-host communication
Hello, This patch series fixes a few problems since the last send, mainly in the save/restore code and a few bugs shown by the automated test suite (located in a separate git repo, link below). The automated test suite and a standalone interactive test program are located at http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git These patches are based on top of the char patches I've sent previously. Amit Shah (2): virtio-console: Add a virtio-serial bus, support for multiple ports virtio-console: Add a new virtserialport device for generic serial port support Gerd Hoffmann (1): qdev: add string property. Makefile.target|2 +- hw/pc.c|9 - hw/ppc440_bamboo.c |7 - hw/qdev-properties.c | 28 ++ hw/qdev.c |8 +- hw/qdev.h |4 + hw/virtio-console.c| 206 +++--- hw/virtio-console.h| 19 -- hw/virtio-pci.c|8 +- hw/virtio-serial-bus.c | 764 hw/virtio-serial.h | 227 ++ hw/virtio.h|2 +- qemu-options.hx|6 +- sysemu.h |6 - vl.c | 65 +++-- 15 files changed, 1182 insertions(+), 179 deletions(-) delete mode 100644 hw/virtio-console.h create mode 100644 hw/virtio-serial-bus.c create mode 100644 hw/virtio-serial.h
[Qemu-devel] [PATCH 4/4] char: emit the OPENED event only when a new char connection is opened
The OPENED event gets sent also when qemu resets its state initially.
The consumers of the event aren't interested in receiving this event
on reset.
Signed-off-by: Amit Shah
---
qemu-char.c |7 ++-
qemu-char.h |2 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 4757689..0fd402c 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -119,7 +119,12 @@ static void qemu_chr_event(CharDriverState *s, int event)
static void qemu_chr_reset_bh(void *opaque)
{
CharDriverState *s = opaque;
-qemu_chr_event(s, CHR_EVENT_OPENED);
+
+if (s->initial_reset_issued) {
+qemu_chr_event(s, CHR_EVENT_OPENED);
+} else {
+s->initial_reset_issued = true;
+}
qemu_bh_delete(s->bh);
s->bh = NULL;
}
diff --git a/qemu-char.h b/qemu-char.h
index 05fe15d..409961d 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -1,6 +1,7 @@
#ifndef QEMU_CHAR_H
#define QEMU_CHAR_H
+#include
#include "qemu-common.h"
#include "qemu-queue.h"
#include "qemu-option.h"
@@ -66,6 +67,7 @@ struct CharDriverState {
QEMUBH *bh;
char *label;
char *filename;
+bool initial_reset_issued;
QTAILQ_ENTRY(CharDriverState) next;
};
--
1.6.2.5
[Qemu-devel] [PATCH 3/4] console: call qemu_chr_reset() in text_console_init
text_console_init is called as the initialiser function for the 'vc' char backend. This function doesn't call qemu_chr_reset(), that emits the OPENED event. This fixes the help text and initial prompt display when the monitor is started in its default options -- as a vc backend to sdl or vnc. Signed-off-by: Amit Shah --- console.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/console.c b/console.c index 9bbef59..a4e0d64 100644 --- a/console.c +++ b/console.c @@ -1403,6 +1403,7 @@ CharDriverState *text_console_init(QemuOpts *opts) text_console_opts[n_text_consoles] = opts; n_text_consoles++; +qemu_chr_reset(chr); return chr; } -- 1.6.2.5
[Qemu-devel] [PATCH 2/4] char: rename CHR_EVENT_RESET to CHR_EVENT_OPENED
The char event RESET is emitted when a char device is opened.
Give it a better name.
Signed-off-by: Amit Shah
---
gdbstub.c |2 +-
hw/baum.c |2 +-
hw/usb-serial.c |2 +-
monitor.c |2 +-
qemu-char.c |2 +-
qemu-char.h |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 315f606..055093f 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -2447,7 +2447,7 @@ static void gdb_chr_receive(void *opaque, const uint8_t
*buf, int size)
static void gdb_chr_event(void *opaque, int event)
{
switch (event) {
-case CHR_EVENT_RESET:
+case CHR_EVENT_OPENED:
vm_stop(EXCP_INTERRUPT);
gdb_has_xml = 0;
break;
diff --git a/hw/baum.c b/hw/baum.c
index 665deab..c66e737 100644
--- a/hw/baum.c
+++ b/hw/baum.c
@@ -475,7 +475,7 @@ static void baum_send_event(CharDriverState *chr, int event)
switch (event) {
case CHR_EVENT_BREAK:
break;
-case CHR_EVENT_RESET:
+case CHR_EVENT_OPENED:
/* Reset state */
baum->in_buf_used = 0;
break;
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index e2379c4..d02f6b2 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -516,7 +516,7 @@ static void usb_serial_event(void *opaque, int event)
break;
case CHR_EVENT_FOCUS:
break;
-case CHR_EVENT_RESET:
+case CHR_EVENT_OPENED:
usb_serial_reset(s);
/* TODO: Reset USB port */
break;
diff --git a/monitor.c b/monitor.c
index 3424e60..2566f4a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -3470,7 +3470,7 @@ static void monitor_event(void *opaque, int event)
mon->mux_out = 1;
break;
-case CHR_EVENT_RESET:
+case CHR_EVENT_OPENED:
monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
"information\n", QEMU_VERSION);
if (!mon->mux_out) {
diff --git a/qemu-char.c b/qemu-char.c
index 8f7f81c..4757689 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -119,7 +119,7 @@ static void qemu_chr_event(CharDriverState *s, int event)
static void qemu_chr_reset_bh(void *opaque)
{
CharDriverState *s = opaque;
-qemu_chr_event(s, CHR_EVENT_RESET);
+qemu_chr_event(s, CHR_EVENT_OPENED);
qemu_bh_delete(s->bh);
s->bh = NULL;
}
diff --git a/qemu-char.h b/qemu-char.h
index c0654bc..05fe15d 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -10,7 +10,7 @@
#define CHR_EVENT_BREAK 0 /* serial break char */
#define CHR_EVENT_FOCUS 1 /* focus to this terminal (modal input needed) */
-#define CHR_EVENT_RESET 2 /* new connection established */
+#define CHR_EVENT_OPENED 2 /* new connection established */
#define CHR_EVENT_MUX_IN 3 /* mux-focus was set to this terminal */
#define CHR_EVENT_MUX_OUT 4 /* mux-focus will move on */
#define CHR_EVENT_CLOSED 5 /* connection closed */
--
1.6.2.5
[Qemu-devel] [PATCH 1/4] char: check for initial_reset_issued unnecessary
At init, qemu_chr_reset is always called with initial_reset_issued set to 1.
So checking for it to be set is not necessary.
Signed-off-by: Amit Shah
---
qemu-char.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 8084a67..8f7f81c 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -108,7 +108,6 @@
static QTAILQ_HEAD(CharDriverStateHead, CharDriverState) chardevs =
QTAILQ_HEAD_INITIALIZER(chardevs);
-static int initial_reset_issued;
static void qemu_chr_event(CharDriverState *s, int event)
{
@@ -127,7 +126,7 @@ static void qemu_chr_reset_bh(void *opaque)
void qemu_chr_reset(CharDriverState *s)
{
-if (s->bh == NULL && initial_reset_issued) {
+if (s->bh == NULL) {
s->bh = qemu_bh_new(qemu_chr_reset_bh, s);
qemu_bh_schedule(s->bh);
}
@@ -137,8 +136,6 @@ void qemu_chr_initial_reset(void)
{
CharDriverState *chr;
-initial_reset_issued = 1;
-
QTAILQ_FOREACH(chr, &chardevs, next) {
qemu_chr_reset(chr);
}
--
1.6.2.5
[Qemu-devel] [PATCH 0/4] Resend: Fixes for the qemu char layer
Hello, These are fixes for qemu's char layer. All of the patches have been sent earlier, this is just a resend with the fix for console char devs included in the series that was sent separately earlier. Amit Shah (4): char: check for initial_reset_issued unnecessary char: rename CHR_EVENT_RESET to CHR_EVENT_OPENED console: call qemu_chr_reset() in text_console_init char: emit the OPENED event only when a new char connection is opened console.c |1 + gdbstub.c |2 +- hw/baum.c |2 +- hw/usb-serial.c |2 +- monitor.c |2 +- qemu-char.c | 12 +++- qemu-char.h |4 +++- 7 files changed, 15 insertions(+), 10 deletions(-)
