headers
pradeep | 1 Oct 2011 05:30
Picon

ethtool


Hello Amos, Lmr

Couple of networking tests like ethtool, file_transfer..etc are not
doing cleaning properly.  Huge files are not getting deleted after the
test. So guest running out of space for next tests. 

--Pradeep

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Nikola Ciprich | 1 Oct 2011 09:36
Picon
Favicon

Re: Re: tcpdump locks up kvm host for a while.

well, give it a try ;)
I still haven't fully resolved this, but I'm sure it has to do something with
the timesource - with kvm-clock, it got much worse...
n.

> [    1.911056] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode
> 
> Will hpet do any better?
> 
> -Robin
> 

--

-- 
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799

www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: servis <at> linuxbox.cz
-------------------------------------
Permalink | Reply | 13 comments |
headers
Robin Lee Powell | 2 Oct 2011 02:45

Re: Re: [kvm] Re: tcpdump locks up kvm host for a while.

I'm afraid clocksource=hpet didn't help much; after about 24 hours
up, tcpdump hung the machine for for about 10 seconds.  That may or
may not be better than usual; I haven't been timing things
precisely.  My suspicion is that it's slightly better, but it's
still not great.

Also:

rlpowell <at> vrici> dmesg | grep -i clock
[    0.000000] Command line: ro root=/dev/vda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0,115200 clocksource=hpet
[    0.000000] kvm-clock: Using msrs 12 and 11
[    0.000000] kvm-clock: cpu 0, msr 0:1b567c1, boot clock
[    0.000000] kvm-clock: cpu 0, msr 0:5fc137c1, primary cpu clock
[    0.000000] Kernel command line: ro root=/dev/vda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM
LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0,115200 clocksource=hpet
[    0.000000] hpet clockevent registered
[    0.260136] Switching to clocksource hpet
[    1.009393] rtc_cmos 00:01: setting system clock to 2011-10-01 07:49:50 UTC (1317455390)
[    1.821905] Refined TSC clocksource calibration: 2394.030 MHz.
[60555.473797] Clocksource tsc unstable (delta = -42950328292 ns)

(note the last line)

-Robin

On Sat, Oct 01, 2011 at 09:36:43AM +0200, Nikola Ciprich wrote:
> well, give it a try ;)
> I still haven't fully resolved this, but I'm sure it has to do something with
> the timesource - with kvm-clock, it got much worse...
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mulyadi Santosa | 2 Oct 2011 09:24
Picon

Re: [Qemu-devel] Guest freezes "Refined TSC clocksource calibration ..."

Hi..... :)

On Sat, Oct 1, 2011 at 19:16, Onkar N Mahajan <kernzap <at> gmail.com> wrote:
>
> Compiled 3.1.0-rc3+ from source (see attached config file) and updated the
> host(fc14) kernel ;
> So host is now running 3.1.0-rc3+
>
> Now I also want to try to boot FC14 guest with this updated kernel , like
> this -
>
> ./qemu-kvm-virtfs -drive file=/home/onkar/bin/v9fs-guest.img,if=virtio -m
> 1024 -smp 4 -net nic,macaddr=54:52:00:46:26:84,model=virtio -net
> tap,script=./qemu-ifup,ifname=vnet1 --enable-kvm -vnc :10 -kernel
> /boot/vmlinuz-3.1.0-rc3p -initrd /boot/initrd-3.1.0-rc3p.img -append
> 'root=UUID=97e4bdfa-c88b-4e1f-8609-10f76d6a35fa' -monitor stdio

Quite simple things you can try first:
- what if you use device name like /dev/sda1 instead? does that work?

- are you sure you have included the suitable filesystem module for
the root partition in the initrd or the main kernel image?

--

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Avi Kivity | 2 Oct 2011 10:56
Picon
Favicon

Re: Re: [kvm] Re: [kvm] Re: [kvm] Re: Questions about duplicate memory work

On 09/29/2011 09:46 PM, Robin Lee Powell wrote:
> On Thu, Sep 29, 2011 at 02:22:43PM -0300, Marcelo Tosatti wrote:
> >  On Wed, Sep 28, 2011 at 05:14:47PM -0700, Robin Lee Powell wrote:
> >  >  >  >  Please post the contents of /proc/meminfo and /proc/zoneinfo
> >  >  >  >  when this is happening.
> >  >  >
> >  >  >  I just noticed that the amount of RAM the VMs had in VIRT
> >  >  >  added up to considerably more than the host's actual RAM;
> >  >  >  hard_limit is now on.  So I may not be able to replicate this.
> >  >  >  :)
> >  >
> >  >  Or not; even with hard_limit the VIRT value goes to hundreds of
> >  >  MiB more than the limit.  Is that expected?
> >
> >  Yes, VIRT field refers to total memory mapped by the process, not
> >  paged-in memory, which is indicated by the RES field.
>
> Yes, I'm aware of that; that isn't relevant to my question.
>
> I would expect the *total* memory requested by a VM to never go over
> the hard_limit value set in the XML file.  I mean, isn't that what
> the hard_limit *means*?  If not, what does it mean?
>
>

VIRT memory includes both guest memory, and memory reserved (usually not 
used) by qemu.  Don't read too much into it.

--

-- 
error compiling committee.c: too many arguments to function
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael S. Tsirkin | 2 Oct 2011 11:11
Picon
Favicon

Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X

On Wed, Sep 28, 2011 at 09:30:51PM +0300, Sasha Levin wrote:
> On Mon, 2011-09-19 at 17:19 +0930, Rusty Russell wrote:
> > On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst <at> redhat.com> wrote:
> > > On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > > > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst <at> redhat.com> wrote:
> > > > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > > > with capability linked list?
> > > > > 
> > > > > There are any number of ways to lay out the structure.  I went for what
> > > > > seemed a simplest one.  For MSI-X the train has left the station.  We
> > > > > can probably still tweak where the high 32 bit features
> > > > > for 64 bit features are.  No idea if it's worth it.
> > > > 
> > > > Sorry, this has been in the back of my mind.  I think it's a good idea;
> > > > can we use the capability linked list for pre-device specific stuff from
> > > > now on?
> > > > 
> > > > Thanks,
> > > > Rusty.
> > > 
> > > Do we even want capability bits then?
> > > We can give each capability an ack flag ...
> > 
> > We could have, and if I'd known PCI when I designed virtio I might have.
> > 
> > But it's not easy now to map structure offsets to that scheme, and we
> > can't really force such a change on the non-PCI users.  So I'd say we
> > should only do it for the non-device-specific options.  ie. we'll still
> > have the MSI-X case move the device-specific config, but we'll use a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prateek Sharma | 2 Oct 2011 11:43
Picon

Dirty page tracking in EPT

Hello ,
    I came across the dirty-page tracking patch here:
[https://lkml.org/lkml/2011/6/21/169] .
There is some mention of dirty-bit tracking not working with EPT. Can
someone please clarify this? Does this patch only work when using
software shadow page tables ?

   On a related note (i've asked a related question on this list a
couple of days back), why can we not use the
kvm_vm_ioctl_get_dirty_log function
[http://lxr.linux.no/#linux+v3.0/arch/x86/kvm/x86.c#L3297] ?  Is it
because it is too expensive? If yes, can we use the dirty-page
tracking ideas in this patch and use it for the migration code?

Thanks for reading,
Prateek
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Avi Kivity | 2 Oct 2011 11:51
Picon
Favicon

[PATCH] KVM: Fix tsc deadline timer without irqchip_in_kernel()

vcpu->arch.apic may be NULL.

Signed-off-by: Avi Kivity <avi <at> redhat.com>
---
 arch/x86/kvm/x86.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 83b839f..aa11707 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
 <at>  <at>  -600,6 +600,8  <at>  <at>  static bool guest_cpuid_has_fsgsbase(struct kvm_vcpu *vcpu)
 static void update_cpuid(struct kvm_vcpu *vcpu)
 {
 	struct kvm_cpuid_entry2 *best;
+	struct kvm_lapic *apic = vcpu->arch.apic;
+	u32 timer_mode_mask;

 	best = kvm_find_cpuid_entry(vcpu, 1, 0);
 	if (!best)
 <at>  <at>  -615,9 +617,12  <at>  <at>  static void update_cpuid(struct kvm_vcpu *vcpu)
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
 		best->function == 0x1) {
 		best->ecx |= bit(X86_FEATURE_TSC_DEADLINE_TIMER);
-		vcpu->arch.apic->lapic_timer.timer_mode_mask = (3 << 17);
+		timer_mode_mask = 3 << 17;
 	} else
-		vcpu->arch.apic->lapic_timer.timer_mode_mask = (1 << 17);
+		timer_mode_mask = 1 << 17;
+
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael S. Tsirkin | 2 Oct 2011 11:56
Picon
Favicon

Re: [PATCH] qemu-kvm: device assignment: add 82599 PCIe Cap struct quirk

On Wed, Sep 28, 2011 at 08:20:33PM -0400, Donald Dutile wrote:
> commit f9c29774d2174df6ffc20becec20928948198914
> changed the PCIe Capability structure version check
> from if > 2 fail, to if ==1, size=x, if ==2, size=y,
> else fail.
> Turns out the 82599's VF has an errata where it's
> PCIe Cap struct version is 0, which now fails device assignment
> due to the else fallout, where before, it would blissfully work.
> 
> Add a quirk if version=0, & intel-82599, set size to version 2 struct.
> 
> Signed-off-by: Donald_Dutile <ddutile <at> redhat.com>

Makes sense.

Nit: please use PCI_VENDOR_ID_INTEL instead of 0x8086 below.

> ---
>  hw/device-assignment.c |   12 ++++++++++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 288f80c..ed2a883 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
>  <at>  <at>  -1261,12 +1261,20  <at>  <at>  static int assigned_device_pci_cap_init(PCIDevice *pci_dev)
>  
>      if ((pos = pci_find_cap_offset(pci_dev, PCI_CAP_ID_EXP, 0))) {
>          uint8_t version, size;
> -        uint16_t type, devctl, lnkcap, lnksta;
(Continue reading)

Permalink | Reply | 1 comment |

Gmane