Re: [kvm-devel] DOR : Example for injecting the interrupt to the guest
>> Actually we're in the middle of developing pci pass through support >> for enabling physical device pass through for guests. It's work in >> progress but eventually we'll post the code to the list. > >Cool. Are you relying on an isolation-capable IOMMU or using the >Neocleus approach? Actually we'll do both. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FW: RE: DOR : Example for injecting the interrupt to the guest
>> Hello Dor, >> >> Thank you so much for the quick reply. >> >> My project is to run a qnx4.4 legacy application (which talks >> to custom made hardware) on virtualized environment. I am >> using KVM for that and am able to read and write to the actual >> hardware. I used serial driver in qemu as a reference to >> develop my custom virtual driver. Let me know what specific >> details you want to know. >> >> I know fairly well to trap the interrupt in the host side >> (linux). What I would require is some example on how to modify >> the qemu part of the code, so that it the qemu set the flag > >Let Qemu set the flag is not that stright forward, it will impact the >performance dramatically. In kernel irqchip will help u on this, but the >foundmental >stuff to support either VT-d or directly hardware pass thru is still >under going. >So you probably have to wait for this :-( While its not trivial it's still doable even without VT-d. If the device has no shared irq line with high-irq-rate physical device there won't be bug performance penalty. > >BTW, is this hardware shared among different VMs or dedicate to each VM? Each physical device is dedicated to specific VM, although theoretically if you have virtualization support in the device like NetXen it can work too. >> and ack the interrupt from the host side. Any example about it >> will be highly appreciated. >> >> Thanks once again for your response >> >> Regards >> Aji >> >> >Thx, eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] DOR : Example for injecting the interrupt to the guest
On Wed, Aug 08, 2007 at 12:03:03AM -0700, Dor Laor wrote: > Actually we'll do both. Doubly cool. Looking forward to more information. Cheers, Muli - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] migration with exec giving truncated images
I've never encountered that problem. I haven't used "exec" migration protocol too many times though. I have not used libvirt too many times either. I'll look into it too. Thanks, Uri. Jim Paris wrote: > I wrote: > >> It's almost as if migrate_write() is being called after >> migrate_finish() ?? >> > > Yes, I'm definitely seeing this -- migrate_finish followed by > migrate_write, which causes a segfault (and explains my truncated > images). Unfortunately I'm not at all familiar with this code, and > all the qemu I/O handler stuff is still confusing to me. Does anyone > with some experience in this area have some time to help track this > down? > > -jim > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1769884 ] Fails to boot linux guest with 2.6.22 kernel
Bugs item #1769884, was opened at 2007-08-08 17:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1769884&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to boot linux guest with 2.6.22 kernel Initial Comment: I cannot boot linux guest with 2.6.22 kernel. The guest crashed while booting kernel. The screen snapshot is attached. Some error messages in host dmesg: >kvm: 9511: cpu0 unhandled wrmsr: 0xc1 >kvm: 9612: cpu0 unhandled wrmsr: 0xc1 >kvm: 9654: cpu0 unhandled wrmsr: 0xc1 But if i add nolapic to the guest kernel, the guest could be booted up without any problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1769884&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] MSR virtualization
Avi: We (Yunfeng) encountered some warning from KVM in certain situation like: "kvm: 9612: cpu0 unhandled wrmsr: 0xc1" Further check find that we are doing MSR write virtualization per a predefined whitelist and give gp fault for others. On the other hand, Xen just silently return (no gp fault). We may not implement policy for all MSRs, but not sure if injecting gp fault for them will cause problem. Any comments? thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] ABAT Testing report, kernel 3415130f97.., userspace 5b16d32e..
A new issue has been found: Fails to boot linux guests with 2.6.22 kernel https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1769884&group_id=180599 >-Original Message- >From: Zhao, Yunfeng >Sent: 2007年8月6日 15:45 >To: 'kvm-devel@lists.sourceforge.net' >Cc: Zhao, Yunfeng >Subject: ABAT Testing report, kernel 3415130f97.., userspace 5b16d32e.. > >Hi, all, > >This is today's ABAT testing result against kvm.git >3415130f97a18f354853cab694d392553aa51af8 and kvm-userspace.git >5b16d32e3785274310e9e1970f4221b4966c5474. > >Two old issues have been fixed. > >1. 64bit host crashed when boot SMP linux guest >https://sourceforge.net/tracker/index.php?func=detail&aid=1766613&group_id= >180599&atid=893831 >2. Cannot build kvm as external modules. > >One new issue: >1. The speed of booting windows guest is very slow, top shows the cpu usage of >qemu is always >100% while booting windows guest. >https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1768187&group_ >id=180599 > >Issue list > >1. Could not create kvm guest with memory >=2040 >https://sourceforge.net/tracker/index.php?func=detail&aid=1736307&group_id= >180599&atid=893831 >2. Create multiple guests simultaneously or create one guest many times may >fail >https://sourceforge.net/tracker/index.php?func=detail&aid=1741312&group_id= >180599&atid=893831 >3. Can not boot IA32e RHEL 4u3 guest with -no-acpi >https://sourceforge.net/tracker/index.php?func=detail&aid=1741314&group_id= >180599&atid=893831 >4. Can not boot 64 bit windows >https://sourceforge.net/tracker/index.php?func=detail&aid=1741318&group_id= >180599&atid=893831 >5. Some ltp test cases fail >https://sourceforge.net/tracker/index.php?func=detail&aid=1741316&group_id= >180599&atid=893831 >6. The speed of booting windows guest is very slow >https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1768187&group_ >id=180599 > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] cleanup struct kvm_vcpu control registers
The patch below removes individual control register definitions from
struct kvm_vcpu and replaces them with an array similar to general
purpose registers.
When splitting kvm_vcpu in architecture dependent and architecture
independent parts, this will allow to keep the control registers in the
architecture independent struct even if we have different control
registers on different architectures.
This is tested on svm, unfortunately I don't have a vmx capable machine
at hand.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 70231f3..21240de 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -196,6 +196,15 @@ enum {
};
enum {
+ VCPU_CREGS_CR0 = 0,
+ VCPU_CREGS_CR2 = 1,
+ VCPU_CREGS_CR3 = 2,
+ VCPU_CREGS_CR4 = 3,
+ VCPU_CREGS_CR8 = 4,
+ NR_VCPU_CREGS
+};
+
+enum {
VCPU_SREG_CS,
VCPU_SREG_DS,
VCPU_SREG_ES,
@@ -311,16 +320,12 @@ struct kvm_vcpu {
unsigned long irq_summary; /* bit vector: 1 per word in irq_pending */
DECLARE_BITMAP(irq_pending, KVM_NR_INTERRUPTS);
unsigned long regs[NR_VCPU_REGS]; /* for rsp: vcpu_load_rsp_rip() */
+ unsigned long cregs[NR_VCPU_CREGS];
unsigned long rip; /* needs vcpu_load_rsp_rip() */
- unsigned long cr0;
- unsigned long cr2;
- unsigned long cr3;
gpa_t para_state_gpa;
struct page *para_state_page;
gpa_t hypercall_gpa;
- unsigned long cr4;
- unsigned long cr8;
u64 pdptrs[4]; /* pae */
u64 shadow_efer;
u64 apic_base;
@@ -616,17 +621,17 @@ static inline int is_long_mode(struct kvm_vcpu *vcpu)
static inline int is_pae(struct kvm_vcpu *vcpu)
{
- return vcpu->cr4 & X86_CR4_PAE;
+ return vcpu->cregs[VCPU_CREGS_CR4] & X86_CR4_PAE;
}
static inline int is_pse(struct kvm_vcpu *vcpu)
{
- return vcpu->cr4 & X86_CR4_PSE;
+ return vcpu->cregs[VCPU_CREGS_CR4] & X86_CR4_PSE;
}
static inline int is_paging(struct kvm_vcpu *vcpu)
{
- return vcpu->cr0 & X86_CR0_PG;
+ return vcpu->cregs[VCPU_CREGS_CR0] & X86_CR0_PG;
}
static inline int memslot_id(struct kvm *kvm, struct kvm_memory_slot *slot)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index f7ff231..993c7d6 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -439,7 +439,7 @@ void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
{
if (cr0 & CR0_RESERVED_BITS) {
printk(KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n",
- cr0, vcpu->cr0);
+ cr0, vcpu->cregs[VCPU_CREGS_CR0]);
inject_gp(vcpu);
return;
}
@@ -478,7 +478,7 @@ void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
}
} else
#endif
- if (is_pae(vcpu) && !load_pdptrs(vcpu, vcpu->cr3)) {
+ if (is_pae(vcpu) && !load_pdptrs(vcpu,
vcpu->cregs[VCPU_CREGS_CR3])) {
printk(KERN_DEBUG "set_cr0: #GP, pdptrs "
"reserved bits\n");
inject_gp(vcpu);
@@ -488,7 +488,7 @@ void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
}
kvm_arch_ops->set_cr0(vcpu, cr0);
- vcpu->cr0 = cr0;
+ vcpu->cregs[VCPU_CREGS_CR0] = cr0;
mutex_lock(&vcpu->kvm->lock);
kvm_mmu_reset_context(vcpu);
@@ -499,7 +499,7 @@ EXPORT_SYMBOL_GPL(set_cr0);
void lmsw(struct kvm_vcpu *vcpu, unsigned long msw)
{
- set_cr0(vcpu, (vcpu->cr0 & ~0x0ful) | (msw & 0x0f));
+ set_cr0(vcpu, (vcpu->cregs[VCPU_CREGS_CR0] & ~0x0ful) | (msw & 0x0f));
}
EXPORT_SYMBOL_GPL(lmsw);
@@ -519,7 +519,7 @@ void set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
return;
}
} else if (is_paging(vcpu) && !is_pae(vcpu) && (cr4 & X86_CR4_PAE)
- && !load_pdptrs(vcpu, vcpu->cr3)) {
+ && !load_pdptrs(vcpu, vcpu->cregs[VCPU_CREGS_CR3])) {
printk(KERN_DEBUG "set_cr4: #GP, pdptrs reserved bits\n");
inject_gp(vcpu);
return;
@@ -582,7 +582,7 @@ void set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
if (unlikely(!gfn_to_memslot(vcpu->kvm, cr3 >> PAGE_SHIFT)))
inject_gp(vcpu);
else {
- vcpu->cr3 = cr3;
+ vcpu->cregs[VCPU_CREGS_CR3] = cr3;
vcpu->mmu.new_cr3(vcpu);
}
mutex_unlock(&vcpu->kvm->lock);
@@ -596,7 +596,7 @@ void set_cr8(struct kvm_vcpu *vcpu, unsigned long cr8)
inject_gp(vcpu);
return;
}
- vcpu->cr8 = cr8;
+ vcpu->cregs[VCPU_CREGS_CR8] = cr8;
}
EXPORT_SYMBOL_GPL(set_cr8);
@@ -1123,7 +1123,7 @@ int emulate_clts(struct kvm_vcpu *vcpu)
{
unsigned long cr0;
- cr0 = vcpu->cr0 & ~X86_CR0_TS;
+ cr0 = vcpu->cregs[VCPU_CREGS_CR0] & ~X
Re: [kvm-devel] MSR virtualization
Dong, Eddie wrote: > Avi: > We (Yunfeng) encountered some warning from KVM in certain > situation like: > "kvm: 9612: cpu0 unhandled wrmsr: 0xc1" > Further check find that we are doing MSR write virtualization > per a predefined whitelist and give gp fault for others. On the other > hand, Xen just silently return (no gp fault). We may not implement > policy for all MSRs, but not sure if injecting gp fault for them will > cause problem. > Silently returning is IMO problematic. If a guest depends on the correct behavior of some msr, and we mis-emulate it by ignoring it, then we get a guest failure with no message in the kernel to point us in the right direction. In the case of 0xc1, this is the performance counter, likely used for the nmi watchdog. If we ignore it, the guest kernel will just report a soft lockup and hang. So there are only two realistic options left: - printk() and ignore - that is a mis-emulation of writes to msrs that are supposed to #gp - printk() and #gp - that is a mis-emulation of writes to msrs that must be handled. But there are fewer of these than msrs that need to #gp. So I think the current behavior is best. Unhandled msrs are rare, we just need to implement them when they happen. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] cleanup struct kvm_vcpu control registers
Carsten Otte wrote: > The patch below removes individual control register definitions from > struct kvm_vcpu and replaces them with an array similar to general > purpose registers. > When splitting kvm_vcpu in architecture dependent and architecture > independent parts, this will allow to keep the control registers in the > architecture independent struct even if we have different control > registers on different architectures. > This is tested on svm, unfortunately I don't have a vmx capable machine > at hand. > I don't think we should aim for keeping control registers in an arch independent manner, since there is nothing common among the different architectures in that area. For x86, keeping them in an array is not helpful since the individual control registers have nothing to do with each other. Also, for most things like the fpu and segment registers this trick won't work. I suggest keeping them in an arch dependent structure (struct kvm_vcpu_arch) in . We can then access them through a member as vcpu->arch.cr0, etc. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] cleanup struct kvm_vcpu control registers
Avi Kivity wrote: > I don't think we should aim for keeping control registers in an arch > independent manner, since there is nothing common among the different > architectures in that area. For x86, keeping them in an array is not > helpful since the individual control registers have nothing to do with > each other. Also, for most things like the fpu and segment registers > this trick won't work. > > I suggest keeping them in an arch dependent structure (struct > kvm_vcpu_arch) in . We can then access them through a member > as vcpu->arch.cr0, etc. Fine with me, I gonna patch that direction. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Storing command line options in qcow2 images
Avi Kivity wrote: > Anthony Liguori wrote: > >> I don't think adding annotations as snapshots is the right approach. I >> think proper support should be added in the header. I wouldn't be too >> concerned with breaking compatibility in qcow2. That's why it's qcow2 >> and not just an updated version of qcow, qcow2 is still, AFAIK, open for >> breakage. >> >> > > Are all the users' images open for breakage too? > FWIW, you can extended the header without causing a breakage. Just bump the version, add the field, and add appropriate code. Of course, this is technically qcow v3 but it's a good opportunity to make things a bit sanier such that instead of check version == QCOW_VERSION that version >= QCOW_VERSION. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Storing command line options in qcow2 images
On 8/8/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: > Avi Kivity wrote: > > Anthony Liguori wrote: > > > >> I don't think adding annotations as snapshots is the right approach. I > >> think proper support should be added in the header. I wouldn't be too > >> concerned with breaking compatibility in qcow2. That's why it's qcow2 > >> and not just an updated version of qcow, qcow2 is still, AFAIK, open for > >> breakage. > >> > >> > > > > Are all the users' images open for breakage too? > > > > FWIW, you can extended the header without causing a breakage. Just bump > the version, add the field, and add appropriate code. Of course, this > is technically qcow v3 but it's a good opportunity to make things a bit > sanier such that instead of check version == QCOW_VERSION that version > >= QCOW_VERSION. I think that for now we can try the snapshot-based approach, as it is the least intrusive one. I wouldn't push for a format change just with this minor feature. However, I would be glad to convert our code if the general consensus was that we need a new format. Patches for our solution follow. They are against: 5b16d32e3785274310e9e1970f4221b4966c5474 Which was userspace a few minutes ago. Cheers, Jorge - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/4][RFC] Allow storing arbitrary annotations in qcow2 images
This patch adds an extra 'annot' field to qcow2 snapshots, and updates
serialization functions.
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/block-qcow2.c b/qemu/block-qcow2.c
index 0f7a069..361d300 100644
--- a/qemu/block-qcow2.c
+++ b/qemu/block-qcow2.c
@@ -106,6 +106,8 @@ typedef struct QCowSnapshot {
uint32_t l1_size;
char *id_str;
char *name;
+char *annot;
+
uint32_t vm_state_size;
uint32_t date_sec;
uint32_t date_nsec;
@@ -1370,6 +1372,7 @@ static void qcow_free_snapshots(BlockDriverState *bs)
for(i = 0; i < s->nb_snapshots; i++) {
qemu_free(s->snapshots[i].name);
qemu_free(s->snapshots[i].id_str);
+qemu_free(s->snapshots[i].annot);
}
qemu_free(s->snapshots);
s->snapshots = NULL;
@@ -1401,12 +1404,18 @@ static int qcow_read_snapshots(BlockDriverState *bs)
sn->date_sec = be32_to_cpu(h.date_sec);
sn->date_nsec = be32_to_cpu(h.date_nsec);
sn->vm_clock_nsec = be64_to_cpu(h.vm_clock_nsec);
-extra_data_size = be32_to_cpu(h.extra_data_size);
+extra_data_size = be32_to_cpu(h.extra_data_size);
id_str_size = be16_to_cpu(h.id_str_size);
name_size = be16_to_cpu(h.name_size);
+sn->annot = qemu_malloc(extra_data_size + 1);
+if (!sn->annot)
+goto fail;
+if (bdrv_pread(s->hd, offset, sn->annot, extra_data_size) !=
extra_data_size)
+goto fail;
offset += extra_data_size;
+sn->annot[extra_data_size] = '\0';
sn->id_str = qemu_malloc(id_str_size + 1);
if (!sn->id_str)
@@ -1439,7 +1448,7 @@ static int qcow_write_snapshots(BlockDriverState *bs)
QCowSnapshotHeader h;
int i, name_size, id_str_size, snapshots_size;
uint64_t data64;
-uint32_t data32;
+uint32_t data32, extra_data_size;
int64_t offset, snapshots_offset;
/* compute the size of the snapshots */
@@ -1448,6 +1457,7 @@ static int qcow_write_snapshots(BlockDriverState *bs)
sn = s->snapshots + i;
offset = align_offset(offset, 8);
offset += sizeof(h);
+offset += strlen(sn->annot);
offset += strlen(sn->id_str);
offset += strlen(sn->name);
}
@@ -1455,7 +1465,7 @@ static int qcow_write_snapshots(BlockDriverState *bs)
snapshots_offset = alloc_clusters(bs, snapshots_size);
offset = snapshots_offset;
-
+
for(i = 0; i < s->nb_snapshots; i++) {
sn = s->snapshots + i;
memset(&h, 0, sizeof(h));
@@ -1465,7 +1475,9 @@ static int qcow_write_snapshots(BlockDriverState *bs)
h.date_sec = cpu_to_be32(sn->date_sec);
h.date_nsec = cpu_to_be32(sn->date_nsec);
h.vm_clock_nsec = cpu_to_be64(sn->vm_clock_nsec);
-
+
+extra_data_size = strlen(sn->annot);
+h.extra_data_size = cpu_to_be32(extra_data_size);
id_str_size = strlen(sn->id_str);
name_size = strlen(sn->name);
h.id_str_size = cpu_to_be16(id_str_size);
@@ -1474,6 +1486,9 @@ static int qcow_write_snapshots(BlockDriverState *bs)
if (bdrv_pwrite(s->hd, offset, &h, sizeof(h)) != sizeof(h))
goto fail;
offset += sizeof(h);
+if (bdrv_pwrite(s->hd, offset, sn->annot, extra_data_size) !=
extra_data_size)
+goto fail;
+offset += extra_data_size;
if (bdrv_pwrite(s->hd, offset, sn->id_str, id_str_size) != id_str_size)
goto fail;
offset += id_str_size;
@@ -1570,6 +1585,10 @@ static int qcow_snapshot_create(BlockDriverState *bs,
sn->name = qemu_strdup(sn_info->name);
if (!sn->name)
goto fail;
+sn->annot = qemu_strdup(sn_info->annot);
+if (!sn->annot)
+goto fail;
+
sn->vm_state_size = sn_info->vm_state_size;
sn->date_sec = sn_info->date_sec;
sn->date_nsec = sn_info->date_nsec;
@@ -1680,6 +1699,8 @@ static int qcow_snapshot_delete(BlockDriverState
*bs, const char *snapshot_id)
qemu_free(sn->id_str);
qemu_free(sn->name);
+qemu_free(sn->annot);
+
memmove(sn, sn + 1, (s->nb_snapshots - snapshot_index - 1) * sizeof(*sn));
s->nb_snapshots--;
ret = qcow_write_snapshots(bs);
@@ -1707,10 +1728,14 @@ static int qcow_snapshot_list(BlockDriverState *bs,
for(i = 0; i < s->nb_snapshots; i++) {
sn_info = sn_tab + i;
sn = s->snapshots + i;
+
pstrcpy(sn_info->id_str, sizeof(sn_info->id_str),
sn->id_str);
pstrcpy(sn_info->name, sizeof(sn_info->name),
sn->name);
+pstrcpy(sn_info->annot, sizeof(sn_info->annot),
+sn->annot);
+
sn_info->vm_state_size = sn->vm_state_size;
sn_info->date_sec = sn->date_sec;
sn_info->date_nsec = sn->date_nsec;
diff --git a/qemu/vl.h b/qemu/vl.h
index 43f56bd..f0273fd 100644
--- a/qemu/vl.h
+++ b/qemu/vl.h
@@ -589,6 +589,7 @@ typedef struct QEMUSnapshotInfo {
/* the following fields are informative. They
[kvm-devel] [PATCH 2/4][RFC] Add functions to manipulate image annotations
This patch adds block driver functions to use qcow2 image annotations.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/block.c b/qemu/block.c
index 39ec37a..4d794f6 100644
--- a/qemu/block.c
+++ b/qemu/block.c
@@ -56,6 +56,8 @@ static int bdrv_write_em(BlockDriverState *bs,
int64_t sector_num,
static BlockDriverState *bdrv_first;
static BlockDriver *first_drv;
+static char *filter_name(char *name);
+
int path_is_absolute(const char *path)
{
const char *p;
@@ -1037,6 +1039,8 @@ char *bdrv_snapshot_dump(char *buf, int
buf_size, QEMUSnapshotInfo *sn)
snprintf(buf, buf_size,
"%-10s%-20s%7s%20s%15s",
"ID", "TAG", "VM SIZE", "DATE", "VM CLOCK");
+} else if (bdrv_snapshot_annotated(sn)) {
+snprintf(buf, buf_size, "%s: '%s'", filter_name(sn->name), sn->annot);
} else {
ti = sn->date_sec;
#ifdef _WIN32
@@ -1361,3 +1365,128 @@ void bdrv_set_locked(BlockDriverState *bs, int locked)
drv->bdrv_set_locked(bs, locked);
}
}
+
+/**/
+/* image annotation support */
+
+static char *prepare_name(const char *name)
+{
+char *res = malloc(1024 * sizeof(char));
+
+res[0] = '\n';
+return strncat(res, name, 1022);
+}
+
+static char *filter_name(char *name)
+{
+return strtok(name, "\n");
+}
+
+int bdrv_snapshot_annotated(QEMUSnapshotInfo *sn)
+{
+ return (sn->name[0] == '\n' &&
+ sn->vm_state_size == 0 &&
+ *sn->annot != '\0');
+}
+
+int bdrv_set_annot(BlockDriverState *bs,
+ const char *name,
+ const char *annotation)
+{
+int nbsnaps, i;
+int ret = 0;
+
+char *fltname;
+char *prepname;
+char *id_annot = NULL;
+
+QEMUSnapshotInfo *sn_info;
+BlockDriver *drv = bs->drv;
+
+nbsnaps = drv->bdrv_snapshot_list(bs, &sn_info);
+
+if (nbsnaps < 0) {
+ret = -1;
+goto end;
+}
+
+for (i = 0; i < nbsnaps; i++) {
+fltname = filter_name(sn_info[i].name);
+
+if (sn_info[i].name[0] == '\n' &&
+!strcmp(fltname, name) &&
+sn_info[i].vm_state_size == 0) {
+
+id_annot = sn_info[i].id_str;
+break;
+}
+}
+
+if (id_annot != NULL)
+drv->bdrv_snapshot_delete(bs, id_annot);
+
+if (strlen(annotation) == 0)
+goto end;
+
+QEMUSnapshotInfo *new_sn_info = qemu_malloc(sizeof(QEMUSnapshotInfo));
+
+if (!new_sn_info) {
+ret = -ENOMEM;
+goto end;
+}
+
+prepname = prepare_name(name);
+
+// No id, set by create
+new_sn_info->id_str[0] = '\0';
+pstrcpy(new_sn_info->name, 1024, prepname);
+pstrcpy(new_sn_info->annot, 1024, annotation);
+
+new_sn_info->vm_state_size = new_sn_info->date_sec =
+new_sn_info->date_nsec = new_sn_info->vm_clock_nsec = 0;
+
+if (drv->bdrv_snapshot_create(bs, new_sn_info) < 0)
+ret = -1;
+
+free(prepname);
+free(new_sn_info);
+
+end:
+free(sn_info);
+return ret;
+}
+
+char *bdrv_get_annot(BlockDriverState *bs, const char *name)
+{
+int nbsnaps, i;
+char *filteredn;
+char *res;
+
+QEMUSnapshotInfo *sn_info = NULL;
+
+res = malloc(1024 * sizeof(char));
+if (!res)
+return NULL;
+
+nbsnaps = bs->drv->bdrv_snapshot_list(bs, &sn_info);
+
+if (nbsnaps < 0) {
+free(sn_info);
+free(res);
+return NULL;
+}
+
+for (i = 0; i < nbsnaps; i++) {
+filteredn = filter_name(sn_info[i].name);
+
+if (sn_info[i].name[0] == '\n' &&
+!strcmp(filteredn, name) &&
+sn_info[i].vm_state_size == 0) {
+
+pstrcpy(res, 1024, sn_info[i].annot);
+break;
+}
+}
+
+return res;
+}
This patch adds block driver functions to use qcow2 image annotations.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/block.c b/qemu/block.c
index 39ec37a..4d794f6 100644
--- a/qemu/block.c
+++ b/qemu/block.c
@@ -56,6 +56,8 @@ static int bdrv_write_em(BlockDriverState *bs, int64_t sector_num,
static BlockDriverState *bdrv_first;
static BlockDriver *first_drv;
+static char *filter_name(char *name);
+
int path_is_absolute(const char *path)
{
const char *p;
@@ -1037,6 +1039,8 @@ char *bdrv_snapshot_dump(char *buf, int buf_size, QEMUSnapshotInfo *sn)
snprintf(buf, buf_size,
"%-10s%-20s%7s%20s%15s",
"ID", "TAG", "VM SIZE", "DATE", "VM CLOCK");
+} else if (bdrv_snapshot_annotated(sn)) {
+snprintf(buf, buf_size, "%s: '%s'", filter_name(sn->name), sn->annot);
} else {
ti = sn->date_sec;
#ifdef _WIN32
@@ -1361,3 +1365,128 @@ void bdrv_set_locked(BlockDriverState *bs, int locked)
drv->bdrv_set_locked(bs, locked);
}
}
+
+/*
[kvm-devel] [PATCH 3/4][RFC] Add qemu-img option to store command line options into qcow2 images
This patch adds a new qemu-img option to store
command line arguments in qcow2 snapshots.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/qemu-img.c b/qemu/qemu-img.c
index a259546..afa1fcc 100644
--- a/qemu/qemu-img.c
+++ b/qemu/qemu-img.c
@@ -98,6 +98,7 @@ void help(void)
"QEMU disk image utility\n"
"\n"
"Command syntax:\n"
+ " cmdline filename \"command_line\" (qcow2 format only)\n"
" create [-e] [-b base_image] [-f fmt] filename [size]\n"
" commit [-f fmt] filename\n"
" convert [-c] [-e] [-f fmt] filename [-O output_fmt]
output_filename\n"
@@ -105,6 +106,8 @@ void help(void)
"\n"
"Command parameters:\n"
" 'filename' is a disk image filename\n"
+ " 'command_line' is a list of command line options to be
stored in the image,\n"
+ "an empty string clears the stored command line options\n"
" 'base_image' is the read-only disk image which is used
as base for a copy on\n"
"write image; the copy on write image only stores the
modified data\n"
" 'fmt' is the disk image format. It is guessed
automatically in most cases\n"
@@ -317,6 +320,33 @@ static int img_create(int argc, char **argv)
return 0;
}
+static int img_cmdline(int argc, char **argv)
+{
+char *filename;
+char *annotation;
+
+BlockDriverState *bs;
+
+char *aname = "commandline_args";
+
+if (argc != 4)
+help();
+
+filename = argv[2];
+annotation = argv[3];
+
+bs = bdrv_new_open(filename, "qcow2");
+if (!bs)
+error("Could not open qcow2 image '%s'", filename);
+
+if (bdrv_set_annot(bs, aname, (const char *)annotation) < 0) {
+error("Could not store command line options into '%s'", filename);
+}
+
+bdrv_delete(bs);
+return 0;
+}
+
static int img_commit(int argc, char **argv)
{
int c, ret;
@@ -577,11 +607,19 @@ static void dump_snapshots(BlockDriverState *bs)
nb_sns = bdrv_snapshot_list(bs, &sn_tab);
if (nb_sns <= 0)
return;
-printf("Snapshot list:\n");
+
+printf("\nAnnotations:\n");
+for (i = 0; i < nb_sns; i++) {
+sn = &sn_tab[i];
+if (bdrv_snapshot_annotated(sn))
+printf("%s\n", bdrv_snapshot_dump(buf, sizeof(buf), sn));
+}
+printf("\nSnapshot list:\n");
printf("%s\n", bdrv_snapshot_dump(buf, sizeof(buf), NULL));
for(i = 0; i < nb_sns; i++) {
sn = &sn_tab[i];
-printf("%s\n", bdrv_snapshot_dump(buf, sizeof(buf), sn));
+if (!bdrv_snapshot_annotated(sn))
+printf("%s\n", bdrv_snapshot_dump(buf, sizeof(buf), sn));
}
qemu_free(sn_tab);
}
@@ -673,7 +711,9 @@ int main(int argc, char **argv)
help();
cmd = argv[1];
optind++;
-if (!strcmp(cmd, "create")) {
+if (!strcmp(cmd, "cmdline")) {
+ img_cmdline(argc, argv);
+} else if (!strcmp(cmd, "create")) {
img_create(argc, argv);
} else if (!strcmp(cmd, "commit")) {
img_commit(argc, argv);
This patch adds a new qemu-img option to store
command line arguments in qcow2 snapshots.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/qemu-img.c b/qemu/qemu-img.c
index a259546..afa1fcc 100644
--- a/qemu/qemu-img.c
+++ b/qemu/qemu-img.c
@@ -98,6 +98,7 @@ void help(void)
"QEMU disk image utility\n"
"\n"
"Command syntax:\n"
+ " cmdline filename \"command_line\" (qcow2 format only)\n"
" create [-e] [-b base_image] [-f fmt] filename [size]\n"
" commit [-f fmt] filename\n"
" convert [-c] [-e] [-f fmt] filename [-O output_fmt] output_filename\n"
@@ -105,6 +106,8 @@ void help(void)
"\n"
"Command parameters:\n"
" 'filename' is a disk image filename\n"
+ " 'command_line' is a list of command line options to be stored in the image,\n"
+ "an empty string clears the stored command line options\n"
" 'base_image' is the read-only disk image which is used as base for a copy on\n"
"write image; the copy on write image only stores the modified data\n"
" 'fmt' is the disk image format. It is guessed automatically in most cases\n"
@@ -317,6 +320,33 @@ static int img_create(int argc, char **argv)
return 0;
}
+static int img_cmdline(int argc, char **argv)
+{
+char *filename;
+char *annotation;
+
+BlockDriverState *bs;
+
+char *aname = "commandline_args";
+
+if (argc != 4)
+help();
+
+filename = argv[2];
+annotation = argv[3];
+
+bs = bdrv_new_open(filename, "qcow2");
+if (!bs)
+error("Could not open qcow2 image '%s'", filename);
+
+if (bdrv_set_annot(bs, aname, (const char *)annotation
[kvm-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
This patch makes QEMU check for command line options stored in qcow2 images.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/vl.c b/qemu/vl.c
index 4ad39f1..1d28794 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -184,6 +184,11 @@ int time_drift_fix = 0;
const char *cpu_vendor_string;
/***/
+/* Image annotation support */
+
+char *img_get_annot(char *filename);
+
+/***/
/* x86 ISA bus support */
target_phys_addr_t isa_mem_base = 0;
@@ -6917,6 +6922,13 @@ int main(int argc, char **argv)
char usb_devices[MAX_USB_CMDLINE][128];
int usb_devices_index;
int fds[2];
+char *tmpannot;
+char annot[1024];
+int done = 0;
+unsigned int nbtoks = 0;
+char *tok;
+BlockDriver *drv;
+BlockDriverState *bs;
saved_argc = argc;
saved_argv = argv;
@@ -7000,6 +7012,58 @@ int main(int argc, char **argv)
nb_nics = 0;
/* default mac address of the first network interface */
+bdrv_init();
+
+drv = bdrv_find_format("qcow2");
+
+if (argc > 1 && argv[1][0] != '-') {
+bs = bdrv_new("");
+if (!bs) {
+fprintf(stderr, "Not enough memory");
+exit(1);
+}
+if (bdrv_open2(bs, argv[1], 0, drv) < 0) {
+fprintf(stderr, "Could not open '%s'", argv[1]);
+bdrv_delete(bs);
+exit(1);
+}
+
+tmpannot = bdrv_get_annot(bs, "commandline_args");
+if (tmpannot) {
+pstrcpy(annot, 1024, tmpannot);
+
+do {
+tok = strtok(nbtoks == 0? tmpannot : NULL, " ");
+
+if (tok != NULL)
+nbtoks++;
+else
+done = 1;
+} while (!done);
+
+free(tmpannot);
+
+if (nbtoks > 0) {
+char **argvprime = malloc((nbtoks + argc) * sizeof(char*));
+
+for (i = 0; i < argc; i++)
+argvprime[i] = argv[i];
+
+for (i = 0; i < nbtoks; i++)
+argvprime[i + argc] = strtok(i == 0? annot : NULL, " ");
+
+argv = argvprime;
+argc = argc + nbtoks;
+
+for (i = 0; i < nbtoks + 2; i++)
+printf("argv[%d] = %s\n", i, argv[i]);
+
+}
+}
+
+bdrv_delete(bs);
+}
+
optind = 1;
for(;;) {
if (optind >= argc)
@@ -7558,7 +7622,6 @@ int main(int argc, char **argv)
#endif
/* we always create the cdrom drive, even if no disk is there */
-bdrv_init();
if (cdrom_index >= 0) {
bs_table[cdrom_index] = bdrv_new("cdrom");
bdrv_set_type_hint(bs_table[cdrom_index], BDRV_TYPE_CDROM);
@@ -7764,5 +7827,8 @@ int main(int argc, char **argv)
main_loop();
quit_timers();
+
+/* was reassigned above so it needs free()ing */
+free(argv);
return 0;
}
This patch makes QEMU check for command line options stored in qcow2 images.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
---
diff --git a/qemu/vl.c b/qemu/vl.c
index 4ad39f1..1d28794 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -184,6 +184,11 @@ int time_drift_fix = 0;
const char *cpu_vendor_string;
/***/
+/* Image annotation support */
+
+char *img_get_annot(char *filename);
+
+/***/
/* x86 ISA bus support */
target_phys_addr_t isa_mem_base = 0;
@@ -6917,6 +6922,13 @@ int main(int argc, char **argv)
char usb_devices[MAX_USB_CMDLINE][128];
int usb_devices_index;
int fds[2];
+char *tmpannot;
+char annot[1024];
+int done = 0;
+unsigned int nbtoks = 0;
+char *tok;
+BlockDriver *drv;
+BlockDriverState *bs;
saved_argc = argc;
saved_argv = argv;
@@ -7000,6 +7012,58 @@ int main(int argc, char **argv)
nb_nics = 0;
/* default mac address of the first network interface */
+bdrv_init();
+
+drv = bdrv_find_format("qcow2");
+
+if (argc > 1 && argv[1][0] != '-') {
+bs = bdrv_new("");
+if (!bs) {
+fprintf(stderr, "Not enough memory");
+exit(1);
+}
+if (bdrv_open2(bs, argv[1], 0, drv) < 0) {
+fprintf(stderr, "Could not open '%s'", argv[1]);
+bdrv_delete(bs);
+exit(1);
+}
+
+tmpannot = bdrv_get_annot(bs, "commandline_args");
+if (tmpannot) {
+pstrcpy(annot, 1024, tmpannot);
+
+do {
+tok = strtok(nbtoks == 0? tmpannot : NULL, " ");
+
+if (tok != NULL)
+nbtoks++;
+else
+done = 1;
+} while (!done);
+
+free(tmpannot);
Re: [kvm-devel] [PATCH 1/4][RFC] Allow storing arbitrary annotations in qcow2 images
This should go through qemu-devel BTW. Please submit there and I'll
provide comments.
Regards,
Anthony Liguori
Jorge Lucángeli Obes wrote:
> This patch adds an extra 'annot' field to qcow2 snapshots, and updates
> serialization functions.
>
> Signed-off-by: Jorge Lucángeli Obes <[EMAIL PROTECTED]>
> ---
> diff --git a/qemu/block-qcow2.c b/qemu/block-qcow2.c
> index 0f7a069..361d300 100644
> --- a/qemu/block-qcow2.c
> +++ b/qemu/block-qcow2.c
> @@ -106,6 +106,8 @@ typedef struct QCowSnapshot {
> uint32_t l1_size;
> char *id_str;
> char *name;
> +char *annot;
> +
> uint32_t vm_state_size;
> uint32_t date_sec;
> uint32_t date_nsec;
> @@ -1370,6 +1372,7 @@ static void qcow_free_snapshots(BlockDriverState *bs)
> for(i = 0; i < s->nb_snapshots; i++) {
> qemu_free(s->snapshots[i].name);
> qemu_free(s->snapshots[i].id_str);
> +qemu_free(s->snapshots[i].annot);
> }
> qemu_free(s->snapshots);
> s->snapshots = NULL;
> @@ -1401,12 +1404,18 @@ static int qcow_read_snapshots(BlockDriverState *bs)
> sn->date_sec = be32_to_cpu(h.date_sec);
> sn->date_nsec = be32_to_cpu(h.date_nsec);
> sn->vm_clock_nsec = be64_to_cpu(h.vm_clock_nsec);
> -extra_data_size = be32_to_cpu(h.extra_data_size);
>
> +extra_data_size = be32_to_cpu(h.extra_data_size);
> id_str_size = be16_to_cpu(h.id_str_size);
> name_size = be16_to_cpu(h.name_size);
>
> +sn->annot = qemu_malloc(extra_data_size + 1);
> +if (!sn->annot)
> +goto fail;
> +if (bdrv_pread(s->hd, offset, sn->annot, extra_data_size) !=
> extra_data_size)
> +goto fail;
> offset += extra_data_size;
> +sn->annot[extra_data_size] = '\0';
>
> sn->id_str = qemu_malloc(id_str_size + 1);
> if (!sn->id_str)
> @@ -1439,7 +1448,7 @@ static int qcow_write_snapshots(BlockDriverState *bs)
> QCowSnapshotHeader h;
> int i, name_size, id_str_size, snapshots_size;
> uint64_t data64;
> -uint32_t data32;
> +uint32_t data32, extra_data_size;
> int64_t offset, snapshots_offset;
>
> /* compute the size of the snapshots */
> @@ -1448,6 +1457,7 @@ static int qcow_write_snapshots(BlockDriverState *bs)
> sn = s->snapshots + i;
> offset = align_offset(offset, 8);
> offset += sizeof(h);
> +offset += strlen(sn->annot);
> offset += strlen(sn->id_str);
> offset += strlen(sn->name);
> }
> @@ -1455,7 +1465,7 @@ static int qcow_write_snapshots(BlockDriverState *bs)
>
> snapshots_offset = alloc_clusters(bs, snapshots_size);
> offset = snapshots_offset;
> -
> +
> for(i = 0; i < s->nb_snapshots; i++) {
> sn = s->snapshots + i;
> memset(&h, 0, sizeof(h));
> @@ -1465,7 +1475,9 @@ static int qcow_write_snapshots(BlockDriverState *bs)
> h.date_sec = cpu_to_be32(sn->date_sec);
> h.date_nsec = cpu_to_be32(sn->date_nsec);
> h.vm_clock_nsec = cpu_to_be64(sn->vm_clock_nsec);
> -
> +
> +extra_data_size = strlen(sn->annot);
> +h.extra_data_size = cpu_to_be32(extra_data_size);
> id_str_size = strlen(sn->id_str);
> name_size = strlen(sn->name);
> h.id_str_size = cpu_to_be16(id_str_size);
> @@ -1474,6 +1486,9 @@ static int qcow_write_snapshots(BlockDriverState *bs)
> if (bdrv_pwrite(s->hd, offset, &h, sizeof(h)) != sizeof(h))
> goto fail;
> offset += sizeof(h);
> +if (bdrv_pwrite(s->hd, offset, sn->annot, extra_data_size) !=
> extra_data_size)
> +goto fail;
> +offset += extra_data_size;
> if (bdrv_pwrite(s->hd, offset, sn->id_str, id_str_size) !=
> id_str_size)
> goto fail;
> offset += id_str_size;
> @@ -1570,6 +1585,10 @@ static int qcow_snapshot_create(BlockDriverState *bs,
> sn->name = qemu_strdup(sn_info->name);
> if (!sn->name)
> goto fail;
> +sn->annot = qemu_strdup(sn_info->annot);
> +if (!sn->annot)
> +goto fail;
> +
> sn->vm_state_size = sn_info->vm_state_size;
> sn->date_sec = sn_info->date_sec;
> sn->date_nsec = sn_info->date_nsec;
> @@ -1680,6 +1699,8 @@ static int qcow_snapshot_delete(BlockDriverState
> *bs, const char *snapshot_id)
>
> qemu_free(sn->id_str);
> qemu_free(sn->name);
> +qemu_free(sn->annot);
> +
> memmove(sn, sn + 1, (s->nb_snapshots - snapshot_index - 1) *
> sizeof(*sn));
> s->nb_snapshots--;
> ret = qcow_write_snapshots(bs);
> @@ -1707,10 +1728,14 @@ static int qcow_snapshot_list(BlockDriverState *bs,
> for(i = 0; i < s->nb_snapshots; i++) {
> sn_info = sn_tab + i;
> sn = s->snapshots + i;
> +
> pstrcpy(sn_info->id_str, sizeof(sn_info->id_str),
> sn->id_str);
> pstrcpy(sn_info->name, sizeof(sn_info->name),
> sn->name);
> +pstrcpy(sn_info->annot, si
[kvm-devel] [PATCH 1/3] qemu: fix freed pointer dereference
If *has_error==0, s is freed before s->detach is used. Save a copy of s->detach earlier. Signed-off-by: Jim Paris <[EMAIL PROTECTED]> --- This shouldn't change much since the memory is most likely still valid even after it's been freed, but it's still a bug. qemu/migration.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/qemu/migration.c b/qemu/migration.c index 6053c98..4d7aa01 100644 --- a/qemu/migration.c +++ b/qemu/migration.c @@ -169,6 +169,7 @@ static void migrate_finish(MigrationState *s) int ret = 0; int *has_error = s->has_error; int saved_vm_running = vm_running; +int detach = s->detach; fcntl(s->fd, F_SETFL, 0); @@ -194,7 +195,7 @@ static void migrate_finish(MigrationState *s) if (saved_vm_running) vm_start(); } -if (!s->detach) +if (!detach) monitor_resume(); qemu_free(has_error); cpu_physical_memory_set_dirty_tracking(0); -- 1.5.3.GIT - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/3] qemu: reset buffer pointers after CR/LF
If readline_handle_byte() is sent both a CR and LF, and
readline_start() is not called after the first CR, then the LF will
cause the same command to be executed a second time. Fix this by
explicitly resetting the buffer pointer when it is processed.
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
This should probably get pushed upstream too.
qemu/readline.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/qemu/readline.c b/qemu/readline.c
index cbe33db..bde3342 100644
--- a/qemu/readline.c
+++ b/qemu/readline.c
@@ -335,6 +335,8 @@ void readline_handle_byte(int ch)
if (!term_is_password)
term_hist_add(term_cmd_buf);
term_printf("\n");
+term_cmd_buf_index = 0;
+term_cmd_buf_size = 0;
/* NOTE: readline_start can be called here */
term_readline_func(term_readline_opaque, term_cmd_buf);
break;
--
1.5.3.GIT
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] migration with exec giving truncated images
I think I've (finally!) tracked it down. See the attached patches. The main problem is this: when using "-monitor pty", all incoming commands are terminated with CRLF even though they were sent with just LF, probably because of the pty layer somewhere. When qemu's readline gets CR and LF without calling readline_start() in between, it executes the same command twice in a row, which meant that _two_ migrations were running concurrently. -jim - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] qemu: don't start a new migration if one is already in progress
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
Having two migrations run simultaneously was causing my crashes.
The command was sent twice because of a bug in the readline routines,
but adding a check here as well seems like a good idea.
qemu/migration.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/qemu/migration.c b/qemu/migration.c
index 4d7aa01..96b0c2f 100644
--- a/qemu/migration.c
+++ b/qemu/migration.c
@@ -973,6 +973,12 @@ int migrate_incoming(const char *device)
void do_migrate(int detach, const char *uri)
{
const char *ptr;
+MigrationState *s = current_migration;
+
+if (s) {
+ term_printf("Migration already active\n");
+ return;
+}
status = MIG_STAT_INVALID_PARAMS;
if (strstart(uri, "exec:", &ptr)) {
--
1.5.3.GIT
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm warning
ia64 allmodconfig says drivers/kvm/Kconfig:14:warning: 'select' used by config symbol 'KVM' refers to undefined symbol 'PREEMPT_NOTIFIERS' Because of commit 8928fb48c7a7f9053a55f1d0023cbc533f2b3663 Author: Avi Kivity <[EMAIL PROTECTED]> Date: Wed Jul 11 18:17:21 2007 +0300 KVM: Use the scheduler preemption notifiers to make kvm preemptible Current kvm disables preemption while the new virtualization registers are in use. This of course is not very good for latency sensitive workloads (on use of virtualization is to offload user interface and other latency insensitive stuff to a container, so that it is easier to analyze the remaining workload). This patch re-enables preemption for kvm; preemption is now only disabled when switching the registers in and out, and during the switch to guest mode and back. Contains fixes from Shaohua Li <[EMAIL PROTECTED]>. Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> --- a/drivers/kvm/Kconfig +++ b/drivers/kvm/Kconfig @@ -11,6 +11,7 @@ if VIRTUALIZATION config KVM tristate "Kernel-based Virtual Machine (KVM) support" depends on X86 && EXPERIMENTAL + select PREEMPT_NOTIFIERS select ANON_INODES ---help--- Support hosting fully virtualized guest machines using hardware ... a) is kvm supported on ia64 at all?? b) `select' is evil. Just Don't Do It. c) `select' is especially evil when it's done on some kernel-internal secret symbol like PREEMPT_NOTIFIERS. d) I can't see anything else in the kernel which sets or clears PREEMPT_NOTIFIERS so I'm rather wonderring why the config option exists at all. e) sched developers may not like KVM reaching over and twiddling their knobs for them. It all needs more thought, I think... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm warning
* Andrew Morton <[EMAIL PROTECTED]> wrote: > ia64 allmodconfig says > > drivers/kvm/Kconfig:14:warning: 'select' used by config symbol 'KVM' > refers to undefined symbol 'PREEMPT_NOTIFIERS' hm, why doesnt ia64 pick up kernel/Kconfig.preempt, like all the other arches? Due to that ia64 also misses out on voluntary preempt and on preempt-bkl. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm warning
Ingo Molnar wrote: > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > >> ia64 allmodconfig says >> >> drivers/kvm/Kconfig:14:warning: 'select' used by config symbol 'KVM' >> refers to undefined symbol 'PREEMPT_NOTIFIERS' >> > > hm, why doesnt ia64 pick up kernel/Kconfig.preempt, like all the other > arches? Due to that ia64 also misses out on voluntary preempt and on > preempt-bkl. > > Even more hm, how does ia64 manage to enable kvm? It 'depends on X86' at this moment. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm warning
On Thu, 09 Aug 2007 01:48:07 +0300 Avi Kivity <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > >> ia64 allmodconfig says > >> > >> drivers/kvm/Kconfig:14:warning: 'select' used by config symbol 'KVM' > >> refers to undefined symbol 'PREEMPT_NOTIFIERS' > >> > > > > hm, why doesnt ia64 pick up kernel/Kconfig.preempt, like all the other > > arches? Due to that ia64 also misses out on voluntary preempt and on > > preempt-bkl. > > > > > > Even more hm, how does ia64 manage to enable kvm? It 'depends on X86' > at this moment. > beats me. CONFIG_KVM doesn't get set. But it seems that kconfig wants to do error-checking on that item anyway. btw, testing of Kconfig can be done for any architecture without installation of a toolchain for that architecture. Set $ARCH and run mrproper then use menuconfig/oldconfig/allmodconfig/allconfig as usual. Judging by the number of Kconfig problem I see, this is a big secret ;) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm warning
Andrew Morton wrote: > On Thu, 09 Aug 2007 01:48:07 +0300 > Avi Kivity <[EMAIL PROTECTED]> wrote: > > >> Ingo Molnar wrote: >> >>> * Andrew Morton <[EMAIL PROTECTED]> wrote: >>> >>> >>> ia64 allmodconfig says drivers/kvm/Kconfig:14:warning: 'select' used by config symbol 'KVM' refers to undefined symbol 'PREEMPT_NOTIFIERS' >>> hm, why doesnt ia64 pick up kernel/Kconfig.preempt, like all the other >>> arches? Due to that ia64 also misses out on voluntary preempt and on >>> preempt-bkl. >>> >>> >>> >> Even more hm, how does ia64 manage to enable kvm? It 'depends on X86' >> at this moment. >> >> > > beats me. CONFIG_KVM doesn't get set. But it seems that kconfig wants > to do error-checking on that item anyway. > > > I could do a 'select PREEMPT_NOTIFIERS if X86' but it seems silly. I'd call it a Kconfig bug. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
