Re: [kvm-devel] [PATCH][RFC] mmu:remove the usage of the private field by the rmap.
Anthony Liguori wrote:
I think you forgot to include the patch?
Regards,
Anthony Liguori
yes i forgot :)
here it is...
commit 3ed7059496e6e7d802dfb46e604d0af4abc2b040
Author: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon Sep 24 13:35:12 2007 +0200
Remove the usage of the private field by the rmap.
this patch add to each memory slot an array sorted by gfn that hold to each page
its reverse mapping,
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index b7cd276..e403441 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -126,6 +126,8 @@ struct kvm_mmu_page {
union kvm_mmu_page_role role;
u64 *spt;
+ /* hold the gfn of each spte inside spt */
+ gfn_t *gfns;
unsigned long slot_bitmap; /* One bit set per slot which has memory
* in this shadow page.
*/
@@ -157,7 +159,7 @@ struct kvm_mmu {
u64 *pae_root;
};
-#define KVM_NR_MEM_OBJS 20
+#define KVM_NR_MEM_OBJS 40
struct kvm_mmu_memory_cache {
int nobjs;
@@ -399,6 +401,7 @@ struct kvm_memory_slot {
unsigned long npages;
unsigned long flags;
struct page **phys_mem;
+ unsigned long *rmap;
unsigned long *dirty_bitmap;
};
@@ -550,6 +553,7 @@ struct page *gva_to_page(struct kvm_vcpu *vcpu, gva_t gva);
extern hpa_t bad_page_address;
+gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn);
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn);
struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn);
void mark_page_dirty(struct kvm *kvm, gfn_t gfn);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index bc2d32d..366e769 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -329,6 +329,8 @@ static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
__free_page(free->phys_mem[i]);
vfree(free->phys_mem);
}
+ if (!dont || free->rmap != dont->rmap)
+ vfree(free->rmap);
if (!dont || free->dirty_bitmap != dont->dirty_bitmap)
vfree(free->dirty_bitmap);
@@ -742,13 +744,18 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
if (!new.phys_mem)
goto out_unlock;
+ new.rmap = vmalloc(npages * sizeof(struct page*));
+
+ if (!new.rmap)
+ goto out_unlock;
+
memset(new.phys_mem, 0, npages * sizeof(struct page *));
+ memset(new.rmap, 0, npages * sizeof(*new.rmap));
for (i = 0; i < npages; ++i) {
new.phys_mem[i] = alloc_page(GFP_HIGHUSER
| __GFP_ZERO);
if (!new.phys_mem[i])
goto out_unlock;
- set_page_private(new.phys_mem[i],0);
}
}
@@ -932,7 +939,7 @@ static int kvm_vm_ioctl_set_irqchip(struct kvm *kvm, struct kvm_irqchip *chip)
return r;
}
-static gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
+gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
{
int i;
struct kvm_mem_alias *alias;
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 6d84d30..6d404a5 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -259,7 +259,7 @@ static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu)
rmap_desc_cache, 1);
if (r)
goto out;
- r = mmu_topup_memory_cache_page(&vcpu->mmu_page_cache, 4);
+ r = mmu_topup_memory_cache_page(&vcpu->mmu_page_cache, 8);
if (r)
goto out;
r = mmu_topup_memory_cache(&vcpu->mmu_page_header_cache,
@@ -310,35 +310,55 @@ static void mmu_free_rmap_desc(struct kvm_rmap_desc *rd)
}
/*
+ * Take gfn and return the reverse mapping to it.
+ * Note: gfn must be unaliased before this function get called
+ */
+
+static unsigned long *gfn_to_rmap(struct kvm *kvm, gfn_t gfn)
+{
+
+ struct kvm_memory_slot *slot;
+
+ slot = gfn_to_memslot(kvm, gfn);
+ return &slot->rmap[gfn - slot->base_gfn];
+}
+
+/*
* Reverse mapping data structures:
*
- * If page->private bit zero is zero, then page->private points to the
- * shadow page table entry that points to page_address(page).
+ * If rmapp bit zero is zero, then rmapp point to the shadw page table entry
+ * that points to page_address(page).
*
- * If page->private bit zero is one, (then page->private & ~1) points
- * to a struct kvm_rmap_desc containing more mappings.
+ * If rmapp bit zero is one, (then rmap & ~1) points to a struct kvm_rmap_desc
+ * containing more mappings.
*/
-static void rmap_add(struct kvm_vcpu *vcpu, u64 *spte)
+static void rmap_add(struct kvm_vcpu *vcpu, u64 *spte, gfn_t gfn)
{
- struct page *page;
+ struct kvm_mmu_page *page;
struct kvm_rmap_desc *desc;
+ unsigned long *rmapp;
int i;
if (!is_rmap_pte(*spte))
return;
- page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >> PAGE_SHIFT);
- if (!page_private(page)) {
+
+ gfn = unalias_gfn(vcpu->kvm, gfn);
+ page = page_header(__pa(spte));
+ page->gfns[spte - page->spt] = gfn;
+ rmapp = gfn_to_rmap(vcpu->kvm, gfn);
+
+ if (!*rmapp) {
rmap_printk("rmap_add: %p %llx 0->1\n", spte, *spte);
- set_page_private(page,(unsigned long)spte);
- } else if (!(page_private(page) & 1)) {
+ *rmapp = (unsigned long)spte;
+ } else if (!(*rmapp & 1)) {
rmap_printk("rmap_add: %p %llx 1->man
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Zhao, Yunfeng wrote: > The attachment is the .config I am using now. > And one more difference is in our testing most guests are created with qcow > images. > I too use qcow usually (well, qcow2). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] BUG_ON in mmu.c:436
Ryan Harper wrote: > * Avi Kivity <[EMAIL PROTECTED]> [2007-09-24 02:57]: > >> Ryan Harper wrote: >> >>> I've run into a nasty bug while trying to install a Linux guest using >>> VMware Server inside a kvm guest (full dmesg attached and recreate >>> instructions below bug). >>> >>> >>> >> Can you reproduce this with AUDIT turned on (top of mmu.c)? AUDIT is >> very slow, so it's recommended to reduce guest memory as much as possible. >> > > Working on it -- running for the better part of today with 256MB and I'm > still booting up the guest. I'll let you know how things go tomorrow. > Any thoughts on how to speed audit runs up other than lower guest > memory? > Hmm. Reduce the number of shadow page tables (KVM_NUM_MMU_PAGES). You can also turn a few passes off in the main audit function, but that of course reduces its effectiveness. btw, the error may occur before the guest fails, so keep an eye on dmesg. Once it hits things will slow down even more due to a flood of printks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] virtio interface
On Tue, 25 Sep 2007 09:37:38 +1000,
Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-25 at 00:18 +0200, Arnd Bergmann wrote:
> > On Monday 24 September 2007, Rusty Russell wrote:
> > > +
> > > +struct virtio_bus {
> > > + struct bus_type bus;
> > > + struct device dev;
> > > +};
> > > +
> > > +static struct virtio_bus virtio_bus = {
> > > + .bus = {
> > > + .name = "virtio",
> > > + .match = virtio_dev_match,
> > > + .dev_attrs = virtio_dev_attrs,
> > > + },
> > > + .dev = {
> > > + /* Can override this if you have a real bus behind it. */
> > > + .parent = NULL,
> > > + .bus_id = "virtio",
> > > + }
> > > +};
> >
> > This is a pattern I've seen a few times before, but could never understand
> > what it's good for. What is your reason for defining a new data structure
> > that is used only once, instead of just
> >
> > static struct bus_type virtio_bus_type;
> > static struct device virtio_root_dev;
>
> It's copied from the lguest bus which was copied from somewhere else.
> Creating a struct like this is a quiet complaint about the requirements
> to do so: it's not clear to me why I need to create a fake device,
> rather than making the bus the parent of the device if it needs one.
You may want to have different busses, all having their own root
device, which share the same bus type.
Or you may want to embed the root device into a more complex structure.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH]Memory mapped TPR shadow feature enabling
Yang, Sheng wrote:
> These patches enable memory mapped TPR shadow (FlexPriority).
>
> Since TPR is accessed very frequently by 32bit Windows, especially SMP
> guest, with FlexPriority enabled, we saw significant performance gain.
>
> The issue is: FlexPriority needs to add a memory slot to the vm to make
> shadow work with APIC access page.
>
> We don't like the idea to add a memory slot, but no better choice now.
> Our propose is to add p2m table to KVM, while seems this is still a long
> way to go.
>
> BTW: I didn't use the offset(or other info) provide by CPU when handling
> APIC access vmexit. Instead, I used a bit in cmd_type(including
> no_decode) to tell emulator decode memory operand by itself when
> necessary. That's because I only got the guest physical address when
> handling APIC access vmexit, but emulator need a guest virtual address
> to fit its flow. I have tried some ways, and current solution seems the
> most proper one.
>
>
> These patches enable memory mapped TPR shadow (FlexPriority).
>
> Since TPR is accessed very frequently by 32bit Windows, especially SMP
> guest, with FlexPriority enabled, we saw significant performance gain.
>
> The issue is: FlexPriority needs to add a memory slot to the vm to make
> shadow work with APIC access page.
>
> We don't like the idea to add a memory slot, but no better choice now.
> Our propose is to add p2m table to KVM, while seems this is still a long
> way to go.
>
> BTW: I didn't use the offset(or other info) provide by CPU when handling
> APIC access vmexit. Instead, I used a bit in cmd_type(including
> no_decode) to tell emulator decode memory operand by itself when
> necessary. That's because I only got the guest physical address when
> handling APIC access vmexit, but emulator need a guest virtual address
> to fit its flow. I have tried some ways, and current solution seems the
> most proper one.
>
> + struct kvm_memory_region apic_memory = {
> + .slot = 5,
> + .memory_size = PAGE_SIZE,
> + .guest_phys_addr = apicmem,
> + };
>
> if (memory >= pcimem)
> extended_memory.memory_size = pcimem - exmem;
> @@ -302,9 +308,16 @@ int kvm_create(kvm_context_t kvm, unsigned long
> phys_mem_bytes, void **vm_mem)
> }
> }
>
> + r = ioctl(fd, KVM_SET_MEMORY_REGION, &apic_memory);
> + if (r == -1) {
> + fprintf(stderr, "kvm_create_memory_region: %m\n");
> + return -1;
> + }
>
Older kernels support only 4 memory slots, so you need to tolerate
failures here (this isn't an issue for large memory, because there's no
way the older kernel can run with large memory, so you can't continue.
but new userspace should be able to run with an older kernel if is not
using newer features.
I don't like userspace involvement in this. Perhaps we can have a
memory slot controlled by the kernel for this? It would be activated by
the feature, so it we won't have it on AMD or when the feature isn't
available.
It can also be just a special case in gfn_to_page.
> ns(-) diff --git a/drivers/kvm/irq.h b/drivers/kvm/irq.h index
> 11fc014..afbfa0c 100644 --- a/drivers/kvm/irq.h +++
> b/drivers/kvm/irq.h @@ -118,6 +118,8 @@ struct kvm_lapic { struct
> kvm_vcpu *vcpu; struct page *regs_page; void *regs; + struct page
> *apic_access_page; + hpa_t apic_access_hpa; };
The second variable is redundant; just use page_address().
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c index
> cecdb1b..0ebae4c 100644 --- a/drivers/kvm/kvm_main.c +++
> b/drivers/kvm/kvm_main.c @@ -1080,14 +1080,19 @@ static int
> emulator_read_emulated(unsigned long addr, memcpy(val,
> vcpu->mmio_data, bytes); vcpu->mmio_read_completed = 0; return
> X86EMUL_CONTINUE; - } else if (emulator_read_std(addr, val, bytes,
> vcpu) - == X86EMUL_CONTINUE) - return X86EMUL_CONTINUE; + } gpa =
> vcpu->mmu.gva_to_gpa(vcpu, addr); + if ((gpa & PAGE_MASK) ==
> 0xfee0) + goto mmio; +
The guest can change the apic base address. Different vcpus can have
different addresses.
> + if ((gpa & PAGE_MASK) == 0xfee0) + goto mmio; +
Same here.
> +static inline int cpu_has_secondary_exec_ctrls(void) +{ + return
> (vmcs_config.cpu_based_exec_ctrl & \ +
> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS); +}
We aren't in a macro there's no \
need for a backslash.
> + +static inline int cpu_has_vmx_virtualize_apic_accesses(void) +{ +
> return (vmcs_config.cpu_based_2nd_exec_ctrl & \ +
> SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES); +}
ditto
> + +static inline int vm_need_virtualize_apic_accesses(struct kvm *kvm)
> +{ + return ((cpu_has_vmx_virtualize_apic_accesses()) && \ +
> (irqchip_in_kernel(kvm))); +} +
ditto
> +static int handle_apic_access(struct kvm_vcpu *vcpu, struct kvm_run
> *kvm_run) +{ + u64 exit_qualification; + enum emulation_result er; +
> unsigned long offset; + + exit_qualification =
> vmcs_read64(EXIT_QUALIFICATION); + offset = exit_qualification &
> 0xffful; + + er = emulate_in
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> Hi,
>
> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> > As with previous "Takes" of this patch, its purpose is to expose host
> > +{
> > +asm("cpuid"
> > +: "=a" (*ax),
> > + "=b" (*bx),
> > + "=c" (*cx),
> > + "=d" (*dx)
> > +: "a" (function));
> > +}
>
> I haven't really read through the rest of your code but this piece
> appears to be outside any #ifdef/#endif so it will only build on x86.
I might be missing something here, but isn't not being on the
TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
elsewhere under target-i386. I don't mind adding extra protection, I
just be happy to better understand the whats and whys.
Dan.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
We are using XP x64 Edition Version 2003 SP1 in the test case. Thanks Yunfeng >-Original Message- >From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2007年9月25日 15:53 >To: Zhao, Yunfeng >Cc: Laurent Vivier; kvm-devel@lists.sourceforge.net >Subject: Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace >114b08b.. > >Zhao, Yunfeng wrote: >> The attachment is the .config I am using now. >> And one more difference is in our testing most guests are created with qcow >images. >> > >I too use qcow usually (well, qcow2). > > >-- >Do not meddle in the internals of kernels, for they are subtle and quick to >panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Dan Kenigsberg wrote:
> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
>
>> Hi,
>>
>> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
>>
>>> As with previous "Takes" of this patch, its purpose is to expose host
>>> +{
>>> +asm("cpuid"
>>> +: "=a" (*ax),
>>> + "=b" (*bx),
>>> + "=c" (*cx),
>>> + "=d" (*dx)
>>> +: "a" (function));
>>> +}
>>>
>> I haven't really read through the rest of your code but this piece
>> appears to be outside any #ifdef/#endif so it will only build on x86.
>>
>
> I might be missing something here, but isn't not being on the
> TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
> elsewhere under target-i386. I don't mind adding extra protection, I
> just be happy to better understand the whats and whys.
>
target-i386 means the guest will run i386 instructions, but the host can
be something else (say, powerpc).
Nothing else uses host instructions in that directory, so no protection
was necessary before.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Zhao, Yunfeng wrote: > We are using XP x64 Edition Version 2003 SP1 in the test case. > All my tests were 32-bit XP... that's probably the difference. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
64bit 2003 has a similar issue but, it doesn’t happen very time. Did you have problem to boot smp win2k? smp win2k on 64bit host got a blue screen in today's testing. I also found that booting 4 linux guests may cause host to hang. I tried to repeat the test case of booting 4 linux guests many times, most time it passed, but sometimes it causes host to hang. I didn't catch any error log from kernel. Thanks Yunfeng >-Original Message- >From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2007年9月25日 17:02 >To: Zhao, Yunfeng >Cc: kvm-devel@lists.sourceforge.net; Laurent Vivier >Subject: Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace >114b08b.. > >Zhao, Yunfeng wrote: >> We are using XP x64 Edition Version 2003 SP1 in the test case. >> > >All my tests were 32-bit XP... that's probably the difference. > >-- >Do not meddle in the internals of kernels, for they are subtle and quick to >panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
> Dan Kenigsberg wrote:
> > On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> >
> >> Hi,
> >>
> >> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> >>
> >>> As with previous "Takes" of this patch, its purpose is to expose host
> >>> +{
> >>> +asm("cpuid"
> >>> +: "=a" (*ax),
> >>> + "=b" (*bx),
> >>> + "=c" (*cx),
> >>> + "=d" (*dx)
> >>> +: "a" (function));
> >>> +}
> >>>
> >> I haven't really read through the rest of your code but this piece
> >> appears to be outside any #ifdef/#endif so it will only build on x86.
> >>
> >
> > I might be missing something here, but isn't not being on the
> > TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
> > elsewhere under target-i386. I don't mind adding extra protection, I
> > just be happy to better understand the whats and whys.
> >
>
> target-i386 means the guest will run i386 instructions, but the host can
> be something else (say, powerpc).
>
> Nothing else uses host instructions in that directory, so no protection
> was necessary before.
I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
x86/x86_64 target. Then, an external tool (even a shell script) can be
used to determine what is the host CPU if you want to select the exact
same CPU to be emulated in Qemu. It seems to me that trying to do so is
out of the scope of Qemu code and just add unneeded complexity.
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
J. Mayer wrote:
> On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
>
>> Dan Kenigsberg wrote:
>>
>>> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
>>>
>>>
Hi,
On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> As with previous "Takes" of this patch, its purpose is to expose host
> +{
> +asm("cpuid"
> +: "=a" (*ax),
> + "=b" (*bx),
> + "=c" (*cx),
> + "=d" (*dx)
> +: "a" (function));
> +}
>
>
I haven't really read through the rest of your code but this piece
appears to be outside any #ifdef/#endif so it will only build on x86.
>>> I might be missing something here, but isn't not being on the
>>> TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
>>> elsewhere under target-i386. I don't mind adding extra protection, I
>>> just be happy to better understand the whats and whys.
>>>
>>>
>> target-i386 means the guest will run i386 instructions, but the host can
>> be something else (say, powerpc).
>>
>> Nothing else uses host instructions in that directory, so no protection
>> was necessary before.
>>
>
> I've got a remark about this: why this has to be added to the Qemu
> code ?
> Imho, all is needed is an implementation of the -cpu option for
> x86/x86_64 target. Then, an external tool (even a shell script) can be
> used to determine what is the host CPU if you want to select the exact
> same CPU to be emulated in Qemu. It seems to me that trying to do so is
> out of the scope of Qemu code and just add unneeded complexity.
>
Indeed for regular qemu this is useless. But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH v2] Use net-tools as a fallback for iproute2 for bridge configuration
The following patch uses net-tools (ifconfig and netstat) if /sbin/ip is
not available while trying to configure a bridge with the kvm wrapper
and qemu-ifup.
It also adds an option to the kvm wrapper to define which bridge device to
use instead of the hardcoded eth0 value (which is still the default)
Carlo
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
kvm | 33 -
scripts/qemu-ifup | 17 +++--
2 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/kvm b/kvm
index d091c86..2f81ae4 100755
--- a/kvm
+++ b/kvm
@@ -55,6 +55,12 @@ optparser.add_option('--no-tap',
default = not privileged,
)
+optparser.add_option('--bridge',
+ help = 'use this device to build the bridge',
+dest = 'bridge',
+default = None,
+)
+
optparser.add_option('--mac',
help = 'use this specific mac addr',
dest = 'mac',
@@ -191,6 +197,7 @@ bootdisk = 'c'
if options.install:
bootdisk = 'd'
+# kvm always compiles for the x86_64 target
arch = 'x86_64'
if arch == 'x86_64':
@@ -226,15 +233,31 @@ if options.debugger:
if not options.irqchip:
qemu_args += ('-no-kvm-irqchip',)
+def getmac(interface):
+if os.access('/sbin/ip', os.F_OK):
+for line in commands.getoutput('/sbin/ip link show ' +
interface).splitlines():
+m = re.match(r'.*link/ether (..:..:..:..:..:..).*', line)
+ if m:
+ mac = m.group(1)
+ return mac
+else:
+for line in commands.getoutput('/sbin/ifconfig ' +
interface).splitlines():
+m = re.match(r'.*HWaddr (..:..:..:..:..:..)', line)
+ if m:
+ mac = m.group(1)
+ return mac
+return False
+
if not options.notap:
+bridge = options.bridge
+if not bridge:
+bridge = 'eth0'
+
mac = options.mac
if not mac:
-for line in commands.getoutput('/sbin/ip link show eth0').splitlines():
-m = re.match(r'.*link/ether (..:..:..:..:..:..).*', line)
-if m:
-mac = m.group(1)
+mac = getmac(bridge)
if not mac:
-raise Exception, 'Unable to determine eth0 mac address'
+raise Exception, 'Unable to determine ' + bridge + ' mac address'
mac_components = mac.split(':')
mac_components[0] = 'a0'
mac = ':'.join(mac_components)
diff --git a/scripts/qemu-ifup b/scripts/qemu-ifup
index 3bf8801..989fe9a 100755
--- a/scripts/qemu-ifup
+++ b/scripts/qemu-ifup
@@ -1,5 +1,18 @@
#!/bin/sh
-switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+if [ -x /sbin/brctl ]; then
+ BRCTL="/sbin/brctl"
+elif [ -x /usr/sbin/brctl ]; then
+ BRCTL="/usr/sbin/brctl"
+else
+ echo "no bridge utils installed"
+ exit 1
+fi
+
+if [ -x /sbin/ip ]; then
+ switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+else
+ switch=$(/bin/netstat -rn | awk '/^0\.0\.0\.0/ { print $NF }')
+fi
/sbin/ifconfig $1 0.0.0.0 up
-/usr/sbin/brctl addif ${switch} $1
+${BRCTL} addif ${switch} $1
--
1.5.1.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH v2] Use net-tools as a fallback for iproute2 for bridge configuration
On 9/25/07, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
> diff --git a/scripts/qemu-ifup b/scripts/qemu-ifup
> index 3bf8801..989fe9a 100755
> --- a/scripts/qemu-ifup
> +++ b/scripts/qemu-ifup
> @@ -1,5 +1,18 @@
> #!/bin/sh
>
> -switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
> +if [ -x /sbin/brctl ]; then
> + BRCTL="/sbin/brctl"
> +elif [ -x /usr/sbin/brctl ]; then
> + BRCTL="/usr/sbin/brctl"
> +else
> + echo "no bridge utils installed"
> + exit 1
> +fi
> +
> +if [ -x /sbin/ip ]; then
> + switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
NAK on this piece. This won't work with non-trivial setups (yes, I now
that the original script is broken too, but since you are touching
it...).
See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417151
IMHO it's better to rely on distro-specific scripts to setup the networking.
Luca
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Avi Kivity wrote: >>> >>> >> I've got a remark about this: why this has to be added to the Qemu >> code ? >> Imho, all is needed is an implementation of the -cpu option for >> x86/x86_64 target. Then, an external tool (even a shell script) can be >> used to determine what is the host CPU if you want to select the exact >> same CPU to be emulated in Qemu. It seems to me that trying to do so is >> out of the scope of Qemu code and just add unneeded complexity. >> >> > > Indeed for regular qemu this is useless. But it is useful for kqemu > (for which there is support in mainline qemu), and for kvm (which we > hope to merge one day). > > Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as it can't trap cpuid in all circumstances. So this is mainly useful for kvm. I hope it will be applied regardless of that, as there is agreement that kvm support should be merged. I'd much rather pull the feature from qemu rather than carry it as an additional patch. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Purify x86_decode_insn() error case management
Laurent Vivier wrote: > Purify x86_decode_insn() error case management, > the only valid case is on protected page access, other cases are errors > > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] virtio interface
On Tue, 2007-09-25 at 08:36 +0200, Arnd Bergmann wrote: > On Tuesday 25 September 2007, Rusty Russell wrote: > > I don't mind: we could expose it. > > What I mean with setting the parent appropriately is not to have a global > device that is used by the hv-specific probing code, but to make sure > that each of them provides their own one. The bus_type should either be > global or provide the wrappers for device_register and driver_register > that you have, but the host bridge device belongs with the code that > probes it. E.g. when all virtio devices are behind PCI bridges, there > does not need to be an empty /virtio or /lguest device node at all. Right, that makes sense. I'll shift this "virtio" device node out to the lguest code. Thanks! Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: > Avi Kivity wrote: > >>> > >>> > >> I've got a remark about this: why this has to be added to the Qemu > >> code ? > >> Imho, all is needed is an implementation of the -cpu option for > >> x86/x86_64 target. Then, an external tool (even a shell script) can be > >> used to determine what is the host CPU if you want to select the exact > >> same CPU to be emulated in Qemu. It seems to me that trying to do so is > >> out of the scope of Qemu code and just add unneeded complexity. > >> > >> > > > > Indeed for regular qemu this is useless. But it is useful for kqemu > > (for which there is support in mainline qemu), and for kvm (which we > > hope to merge one day). > > > > > > Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as > it can't trap cpuid in all circumstances. > > So this is mainly useful for kvm. I hope it will be applied regardless > of that, as there is agreement that kvm support should be merged. I'd > much rather pull the feature from qemu rather than carry it as an > additional patch. Still I don't understand why it's usefull to put it inside the emulator and why: # qemu -cpu `guess_host_cpu` would not do the work properly. Adding a specific case for '-cpu host' seems useless to me. And this way of doing potentially work for any family of emulated targets, without any modification in Qemu. If the string returned by 'guess_host_cpu' is not recognized for the specific target you used it with, Qemu just stops telling it cannot find this CPU model, no more, no less. The only case it could be interresting, imho, is if you do not allow the -cpu option in KVM case and force the cpu model instead using this function. This behavior does not seem to be great idea to me. Or maybe I missed something ? -- J. Mayer <[EMAIL PROTECTED]> Never organized - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
J. Mayer wrote: > On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: > >> Avi Kivity wrote: >> > > > I've got a remark about this: why this has to be added to the Qemu code ? Imho, all is needed is an implementation of the -cpu option for x86/x86_64 target. Then, an external tool (even a shell script) can be used to determine what is the host CPU if you want to select the exact same CPU to be emulated in Qemu. It seems to me that trying to do so is out of the scope of Qemu code and just add unneeded complexity. >>> Indeed for regular qemu this is useless. But it is useful for kqemu >>> (for which there is support in mainline qemu), and for kvm (which we >>> hope to merge one day). >>> >>> >>> >> Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as >> it can't trap cpuid in all circumstances. >> >> So this is mainly useful for kvm. I hope it will be applied regardless >> of that, as there is agreement that kvm support should be merged. I'd >> much rather pull the feature from qemu rather than carry it as an >> additional patch. >> > > Still I don't understand why it's usefull to put it inside the emulator > and why: > # qemu -cpu `guess_host_cpu` > would not do the work properly. Adding a specific case for '-cpu host' > seems useless to me. > And this way of doing potentially work for any family of emulated > targets, without any modification in Qemu. If the string returned by > 'guess_host_cpu' is not recognized for the specific target you used it > with, Qemu just stops telling it cannot find this CPU model, no more, no > less. > It's a usability issue. I agree your suggestion would work, but I'd like the default for kvm to be using the host cpu features, whereas managed environments would specify some subset to enable live migration. > The only case it could be interresting, imho, is if you do not allow the > -cpu option in KVM case and force the cpu model instead using this > function. This behavior does not seem to be great idea to me. > I think we can move the host cpu checks to kvm-specific code, since it is not useful for kqemu. So, running qemu without any parameters would use host capabilities if kvm is available and the default qemu cpu if not. The -cpu option can be used to override this if necessary. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Any legacy prefix after a REX prefix nullifies its effect
This patch modifies the management of REX prefix according behavior I saw in
Xen 3.1.
In Xen, this modification has been introduced by Jan Beulich.
http://lists.xensource.com/archives/html/xen-changelog/2007-01/msg00081.html
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index f8516ba..585cccf 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -552,7 +552,7 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
}
/* Legacy prefixes. */
- for (i = 0; i < 8; i++) {
+ for (;;) {
switch (c->b = insn_fetch(u8, 1, c->eip)) {
case 0x66: /* operand-size override */
c->op_bytes ^= 6; /* switch between 2/4 bytes */
@@ -583,6 +583,11 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
case 0x36: /* SS override */
c->override_base = &ctxt->ss_base;
break;
+ case 0x40 ... 0x4f: /* REX */
+ if (mode != X86EMUL_MODE_PROT64)
+ goto done_prefixes;
+ rex_prefix = c->b;
+ continue;
case 0xf0: /* LOCK */
c->lock_prefix = 1;
break;
@@ -593,19 +598,21 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
default:
goto done_prefixes;
}
+
+ /* Any legacy prefix after a REX prefix nullifies its effect. */
+
+ rex_prefix = 0;
}
done_prefixes:
/* REX prefix. */
- if ((mode == X86EMUL_MODE_PROT64) && ((c->b & 0xf0) == 0x40)) {
- rex_prefix = c->b;
- if (c->b & 8)
+ if (rex_prefix) {
+ if (rex_prefix & 8)
c->op_bytes = 8;/* REX.W */
- c->modrm_reg = (c->b & 4) << 1; /* REX.R */
- index_reg = (c->b & 2) << 2; /* REX.X */
- c->modrm_rm = base_reg = (c->b & 1) << 3; /* REG.B */
- c->b = insn_fetch(u8, 1, c->eip);
+ c->modrm_reg = (rex_prefix & 4) << 1; /* REX.R */
+ index_reg = (rex_prefix & 2) << 2; /* REX.X */
+ c->modrm_rm = base_reg = (rex_prefix & 1) << 3; /* REG.B */
}
/* Opcode byte(s). */
--
1.5.2.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Avi Kivity wrote: > J. Mayer wrote: > >>On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: >> >> >>>Avi Kivity wrote: >>> >>> >> >> >> > >I've got a remark about this: why this has to be added to the Qemu >code ? >Imho, all is needed is an implementation of the -cpu option for >x86/x86_64 target. Then, an external tool (even a shell script) can be >used to determine what is the host CPU if you want to select the exact >same CPU to be emulated in Qemu. It seems to me that trying to do so is >out of the scope of Qemu code and just add unneeded complexity. > > > Indeed for regular qemu this is useless. But it is useful for kqemu (for which there is support in mainline qemu), and for kvm (which we hope to merge one day). >>> >>>Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as >>>it can't trap cpuid in all circumstances. >>> >>>So this is mainly useful for kvm. I hope it will be applied regardless >>>of that, as there is agreement that kvm support should be merged. I'd >>>much rather pull the feature from qemu rather than carry it as an >>>additional patch. >>> >> >>Still I don't understand why it's usefull to put it inside the emulator >>and why: >># qemu -cpu `guess_host_cpu` >>would not do the work properly. Adding a specific case for '-cpu host' >>seems useless to me. >>And this way of doing potentially work for any family of emulated >>targets, without any modification in Qemu. If the string returned by >>'guess_host_cpu' is not recognized for the specific target you used it >>with, Qemu just stops telling it cannot find this CPU model, no more, no >>less. >> > > > It's a usability issue. I agree your suggestion would work, but I'd > like the default for kvm to be using the host cpu features, whereas > managed environments would specify some subset to enable live migration. > > >>The only case it could be interresting, imho, is if you do not allow the >>-cpu option in KVM case and force the cpu model instead using this >>function. This behavior does not seem to be great idea to me. >> > > > I think we can move the host cpu checks to kvm-specific code, since it > is not useful for kqemu. > > So, running qemu without any parameters would use host capabilities if > kvm is available and the default qemu cpu if not. The -cpu option can > be used to override this if necessary. Rectification: this is useful for kqemu too. I strongly suggest to look at kqemu.c:kqemu_update_cpuid() ! Moreover I believe that using the same CPU as host can be useful for pure emulation too, for example if code to do cache profiling is added. Regards, Fabrice. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Any legacy prefix after a REX prefix nullifies its effect
Laurent Vivier wrote: > This patch modifies the management of REX prefix according behavior I saw in > Xen 3.1. > In Xen, this modification has been introduced by Jan Beulich. > > Applied, thanks. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU featu res to guests: Take 3
On Tuesday 25 September 2007, Avi Kivity wrote:
> J. Mayer wrote:
> > On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
> >> Dan Kenigsberg wrote:
> >>> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> Hi,
>
> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> > As with previous "Takes" of this patch, its purpose is to expose host
> > +{
> > +asm("cpuid"
> > +: "=a" (*ax),
> > + "=b" (*bx),
> > + "=c" (*cx),
> > + "=d" (*dx)
> > +: "a" (function));
> > +}
>
> Indeed for regular qemu this is useless. But it is useful for kqemu
> (for which there is support in mainline qemu), and for kvm (which we
> hope to merge one day).
And, as discussed before, it should be asking the hypervisor what features it
supports instead of trying to guess from the cpuid output.
Paul
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote: > J. Mayer wrote: > > On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: > > > >> Avi Kivity wrote: > >> > > > > > > > I've got a remark about this: why this has to be added to the Qemu > code ? > Imho, all is needed is an implementation of the -cpu option for > x86/x86_64 target. Then, an external tool (even a shell script) can be > used to determine what is the host CPU if you want to select the exact > same CPU to be emulated in Qemu. It seems to me that trying to do so is > out of the scope of Qemu code and just add unneeded complexity. > > > > >>> Indeed for regular qemu this is useless. But it is useful for kqemu > >>> (for which there is support in mainline qemu), and for kvm (which we > >>> hope to merge one day). > >>> > >>> > >>> > >> Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as > >> it can't trap cpuid in all circumstances. > >> > >> So this is mainly useful for kvm. I hope it will be applied regardless > >> of that, as there is agreement that kvm support should be merged. I'd > >> much rather pull the feature from qemu rather than carry it as an > >> additional patch. > >> > > > > Still I don't understand why it's usefull to put it inside the emulator > > and why: > > # qemu -cpu `guess_host_cpu` > > would not do the work properly. Adding a specific case for '-cpu host' > > seems useless to me. > > And this way of doing potentially work for any family of emulated > > targets, without any modification in Qemu. If the string returned by > > 'guess_host_cpu' is not recognized for the specific target you used it > > with, Qemu just stops telling it cannot find this CPU model, no more, no > > less. > > > > It's a usability issue. I agree your suggestion would work, but I'd > like the default for kvm to be using the host cpu features, whereas > managed environments would specify some subset to enable live migration. > > > The only case it could be interresting, imho, is if you do not allow the > > -cpu option in KVM case and force the cpu model instead using this > > function. This behavior does not seem to be great idea to me. > > > > I think we can move the host cpu checks to kvm-specific code, since it > is not useful for kqemu. > > So, running qemu without any parameters would use host capabilities if > kvm is available and the default qemu cpu if not. The -cpu option can > be used to override this if necessary. Well, it may be needed to integrate the "-cpu host" option. But I think it's a really bad idea that running qemu without the -cpu option would not act the same on different host. When I want to test qemu with the same command line, I want it to behave exactly the same, whatever the host I'm running on, like any other tool. Think about gcc, for example, if you launch it without option, it compiles for a generic CPU. If you want to tune the generated code, even for the host you're running on, you have to use -mcpu/-march/-mtune. Using one command line always have gives the same result. Then, my opinion is that running qemu without any -cpu option should always use a default target. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Jocelyn Mayer wrote: > On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote: > >> J. Mayer wrote: >> >>> On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: >>> >>> Avi Kivity wrote: >>> >>> >>> >>> >> I've got a remark about this: why this has to be added to the Qemu >> code ? >> Imho, all is needed is an implementation of the -cpu option for >> x86/x86_64 target. Then, an external tool (even a shell script) can be >> used to determine what is the host CPU if you want to select the exact >> same CPU to be emulated in Qemu. It seems to me that trying to do so is >> out of the scope of Qemu code and just add unneeded complexity. >> >> >> >> > Indeed for regular qemu this is useless. But it is useful for kqemu > (for which there is support in mainline qemu), and for kvm (which we > hope to merge one day). > > > > Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as it can't trap cpuid in all circumstances. So this is mainly useful for kvm. I hope it will be applied regardless of that, as there is agreement that kvm support should be merged. I'd much rather pull the feature from qemu rather than carry it as an additional patch. >>> Still I don't understand why it's usefull to put it inside the emulator >>> and why: >>> # qemu -cpu `guess_host_cpu` >>> would not do the work properly. Adding a specific case for '-cpu host' >>> seems useless to me. >>> And this way of doing potentially work for any family of emulated >>> targets, without any modification in Qemu. If the string returned by >>> 'guess_host_cpu' is not recognized for the specific target you used it >>> with, Qemu just stops telling it cannot find this CPU model, no more, no >>> less. >>> >>> >> It's a usability issue. I agree your suggestion would work, but I'd >> like the default for kvm to be using the host cpu features, whereas >> managed environments would specify some subset to enable live migration. >> >> >>> The only case it could be interresting, imho, is if you do not allow the >>> -cpu option in KVM case and force the cpu model instead using this >>> function. This behavior does not seem to be great idea to me. >>> >>> >> I think we can move the host cpu checks to kvm-specific code, since it >> is not useful for kqemu. >> >> So, running qemu without any parameters would use host capabilities if >> kvm is available and the default qemu cpu if not. The -cpu option can >> be used to override this if necessary. >> > > Well, it may be needed to integrate the "-cpu host" option. > But I think it's a really bad idea that running qemu without the -cpu > option would not act the same on different host. When I want to test > qemu with the same command line, I want it to behave exactly the same, > whatever the host I'm running on, like any other tool. Think about gcc, > for example, if you launch it without option, it compiles for a generic > CPU. If you want to tune the generated code, even for the host you're > running on, you have to use -mcpu/-march/-mtune. Using one command line > always have gives the same result. > Then, my opinion is that running qemu without any -cpu option should > always use a default target. > That's a valid usage model. For many kvm users, however, the primary reason to run qemu is to get the performance that kvm provides, so they'd like to see host cpuid as the default. Maybe a .qemurc can help here. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Paul Brook wrote: >> Indeed for regular qemu this is useless. But it is useful for kqemu >> (for which there is support in mainline qemu), and for kvm (which we >> hope to merge one day). >> > > And, as discussed before, it should be asking the hypervisor what features it > supports instead of trying to guess from the cpuid output. > Agreed. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, Sep 25, 2007 at 03:07:44PM +0200, Jocelyn Mayer wrote: > > So, running qemu without any parameters would use host capabilities if > > kvm is available and the default qemu cpu if not. The -cpu option can > > be used to override this if necessary. > > Well, it may be needed to integrate the "-cpu host" option. > But I think it's a really bad idea that running qemu without the -cpu > option would not act the same on different host. When I want to test > qemu with the same command line, I want it to behave exactly the same, > whatever the host I'm running on, like any other tool. Think about gcc, > for example, if you launch it without option, it compiles for a generic > CPU. If you want to tune the generated code, even for the host you're > running on, you have to use -mcpu/-march/-mtune. Using one command line > always have gives the same result. > Then, my opinion is that running qemu without any -cpu option should > always use a default target. Note that in "take 3" the default is indeed to expose the "basic" default cpu features if no -cpu is specified. One must add -cpu host in order to read and expose the host cpuid. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] virtio ring implementation
On Mon, 2007-09-24 at 15:44 +0200, Dor Laor wrote:
> Rusty Russell wrote:
> > +irqreturn_t vring_interrupt(int irq, void *_vq)
> > +{
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > + pr_debug("virtqueue interrupt for %p\n", vq);
> > +
> > + if (unlikely(vq->broken))
> > + return IRQ_HANDLED;
> > +
> > + if (more_used(vq)) {
> > + pr_debug("virtqueue callback for %p (%p)\n",
> > +vq, vq->vq.callback);
> > + if (!vq->vq.callback)
> > + return IRQ_NONE;
> > + if (!vq->vq.callback(&vq->vq))
> > + vq->vring.avail->flags |=
> > VRING_AVAIL_F_NO_INTERRUPT;
> > + } else
> > + pr_debug("virtqueue %p no more used\n", vq);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> >
> Seems like there is a problem with shared irq line, the interrupt
> handler always returns IRQ_HANDLED (except for the trivial case
> were the callback is null).
To reply for a second time, this time with thought. Sorry.
Yes, this code is wrong. It should be:
irqreturn_t vring_interrupt(int irq, void *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
if (!more_used(vq)) {
pr_debug("virtqueue interrupt with no work for %p\n", vq);
return IRQ_NONE;
}
if (unlikely(vq->broken))
return IRQ_HANDLED;
pr_debug("virtqueue callback for %p (%p)\n", vq, vq->vq.callback);
if (vq->vq.callback && !vq->vq.callback(&vq->vq))
vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
return IRQ_HANDLED;
}
Cheers,
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] remove unused variable
Remove unused variable introduced by commit
5ed6627ee96f0a6802d99e71879d98610ba17e01
(I missed it, sorry)
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 585cccf..ccdd76f 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -522,7 +522,6 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
{
struct decode_cache *c = &ctxt->decode;
u8 sib, rex_prefix = 0;
- unsigned int i;
int rc = 0;
int mode = ctxt->mode;
int index_reg = 0, base_reg = 0, scale, rip_relative = 0;
--
1.5.2.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1802082 ] Networking Dies Under Heavy Load
Bugs item #1802082, was opened at 2007-09-25 09:44 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=1802082&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: Eckie Silapaswang (esila) Assigned to: Nobody/Anonymous (nobody) Summary: Networking Dies Under Heavy Load Initial Comment: Running a stress test of kvm using an EnGarde Secure Linux 1.5 guest OS. Under a heavy network email load, the guest OS networking gets knocked out - unable to ping, ssh, etc. Can only get things started again by going into vncviewer and restarting the networking services from there. CPUs: 8 x Intel(R) Xeon(R) CPU E5335 @ 2.00GHz KVM 33-4 Host Kernel: 2.6.23-rc3 Kernel Arch: x86_64 Guest OS: EnGarde Secure Linux 32bit i686, 2.4.31-1.5.60 Command Line: /usr/bin/qemu-system -hda /root/images/bwimail01.img -boot c -m 384 -smp 4 -std-vga -net nic,vlan=0,macaddr=52:54:00:12:34:6F -net tap,ifname=tap1,script=/etc/qemu-ifup -vnc 192.168.1.57:1 & Cannot boot guest with the -no-kvm switch. Can provide remote access to the guest OS if needed for debugging purposes. Any help appreciated. Best, Eckie -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1802082&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] virtio ring implementation
Rusty Russell wrote:
On Mon, 2007-09-24 at 15:44 +0200, Dor Laor wrote:
> Rusty Russell wrote:
> > +irqreturn_t vring_interrupt(int irq, void *_vq)
> > +{
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > + pr_debug("virtqueue interrupt for %p\n", vq);
> > +
> > + if (unlikely(vq->broken))
> > + return IRQ_HANDLED;
> > +
> > + if (more_used(vq)) {
> > + pr_debug("virtqueue callback for %p (%p)\n",
> > +vq, vq->vq.callback);
> > + if (!vq->vq.callback)
> > + return IRQ_NONE;
> > + if (!vq->vq.callback(&vq->vq))
> > + vq->vring.avail->flags |=
> > VRING_AVAIL_F_NO_INTERRUPT;
> > + } else
> > + pr_debug("virtqueue %p no more used\n", vq);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> >
> Seems like there is a problem with shared irq line, the interrupt
> handler always returns IRQ_HANDLED (except for the trivial case
> were the callback is null).
To reply for a second time, this time with thought. Sorry.
Yes, this code is wrong. It should be:
irqreturn_t vring_interrupt(int irq, void *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
if (!more_used(vq)) {
pr_debug("virtqueue interrupt with no work for %p\n", vq);
return IRQ_NONE;
}
if (unlikely(vq->broken))
return IRQ_HANDLED;
pr_debug("virtqueue callback for %p (%p)\n", vq, vq->vq.callback);
if (vq->vq.callback && !vq->vq.callback(&vq->vq))
vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
return IRQ_HANDLED;
}
Cheers,
Rusty.
At the moment it's not good enough, there is a potential race were the
guest optimistically turn off
the VRING_AVAIL_F_NO_INTERRUPT in the vring_restart and afterwards finds
there are more_used so
it consume them in the poll function.
If in the middle, packets arrive the host will see the flag is off and
send irq.
In that case the above irq handler will report IRQ_NONE.
It's also not trivial to cancel the optimistic approach in the restart
function since then there might be another race
that will result in missing irq reaching the guest.
I'll try to think of something better than a hypercall for switching irq
on/off.
Cheers mate,
Dor.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)
Bugs item #1802223, was opened at 2007-09-25 22:59 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=1802223&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: xeb (xebd) Assigned to: Nobody/Anonymous (nobody) Summary: nics have same hw address (rtl8139) Initial Comment: Hello! Host:Linux 2.6.22-gentoo-r2 #2 SMP Fri Aug 3 07:01:46 MSD 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux,Gentoo, kvm-44 Guest:Linux 2.6.22-hardened-r4 command line: qemu-system-x86_64 -hda server_base_x86.img -hdc server_swap.img -localtime -m 128 \ -net nic,vlan=0,macaddr=52:54:00:12:34:56,model=rtl8139 -net tap,vlan=0,ifname=tap3,script=no \ -net nic,vlan=1,macaddr=52:54:00:12:34:57,model=rtl8139 -net tap,vlan=1,ifname=tap4,script=no \ -net nic,vlan=2,macaddr=52:54:00:12:34:58,model=rtl8139 -net tap,vlan=2,ifname=tap5,script=no \ -nographic ifconfig on guest: eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:58 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0x4000 eth1 Link encap:Ethernet HWaddr 52:54:00:12:34:58 inet addr:192.168.11.1 Bcast:192.168.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:9 Base address:0x6100 eth2 Link encap:Ethernet HWaddr 52:54:00:12:34:58 inet addr:192.168.13.1 Bcast:192.168.13.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0x8200 As can you see they have same hwaddr. With model=ne2k_pci nics have correct hw addresses -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1802223&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1802227 ] network speed
Bugs item #1802227, was opened at 2007-09-25 23:07 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=1802227&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: xeb (xebd) Assigned to: Nobody/Anonymous (nobody) Summary: network speed Initial Comment: Hello. Host:Linux 2.6.22-gentoo-r2 #2 SMP Fri Aug 3 07:01:46 MSD 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux,Gentoo, kvm-44 Guest:Linux 2.6.22-hardened-r4 I have measured network speed host<->guest and it is 200-400 KB/s. Is so low speed proper for kvm ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1802227&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-40 and above: Win XP SP2 install crashes on AMD64 & 2.6.22.5-49
Hello, Starting with kvm-40, I am not able to install a Win XP SP2 guest any more. I consistently get a BSOD somewhere in the 2nd stage install. Sometimes it is IRQL_NOT_LESS_OR_EQUAL, otherwise STOP: 0x008E or STOP: 0x000A In most failure cases I also get a kernel message: emulation failed (mmio) rip 426 c4 c4 00 00 The hardware is an AMD Athlon(tm) 64 Processor 3500+ with 3G of RAM. The host is a FC6 installation with a pretty recent kernel (2.6.22.5-49) I configured kvm only with --prefix=/opt/kvm The command to run the installation was /opt/kvm/bin/qemu-system-x86_64 -no-acpi -hda /dev/Guests/xp_kvm -m 1024 -net nic,mac=00:16:3e:11:80:49,model=rtl8139 -cdrom /d/3/oe1kib/img/windows_xp_sp2_en.iso -boot d I always select the "Standard PC" HAL during install. On kvm-39 & 36, the install completes fine. On kvm-40,41,43,44 it fails with the symptoms described above. I have not tested others, but the tendency seems clear. [With -no-kvm, qemu-system-x86_64 does not crash the guest, but Win XP seems to be "Installing Devices" for the rest of its life. The session is alive, but no progress anymore. Likely a different problem] Any idea? Or even a fix? Regards, Klaus - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc8-mm1: drivers/kvm/ioapic.o build failure
Hello, Similar (the same?) as in 2.6.23-rc6-mm1? http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html CC [M] drivers/kvm/ioapic.o drivers/kvm/ioapic.c: In function 'ioapic_deliver': drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function) drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once drivers/kvm/ioapic.c:208: error: for each function it appears in.) drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function) make[2]: *** [drivers/kvm/ioapic.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 Regards, Mariusz # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm1 # Tue Sep 25 22:26:46 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # C
Re: [kvm-devel] [PATCH 2/3] virtio ring implementation
On Tue, 2007-09-25 at 19:15 +0200, Dor Laor wrote: > At the moment it's not good enough, there is a potential race were the > guest optimistically turn off > the VRING_AVAIL_F_NO_INTERRUPT in the vring_restart and afterwards > finds there are more_used so > it consume them in the poll function. > If in the middle, packets arrive the host will see the flag is off and > send irq. > In that case the above irq handler will report IRQ_NONE. Good point. On the one hand, reporting IRQ_NONE occasionally is not fatal. On the other, it'd be nice to get this right. > It's also not trivial to cancel the optimistic approach in the restart > function since then there might be another race > that will result in missing irq reaching the guest. I did it optimistically because otherwise we need two barriers (and still have a window). > I'll try to think of something better than a hypercall for switching > irq on/off. Erk. That would be v. bad... Thanks, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: x86_emulator: no writeback for bt
>-Original Message- >From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2007年9月24日 21:24 >To: He, Qing >Cc: kvm-devel >Subject: Re: [kvm-devel] [PATCH] KVM: x86_emulator: no writeback for bt > >He, Qing wrote: >> (p.s., this patch is before Laurent's patch of no_wb removal, the change >> is minor to adapt to OP_NONE) >> >> > >Applied, thanks. Does it solve some specific issue with a guest? I'll >have to send it for 2.6.23 as well if it does. No, it doesn't solve any major issue. We just found that in some occasions, apic irr is written to when this instruction is emulated. It reduces MMIO emulation overhead as well. > >-- >error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
