date:20100127

On Tue, Jan 26, 2010 at 02:50:28PM -0600, Anthony Liguori wrote:
 On 01/26/2010 02:47 PM, Anthony Liguori wrote:
 On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
 This patch adds raw socket backend to qemu and is based on Or Gerlitz's
 patch re-factored and ported to the latest qemu-kvm git tree.
 It also includes support for vnet_hdr option that enables gso/checksum
 offload with raw backend. You can find the linux kernel patch to support
 this feature here.
 http://thread.gmane.org/gmane.linux.network/150308

 Signed-off-by: Sridhar Samudralas...@us.ibm.com

 See the previous discussion about the raw backend from Or's original  
 patch.  There's no obvious reason why we should have this in addition  
 to a tun/tap backend.

I thought this was cleared already: vepa support is the requirement
here.  Existing tap solution requires management of host linux
networking which some users would rather avoid.

 The only use-case I know of is macvlan but macvtap addresses this  
 functionality while not introduce the rather nasty security problems  
 associated with a raw backend.

I am not sure I agree with this sentiment.  The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can work with any network card in promisc mode.

 Not to mention that from a user perspective, raw makes almost no sense  
 as it's an obscure socket protocol family.

 A user wants to do useful things like bridged networking or direct VF  
 assignment.  We should have -net backends that reflect things that make  
 sense to a user.

 Regards,

 Anthony Liguori


I agree to that. People don't even seem to agree whether it's a raw
socket or a packet socket :) We need a better name for this option: what
it really does is rely on an external device to loopback a packet to us,
so how about -net loopback or -net extbridge?

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

2010-01-27 Thread Arnd Bergmann

On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
 I am not sure I agree with this sentiment.  The main issue being that
 macvtap doesn't exist on all kernels :). macvlan also requires hardware
 support, packet socket can work with any network card in promisc mode.

To be clear, macvlan does not require hardware support, it will happily
put cards into promiscous mode if they don't support multiple mac addresses.

 I agree to that. People don't even seem to agree whether it's a raw
 socket or a packet socket :) We need a better name for this option: what
 it really does is rely on an external device to loopback a packet to us,
 so how about -net loopback or -net extbridge?

I think -net socket,fd should just be (trivially) extended to work with raw
sockets out of the box, with no support for opening it. Then you can have
libvirt or some wrapper open a raw socket and a private namespace and just pass 
it
down. If you really want to let qemu open the socket itself, -net 
socket,raw=eth0
is probably closer to what you want than a new -net xxx option.

Arnd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Autotest] [Autotest PATCH] KVM-test: Add a subtest 'qemu_img'

2010-01-27 Thread Yolkfull Chow

On Tue, Jan 26, 2010 at 03:11:34PM -0200, Lucas Meneghel Rodrigues wrote:
 On Tue, 2010-01-26 at 11:25 +0800, Yolkfull Chow wrote:
  This is designed to test all subcommands of 'qemu-img' however
  so far 'commit' is not implemented.
 
 Hi Yolkful, this is very good! Seeing this test made me think about that
 stand alone autotest module we commited a while ago, that does
 qemu_iotests testsuite on the host.
 
 Perhaps we could 'port' this module to the kvm test, since it is more

Lucas, do you mean the client-side 'kvmtest' ?

And thanks for comments. :)

 convenient to execute it inside a kvm test job (in a job where we test
 more than 2 build types, for example, we need to execute qemu_img and
 qemu_io_tests for every qemu-img built).
 
 Could you look at implementing this?
 
  * For 'check' subcommand test, it will 'dd' to create a file with specified
  size and see whether it's supported to be checked. Then convert it to be
  supported formats (qcow2 and raw so far) to see whether there's error
  after convertion.
  
  * For 'convert' subcommand test, it will convert both to 'qcow2' and 'raw' 
  from
  the format specified in config file. And only check 'qcow2' after 
  convertion.
  
  * For 'snapshot' subcommand test, it will create two snapshots and list 
  them.
  Finally delete them if no errors found.
  
  * For 'info' subcommand test, it simply get output from specified image 
  file.
  
  Signed-off-by: Yolkfull Chow yz...@redhat.com
  ---
   client/tests/kvm/tests/qemu_img.py |  155 
  
   client/tests/kvm/tests_base.cfg.sample |   36 
   2 files changed, 191 insertions(+), 0 deletions(-)
   create mode 100644 client/tests/kvm/tests/qemu_img.py
  
  diff --git a/client/tests/kvm/tests/qemu_img.py 
  b/client/tests/kvm/tests/qemu_img.py
  new file mode 100644
  index 000..1ae04f0
  --- /dev/null
  +++ b/client/tests/kvm/tests/qemu_img.py
  @@ -0,0 +1,155 @@
  +import os, logging, commands
  +from autotest_lib.client.common_lib import error
  +import kvm_vm
  +
  +
  +def run_qemu_img(test, params, env):
  +
  +`qemu-img' functions test:
  +1) Judge what subcommand is going to be tested
  +2) Run subcommand test
  +
  +@param test: kvm test object
  +@param params: Dictionary with the test parameters
  +@param env: Dictionary with test environment.
  +
  +cmd = params.get(qemu_img_binary)
 
 It is a good idea to verify if cmd above resolves to an absolute path,
 to avoid problems. If it doesn't resolve, verify if there's the symbolic
 link under kvm test dir pointing to qemu-img, and if it does exist, make
 sure it points to a valid file (ie, symlink is not broken).
 
  +subcommand = params.get(subcommand)
  +image_format = params.get(image_format)
  +image_name = kvm_vm.get_image_filename(params, test.bindir)
  +
  +def check(img):
  +global cmd
  +cmd +=  check %s % img
  +logging.info(Checking image '%s'... % img)
  +s, o = commands.getstatusoutput(cmd)
  +if not (s == 0 or does not support checks in o):
  +return (False, o)
  +return (True, )
 
 Please use utils.system_output here instead of the equivalent commands
 API on the above code. This comment applies to all further uses of
 commands.[function].
 
  +
  +# Subcommand 'qemu-img check' test
  +# This tests will 'dd' to create a specified size file, and check it.
  +# Then convert it to supported image_format in each loop and check 
  again.
  +def check_test():
  +size = params.get(dd_image_size)
  +test_image = params.get(dd_image_name)
  +create_image_cmd = params.get(create_image_cmd)
  +create_image_cmd = create_image_cmd % (test_image, size)
  +s, o = commands.getstatusoutput(create_image_cmd)
  +if s != 0:
  +raise error.TestError(Failed command: %s; Output is: %s %
  + (create_image_cmd, o))
  +s, o = check(test_image)
  +if not s:
  +raise error.TestFail(Failed to check image '%s' with error: 
  %s %
  +  (test_image, 
  o))
  +for fmt in params.get(supported_image_formats).split():
  +output_image = test_image + .%s % fmt
  +convert(fmt, test_image, output_image)
  +s, o = check(output_image)
  +if not s:
  +raise error.TestFail(Check image '%s' got error: %s %
  + (output_image, o))
  +commands.getoutput(rm -f %s % output_image)
  +commands.getoutput(rm -f %s % test_image)
  +#Subcommand 'qemu-img create' test
  +def create_test():
  +global cmd
 
 I don't like very much this idea of using a global variable, instead it
 should be preferrable to use a class and have a class attribute with
 'cmd'.

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

On Wed, Jan 27, 2010 at 10:34:35AM +0100, Arnd Bergmann wrote:
 On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
  I am not sure I agree with this sentiment.  The main issue being that
  macvtap doesn't exist on all kernels :). macvlan also requires hardware
  support, packet socket can work with any network card in promisc mode.
 
 To be clear, macvlan does not require hardware support, it will happily
 put cards into promiscous mode if they don't support multiple mac addresses.
 
  I agree to that. People don't even seem to agree whether it's a raw
  socket or a packet socket :) We need a better name for this option: what
  it really does is rely on an external device to loopback a packet to us,
  so how about -net loopback or -net extbridge?
 
 I think -net socket,fd should just be (trivially) extended to work with raw
 sockets out of the box, with no support for opening it. Then you can have
 libvirt or some wrapper open a raw socket and a private namespace and just 
 pass it
 down.

That'd work. Anthony?

 If you really want to let qemu open the socket itself, -net socket,raw=eth0
 is probably closer to what you want than a new -net xxx option.
 
   Arnd

So again if implemented this probably should be 
-net socket,raw,loopback=eth0 or -net socket,raw,extbridge=eth0
or some such, just to make it abundantly clear that you must not bind it
to a regular ethernet device.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] Export the symbol of getboottime and monotonic_to_bootbased

2010-01-27 Thread Jason Wang

Export getboottime and monotonic_to_bootbased in order to let them
could be used by following patch.

Signed-off-by: Jason Wang jasow...@redhat.com
---
 kernel/time/timekeeping.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 7faaa32..e2ab064 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -880,6 +880,7 @@ void getboottime(struct timespec *ts)
 
set_normalized_timespec(ts, -boottime.tv_sec, -boottime.tv_nsec);
 }
+EXPORT_SYMBOL_GPL(getboottime);
 
 /**
  * monotonic_to_bootbased - Convert the monotonic time to boot based.
@@ -889,6 +890,7 @@ void monotonic_to_bootbased(struct timespec *ts)
 {
*ts = timespec_add_safe(*ts, total_sleep_time);
 }
+EXPORT_SYMBOL_GPL(monotonic_to_bootbased);
 
 unsigned long get_seconds(void)
 {

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] kvmclock: count total_sleep_time when updating guest clock

2010-01-27 Thread Jason Wang

Current kvm wallclock does not consider the total_sleep_time which could cause
wrong wallclock in guest after host suspend/resume. This patch solve
this issue by counting total_sleep_time to get the correct host boot time.

Signed-off-by: Jason Wang jasow...@redhat.com
---
 arch/x86/kvm/x86.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ac8672f..d47ceda 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -723,7 +723,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t 
wall_clock)
 {
static int version;
struct pvclock_wall_clock wc;
-   struct timespec now, sys, boot;
+   struct timespec boot;
 
if (!wall_clock)
return;
@@ -738,9 +738,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t 
wall_clock)
 * wall clock specified here.  guest system time equals host
 * system time for us, thus we must fill in host boot time here.
 */
-   now = current_kernel_time();
-   ktime_get_ts(sys);
-   boot = ns_to_timespec(timespec_to_ns(now) - timespec_to_ns(sys));
+   getboottime(boot);
 
wc.sec = boot.tv_sec;
wc.nsec = boot.tv_nsec;
@@ -815,6 +813,7 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
local_irq_save(flags);
kvm_get_msr(v, MSR_IA32_TSC, vcpu-hv_clock.tsc_timestamp);
ktime_get_ts(ts);
+   monotonic_to_bootbased(ts);
local_irq_restore(flags);
 
/* With all the info we got, fill in the values */

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Autotest] [Autotest PATCH] KVM-test: Add a subtest image_copy

2010-01-27 Thread Lucas Meneghel Rodrigues

On Wed, 2010-01-27 at 11:43 +0800, Yolkfull Chow wrote:
 On Tue, Jan 26, 2010 at 02:04:09PM -0200, Lucas Meneghel Rodrigues wrote:
  Yolkfull, I am copying Michael and Lawrence on the e-mail so they can
  comment on the points I am going to present.
 
 Lucas, firstly thank you very much for addressing your viewpoints and the
 coding/logical suggestions. Most of them are reasonable and appreciated
 except that I also have an improvidence about point 3):
 
 Your idea on executing image_copy as a backup of unattended_install is good.
 But I think we could also seperate 'unattended_install' from test set of
 functional testing and encapsulate it into Installation testing set.
 In this way the following functional test cases will not be affected by
 failed installation tests.
 
 What do you think about this?

I believe this could be implemented by simply removing the dependency.
However, if *no* install test succeed whatsoever, then we don't have any
way to perform the subsequent tests. So I don't know how to implement
this idea.

Please explain me how that encapsulation would work.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Autotest] [Autotest PATCH] KVM-test: Add a subtest 'qemu_img'

2010-01-27 Thread Lucas Meneghel Rodrigues

On Wed, 2010-01-27 at 17:41 +0800, Yolkfull Chow wrote:
 On Tue, Jan 26, 2010 at 03:11:34PM -0200, Lucas Meneghel Rodrigues wrote:
  On Tue, 2010-01-26 at 11:25 +0800, Yolkfull Chow wrote:
   This is designed to test all subcommands of 'qemu-img' however
   so far 'commit' is not implemented.
  
  Hi Yolkful, this is very good! Seeing this test made me think about that
  stand alone autotest module we commited a while ago, that does
  qemu_iotests testsuite on the host.
  
  Perhaps we could 'port' this module to the kvm test, since it is more
 
 Lucas, do you mean the client-side 'kvmtest' ?

I mean, client/tests/kvm. Sorry I wasn't clear enough.



--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How to use VMDq in KVM?

2010-01-27 Thread Yang Yang

Hi list,

I have a box with Intel 82575EB NIC and VT-d. I can assign the NIC to
guest successfully by following the HOWTO of linux-kvm.org, and it
works well.

Later I found that the 82575 card also supports VMDq, so I search the
Internet for some help.
But there are only 2 articles I've found:
one is something from Intel:
http://kvm.et.redhat.com/wiki/images/6/6a/KvmForum2008$kdf2008_7.pdf
the other is :
http://thread.gmane.org/gmane.linux.kernel.mm/38508

These 2 articles describe the way of how VMDq+virtio_net works, but no
user guide
So I still don't know how to use the VMDq feature with KVM, are there
any documents describe this?


Thanks a lot!

-- 
regards,

Y.Yang
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] kvmclock: count total_sleep_time when updating guest clock

2010-01-27 Thread Glauber Costa

On Wed, Jan 27, 2010 at 07:13:49PM +0800, Jason Wang wrote:
 Current kvm wallclock does not consider the total_sleep_time which could cause
 wrong wallclock in guest after host suspend/resume. This patch solve
 this issue by counting total_sleep_time to get the correct host boot time.
 
 Signed-off-by: Jason Wang jasow...@redhat.com
This makes sense to me.

Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Autotest] [Autotest PATCH] KVM-test: Add a subtest 'qemu_img'

2010-01-27 Thread Michael Goldish


- Yolkfull Chow yz...@redhat.com wrote:

 On Tue, Jan 26, 2010 at 03:11:34PM -0200, Lucas Meneghel Rodrigues
 wrote:
  On Tue, 2010-01-26 at 11:25 +0800, Yolkfull Chow wrote:
   This is designed to test all subcommands of 'qemu-img' however
   so far 'commit' is not implemented.
  
  Hi Yolkful, this is very good! Seeing this test made me think about
 that
  stand alone autotest module we commited a while ago, that does
  qemu_iotests testsuite on the host.
  
  Perhaps we could 'port' this module to the kvm test, since it is
 more
 
 Lucas, do you mean the client-side 'kvmtest' ?
 
 And thanks for comments. :)
 
  convenient to execute it inside a kvm test job (in a job where we
 test
  more than 2 build types, for example, we need to execute qemu_img
 and
  qemu_io_tests for every qemu-img built).
  
  Could you look at implementing this?
  
   * For 'check' subcommand test, it will 'dd' to create a file with
 specified
   size and see whether it's supported to be checked. Then convert it
 to be
   supported formats (qcow2 and raw so far) to see whether there's
 error
   after convertion.
   
   * For 'convert' subcommand test, it will convert both to 'qcow2'
 and 'raw' from
   the format specified in config file. And only check 'qcow2' after
 convertion.
   
   * For 'snapshot' subcommand test, it will create two snapshots and
 list them.
   Finally delete them if no errors found.
   
   * For 'info' subcommand test, it simply get output from specified
 image file.
   
   Signed-off-by: Yolkfull Chow yz...@redhat.com
   ---
client/tests/kvm/tests/qemu_img.py |  155
 
client/tests/kvm/tests_base.cfg.sample |   36 
2 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/tests/qemu_img.py
   
   diff --git a/client/tests/kvm/tests/qemu_img.py
 b/client/tests/kvm/tests/qemu_img.py
   new file mode 100644
   index 000..1ae04f0
   --- /dev/null
   +++ b/client/tests/kvm/tests/qemu_img.py
   @@ -0,0 +1,155 @@
   +import os, logging, commands
   +from autotest_lib.client.common_lib import error
   +import kvm_vm
   +
   +
   +def run_qemu_img(test, params, env):
   +
   +`qemu-img' functions test:
   +1) Judge what subcommand is going to be tested
   +2) Run subcommand test
   +
   +@param test: kvm test object
   +@param params: Dictionary with the test parameters
   +@param env: Dictionary with test environment.
   +
   +cmd = params.get(qemu_img_binary)
  
  It is a good idea to verify if cmd above resolves to an absolute
 path,
  to avoid problems. If it doesn't resolve, verify if there's the
 symbolic
  link under kvm test dir pointing to qemu-img, and if it does exist,
 make
  sure it points to a valid file (ie, symlink is not broken).

This can be done quickly using kvm_utils.get_path() and os.path.exists(),
like this:

cmd = kvm_utils.get_path(params.get(qemu_img_binary))
if not os.path.exists(cmd):
raise error.TestError(qemu-img binary not found)

kvm_utils.get_path() is the standard way of getting both absolute and
relative paths, and os.path.exists() checks whether the file exists and
makes sure it's not a broken symlink.

   +subcommand = params.get(subcommand)
   +image_format = params.get(image_format)
   +image_name = kvm_vm.get_image_filename(params, test.bindir)
   +
   +def check(img):
   +global cmd
   +cmd +=  check %s % img
   +logging.info(Checking image '%s'... % img)
   +s, o = commands.getstatusoutput(cmd)
   +if not (s == 0 or does not support checks in o):
   +return (False, o)
   +return (True, )
  
  Please use utils.system_output here instead of the equivalent
 commands
  API on the above code. This comment applies to all further uses of
  commands.[function].
  
   +
   +# Subcommand 'qemu-img check' test
   +# This tests will 'dd' to create a specified size file, and
 check it.
   +# Then convert it to supported image_format in each loop and
 check again.
   +def check_test():
   +size = params.get(dd_image_size)
   +test_image = params.get(dd_image_name)
   +create_image_cmd = params.get(create_image_cmd)
   +create_image_cmd = create_image_cmd % (test_image, size)
   +s, o = commands.getstatusoutput(create_image_cmd)
   +if s != 0:
   +raise error.TestError(Failed command: %s; Output is:
 %s %
   +
 (create_image_cmd, o))
   +s, o = check(test_image)
   +if not s:
   +raise error.TestFail(Failed to check image '%s' with
 error: %s %
   + 
 (test_image, o))
   +for fmt in
 params.get(supported_image_formats).split():
   +output_image = test_image + .%s % fmt
   +convert(fmt, test_image, output_image)
   +s,

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu


On 01/27/2010 03:44 AM, Michael S. Tsirkin wrote:

On Wed, Jan 27, 2010 at 10:34:35AM +0100, Arnd Bergmann wrote:
   

On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
 

I am not sure I agree with this sentiment.  The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can work with any network card in promisc mode.
   

To be clear, macvlan does not require hardware support, it will happily
put cards into promiscous mode if they don't support multiple mac addresses.

 

I agree to that. People don't even seem to agree whether it's a raw
socket or a packet socket :) We need a better name for this option: what
it really does is rely on an external device to loopback a packet to us,
so how about -net loopback or -net extbridge?
   

I think -net socket,fd should just be (trivially) extended to work with raw
sockets out of the box, with no support for opening it. Then you can have
libvirt or some wrapper open a raw socket and a private namespace and just pass 
it
down.
 

That'd work. Anthony?
   


What functionality are we trying to achieve?  Let's be very specific 
about use-cases here.  If it's VEPA, like you mentioned earlier, why 
isn't macvtap a better solution from a security perspective?


The fundamental problem that I have with all of this is that we should 
not be introducing new network backends that are based around something 
only a developer is going to understand.  If I'm a user and I want to 
use an external switch in VEPA mode, how in the world am I going to know 
that I'm supposed to use the -net raw backend or the -net socket 
backend?  It might as well be the -net butterflies backend as far as a 
user is concerned.


Networking in QEMU is already hard enough for users, we shouldn't make 
it worse than it already is.


Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Windows Vista/7 repeatedly prompt to Set Network Location

2010-01-27 Thread Chris Lalancette

On 01/26/2010 11:22 PM, Jamin W. Collins wrote:
Every time I start a Windows Vista or Windows 7 virtual machine it
request a that a location be set for the network, regardless of the fact
that the network location has already been set the same way every time
the system is started. Near as I can tell the VM's NIC MAC, IP address,
DNS servers, default gateway, and all other network related items are
the same every single time. While this does not stop the VM from
working it is annoying.

I'm starting the VM the same way through libvirt every single time. The
resultant kvm command line is:

/usr/bin/kvm -S -M pc-0.11 -cpu qemu32 -enable-kvm -m 1536 -smp 1 -name
win7 -uuid 6671f42a-b974-6bb9-bd7e-fd1da95cabe5 -monitor
unix:/var/lib/libvirt/qemu/win7.monitor,server,nowait -localtime -boot c
-drive file=/media/devel/testing/win7/testing.img,if=ide,index=0,boot=on
-drive
file=/media/devel/testing/isos/en_windows_7_professional_x86_dvd_x15-65804.iso,if=ide,media=cdrom,index=2
-net nic,macaddr=54:52:00:37:4a:ce,vlan=0,model=rtl8139,name=rtl8139.0
-net tap,fd=38,vlan=0,name=tap.0 -serial pty -parallel none -usb
-usbdevice tablet -vga cirrus

While the uuid isn't the same from one execution to the next, to my
knowledge it's not something the VM ever sees and is only an identifier
within KVM. Has anyone else seen anything like this?

Actually, that's not true (if I remember correctly). The uuid is exposed to
the guest
via the SMBIOS tables, so that might be causing the problem. Try setting the
UUID in the libvirt XML, and that may solve it.

--
Chris Lalancette
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu


On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:

I am not sure I agree with this sentiment.  The main issue being that
macvtap doesn't exist on all kernels :).


Neither does vhost ;-)  If it were just that as the difference, I'd be 
inclined to agree, but macvtap is much better from a security PoV.



Not to mention that from a user perspective, raw makes almost no sense
as it's an obscure socket protocol family.

A user wants to do useful things like bridged networking or direct VF
assignment.  We should have -net backends that reflect things that make
sense to a user.

Regards,

Anthony Liguori
 


I agree to that. People don't even seem to agree whether it's a raw
socket or a packet socket :) We need a better name for this option: what
it really does is rely on an external device to loopback a packet to us,
so how about -net loopback or -net extbridge?
   


Specifically for VEPA, something like:

-net extbridge,if=eth0

or even

-net vepa,if=eth0

Would be fantastic.  I think the best way to achieve this is to 
introduce a small helper that gets called and can create a macvtap 
device and hand the file descriptor back to qemu :-)  A builtin backend 
would also be fine since we don't have the helper infrastructure.


Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Windows Vista/7 repeatedly prompt to Set Network Location

2010-01-27 Thread Jamin W. Collins


Chris Lalancette wrote:

On 01/26/2010 11:22 PM, Jamin W. Collins wrote:


While the uuid isn't the same from one execution to the next, to my
knowledge it's not something the VM ever sees and is only an identifier
within KVM.  Has anyone else seen anything like this?


Actually, that's not true (if I remember correctly).  The uuid is exposed to 
the guest
via the SMBIOS tables, so that might be causing the problem.  Try setting the
UUID in the libvirt XML, and that may solve it.


Even with the UUID defined in the XML I'm still repeatedly getting the 
prompt to define the network location.  If I simply reboot the virtual 
machine all is well.  However, if I actually shut the virtual machine 
down, on the next startup it will ask for the network location type.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH] KVM: Introduce modification context for cpu_synchronize_state

2010-01-27 Thread Jan Kiszka

This patch originates in the mp_state writeback issue: During runtime
and even on reset, we must not write the previously saved VCPU state
back into the kernel in an uncontrolled fashion. E.g mp_state should
only written on reset or on VCPU setup. Certain clocks (e.g. the TSC)
may only be written on setup or after vmload.

By introducing additional information about the context of the planned
vcpu state manipulation, we can simply skip sensitive states like
mp_state when updating the in-kernel state. The planned modifications
are defined when calling cpu_synchronize_state. They accumulate, ie.
once a full writeback was requested, it will stick until it was
performed.

This patch already fixes existing writeback issues in upstream KVM by
only selectively writing MSR_IA32_TSC, MSR_KVM_SYSTEM_TIME,
MSR_KVM_WALL_CLOCK, the mp_state and the vcpu_events.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---

This patch is intentionally written against uq/master. As upstream is
less convoluted (yet :) ), it may help understanding the basic idea. An
add-on patch for qemu-kvm that both cleans up the current code and also
moves kvm_get/set_lapic into kvm_arch_get/put_registers (hmm, maybe also
renaming that services...) will follow soon if no one sees fundamental
problems of this approach.

 exec.c|4 ++--
 gdbstub.c |   10 +-
 hw/apic.c |2 +-
 hw/ppc_newworld.c |2 +-
 hw/ppc_oldworld.c |2 +-
 hw/s390-virtio.c  |2 +-
 kvm-all.c |   31 +++
 kvm.h |   13 +
 monitor.c |4 ++--
 target-i386/helper.c  |2 +-
 target-i386/kvm.c |   31 +++
 target-i386/machine.c |4 ++--
 target-ppc/kvm.c  |2 +-
 target-ppc/machine.c  |4 ++--
 target-s390x/kvm.c|   17 -
 15 files changed, 78 insertions(+), 52 deletions(-)

diff --git a/exec.c b/exec.c
index 6875370..5a83922 100644
--- a/exec.c
+++ b/exec.c
@@ -521,14 +521,14 @@ static void cpu_common_pre_save(void *opaque)
 {
 CPUState *env = opaque;
 
-cpu_synchronize_state(env);
+cpu_synchronize_state(env, CPU_MODIFY_NONE);
 }
 
 static int cpu_common_pre_load(void *opaque)
 {
 CPUState *env = opaque;
 
-cpu_synchronize_state(env);
+cpu_synchronize_state(env, CPU_MODIFY_INIT);
 return 0;
 }
 
diff --git a/gdbstub.c b/gdbstub.c
index 80477be..8caae15 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1653,7 +1653,7 @@ static void gdb_breakpoint_remove_all(void)
 static void gdb_set_cpu_pc(GDBState *s, target_ulong pc)
 {
 #if defined(TARGET_I386)
-cpu_synchronize_state(s-c_cpu);
+cpu_synchronize_state(s-c_cpu, CPU_MODIFY_RUNTIME);
 s-c_cpu-eip = pc;
 #elif defined (TARGET_PPC)
 s-c_cpu-nip = pc;
@@ -1678,7 +1678,7 @@ static void gdb_set_cpu_pc(GDBState *s, target_ulong pc)
 #elif defined (TARGET_ALPHA)
 s-c_cpu-pc = pc;
 #elif defined (TARGET_S390X)
-cpu_synchronize_state(s-c_cpu);
+cpu_synchronize_state(s-c_cpu, CPU_MODIFY_RUNTIME);
 s-c_cpu-psw.addr = pc;
 #endif
 }
@@ -1848,7 +1848,7 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 }
 break;
 case 'g':
-cpu_synchronize_state(s-g_cpu);
+cpu_synchronize_state(s-g_cpu, CPU_MODIFY_NONE);
 len = 0;
 for (addr = 0; addr  num_g_regs; addr++) {
 reg_size = gdb_read_register(s-g_cpu, mem_buf + len, addr);
@@ -1858,7 +1858,7 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 put_packet(s, buf);
 break;
 case 'G':
-cpu_synchronize_state(s-g_cpu);
+cpu_synchronize_state(s-g_cpu, CPU_MODIFY_RUNTIME);
 registers = mem_buf;
 len = strlen(p) / 2;
 hextomem((uint8_t *)registers, p, len);
@@ -2022,7 +2022,7 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 thread = strtoull(p+16, (char **)p, 16);
 env = find_cpu(thread);
 if (env != NULL) {
-cpu_synchronize_state(env);
+cpu_synchronize_state(env, CPU_MODIFY_NONE);
 len = snprintf((char *)mem_buf, sizeof(mem_buf),
CPU#%d [%s], env-cpu_index,
env-halted ? halted  : running);
diff --git a/hw/apic.c b/hw/apic.c
index 87e7dc0..3562ad5 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -938,7 +938,7 @@ static void apic_reset(void *opaque)
 APICState *s = opaque;
 int bsp;
 
-cpu_synchronize_state(s-cpu_env);
+cpu_synchronize_state(s-cpu_env, CPU_MODIFY_RESET);
 
 bsp = cpu_is_bsp(s-cpu_env);
 s-apicbase = 0xfee0 |
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index a4c714a..6e33c47 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -140,7 +140,7 @@ static void ppc_core99_init (ram_addr_t ram_size,
 }
 
 /* Make sure all register sets take effect */
-

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:
 On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
 I am not sure I agree with this sentiment.  The main issue being that
 macvtap doesn't exist on all kernels :).

 Neither does vhost ;-)  If it were just that as the difference, I'd be  
 inclined to agree, but macvtap is much better from a security PoV.

 Not to mention that from a user perspective, raw makes almost no sense
 as it's an obscure socket protocol family.

 A user wants to do useful things like bridged networking or direct VF
 assignment.  We should have -net backends that reflect things that make
 sense to a user.

 Regards,

 Anthony Liguori
  

 I agree to that. People don't even seem to agree whether it's a raw
 socket or a packet socket :) We need a better name for this option: what
 it really does is rely on an external device to loopback a packet to us,
 so how about -net loopback or -net extbridge?


 Specifically for VEPA, something like:

 -net extbridge,if=eth0

 or even

 -net vepa,if=eth0

 Would be fantastic.

extbridge is IMO better.

 I think the best way to achieve this is to  
 introduce a small helper that gets called and can create a macvtap  
 device and hand the file descriptor back to qemu :-)  A builtin backend  
 would also be fine since we don't have the helper infrastructure.

Excellent.
Sridhar, this is actually not a lot of work on top of what you
already posted.

 Regards,

 Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu


On 01/27/2010 10:59 AM, Michael S. Tsirkin wrote:

On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:
   

On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
 

I am not sure I agree with this sentiment.  The main issue being that
macvtap doesn't exist on all kernels :).
   

Neither does vhost ;-)  If it were just that as the difference, I'd be
inclined to agree, but macvtap is much better from a security PoV.

 

Not to mention that from a user perspective, raw makes almost no sense
as it's an obscure socket protocol family.

A user wants to do useful things like bridged networking or direct VF
assignment.  We should have -net backends that reflect things that make
sense to a user.

Regards,

Anthony Liguori

 

I agree to that. People don't even seem to agree whether it's a raw
socket or a packet socket :) We need a better name for this option: what
it really does is rely on an external device to loopback a packet to us,
so how about -net loopback or -net extbridge?

   

Specifically for VEPA, something like:

-net extbridge,if=eth0

or even

-net vepa,if=eth0

Would be fantastic.
 

extbridge is IMO better.

   

I think the best way to achieve this is to
introduce a small helper that gets called and can create a macvtap
device and hand the file descriptor back to qemu :-)  A builtin backend
would also be fine since we don't have the helper infrastructure.
 

Excellent.
Sridhar, this is actually not a lot of work on top of what you
already posted.

   


N.B.  I had suggested using macvtap, not raw.  In this case, the full 
syntax would be:


-net vepa,if=eth0

or

-net vepa,fd=N

where N is a macvtap fd.

For raw, I think there's a real problem wrt security.  I think it's 
important that we support running qemu as a non-privileged user.  In 
fact, this seems to be the mode libvirt is now preferring to operate in.


I think we need to re-evaluate the use of any raw socket by qemu as it's 
very dangerous from a security perspective (assuming we cannot 
introduced a locked raw socket mode).


Regards,

Anthony Liguori


Regards,

Anthony Liguori
 


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

On Wed, Jan 27, 2010 at 11:07:45AM -0600, Anthony Liguori wrote:
 On 01/27/2010 10:59 AM, Michael S. Tsirkin wrote:
 On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:

 On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
  
 I am not sure I agree with this sentiment.  The main issue being that
 macvtap doesn't exist on all kernels :).

 Neither does vhost ;-)  If it were just that as the difference, I'd be
 inclined to agree, but macvtap is much better from a security PoV.

  
 Not to mention that from a user perspective, raw makes almost no sense
 as it's an obscure socket protocol family.

 A user wants to do useful things like bridged networking or direct VF
 assignment.  We should have -net backends that reflect things that make
 sense to a user.

 Regards,

 Anthony Liguori

  
 I agree to that. People don't even seem to agree whether it's a raw
 socket or a packet socket :) We need a better name for this option: what
 it really does is rely on an external device to loopback a packet to us,
 so how about -net loopback or -net extbridge?


 Specifically for VEPA, something like:

 -net extbridge,if=eth0

 or even

 -net vepa,if=eth0

 Would be fantastic.
  
 extbridge is IMO better.


 I think the best way to achieve this is to
 introduce a small helper that gets called and can create a macvtap
 device and hand the file descriptor back to qemu :-)  A builtin backend
 would also be fine since we don't have the helper infrastructure.
  
 Excellent.
 Sridhar, this is actually not a lot of work on top of what you
 already posted.



 N.B.  I had suggested using macvtap, not raw.

Well, this is an implementation detail :) In fact, I don't have any
objections to using macvtap.  As I tried to hint, macvtap doesn't seem
to exist in any Linux yet, packet sockets have been supported since
ages. So we might want to support packet sockets at least optionally
as a backend for extbridge.

  In this case, the full  
 syntax would be:

 -net vepa,if=eth0

 or

 -net vepa,fd=N

I still hope it's extbridge, vepa is an acronym that will likely not be
known for 99% of users.

 where N is a macvtap fd.

 For raw, I think there's a real problem wrt security.  I think it's  
 important that we support running qemu as a non-privileged user.  In  
 fact, this seems to be the mode libvirt is now preferring to operate in.

 I think we need to re-evaluate the use of any raw socket by qemu as it's  
 very dangerous from a security perspective (assuming we cannot  
 introduced a locked raw socket mode).

As was pointed out on netdev and elsewhere this seems to be what
namespaces/selinux are there for. Can qemu be run within a namespace and
if yes would that address your concerns?  Security is probably a wrong
reason to use character devices: they are much more likely to have
security problems than standard interfaces.  Ease of setup/compatibility
with tap would be a better reason.

 Regards,

 Anthony Liguori

 Regards,

 Anthony Liguori
  
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu


On 01/27/2010 11:25 AM, Michael S. Tsirkin wrote:

  In this case, the full
syntax would be:

-net vepa,if=eth0

or

-net vepa,fd=N
 

I still hope it's extbridge, vepa is an acronym that will likely not be
known for 99% of users.
   


Oh sorry, I don't care about the name at all.  If you prefer extbridge, 
I'm all for it :-)



where N is a macvtap fd.

For raw, I think there's a real problem wrt security.  I think it's
important that we support running qemu as a non-privileged user.  In
fact, this seems to be the mode libvirt is now preferring to operate in.

I think we need to re-evaluate the use of any raw socket by qemu as it's
very dangerous from a security perspective (assuming we cannot
introduced a locked raw socket mode).
 

As was pointed out on netdev and elsewhere this seems to be what
namespaces/selinux are there for. Can qemu be run within a namespace and
if yes would that address your concerns?


It's unclear to me what this would even involve.  But really, we just 
want an interface to inject packets directly into a physical device.  
raw sockets give us that but it also gives us way more.  Using network 
namespaces to restrict this is a bit convoluted.  It seems to me that 
providing an interface that never gives us way more to start with is 
better overall from a security perspective.


Regards,

Anthony Liguori


   Security is probably a wrong
reason to use character devices: they are much more likely to have
security problems than standard interfaces.  Ease of setup/compatibility
with tap would be a better reason.

   

Regards,

Anthony Liguori

 

Regards,

Anthony Liguori

 


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] KVM: Plan obsolescence of kernel allocated slots, paravirt mmu

On Tue, Jan 26, 2010 at 04:34:34PM +0200, Avi Kivity wrote:
 These features are unused by modern userspace and can go away.  Paravirt
 mmu needs to stay a little longer for live migration.
 
 Signed-off-by: Avi Kivity a...@redhat.com
 ---
  Documentation/feature-removal-schedule.txt |   23 +++
  1 files changed, 23 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/feature-removal-schedule.txt 
 b/Documentation/feature-removal-schedule.txt
 index 870d190..88ca110 100644
 --- a/Documentation/feature-removal-schedule.txt
 +++ b/Documentation/feature-removal-schedule.txt
 @@ -493,3 +493,26 @@ Why: These two features use non-standard interfaces. 
 There are the
  Who: Corentin Chary corentin.ch...@gmail.com
  
  
 +What:KVM memory aliases support
 +When:July 2010
 +Why: Memory aliasing support is used for speeding up guest vga access
 + through the vga windows.
 +
 + Modern userspace no longer uses this feature, so it's just bitrotted
 + code and can be removed with no impact.
 +Who: Avi Kivity a...@redhat.com
 +
 +What:KVM kernel-allocated memory slots
 +When:July 2010
 +Why: Since 2.6.25, kvm supports user-allocated memory slots, which are
 + much more flexible than kernel-allocated slots.  All current userspace
 + supports the newer interface and this code can be removed with no
 + impact.

Just a note: can block userspace usage but can't really remove code
since there are in-kernel users (special purpose vmx pages).

Otherwise looks good to me.

 +Who: Avi Kivity a...@redhat.com
 +
 +What:KVM paravirt mmu host support
 +When:January 2011
 +Why: The paravirt mmu host support is slower than non-paravirt mmu, both
 + on newer and older hardware.  It is already not exposed to the guest,
 + and kept only for live migration purposes.
 +Who: Avi Kivity a...@redhat.com
 -- 
 1.6.5.3
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu


On 01/27/2010 11:54 AM, Sridhar Samudrala wrote:

I too think that we should not block raw backend in qemu just because of
security reasons. It should be perfectly fine to use raw backend in
scenarios where qemu can be run as a privileged process.

libvirt need not support raw backend until we figure out a secure way to
start qemu when passing raw fd. using network namespaces seems like a
good option.
   


Introducing something that is known to be problematic from a security 
perspective without any clear idea of what the use-case for it is is a 
bad idea IMHO.


Regards,

Anthony Liguori


Thanks
Sridhar

   


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

On Wed, Jan 27, 2010 at 12:02:34PM -0600, Anthony Liguori wrote:
 On 01/27/2010 11:54 AM, Sridhar Samudrala wrote:
 I too think that we should not block raw backend in qemu just because of
 security reasons. It should be perfectly fine to use raw backend in
 scenarios where qemu can be run as a privileged process.

 libvirt need not support raw backend until we figure out a secure way to
 start qemu when passing raw fd. using network namespaces seems like a
 good option.


 Introducing something that is known to be problematic from a security  
 perspective without any clear idea of what the use-case for it is is a  
 bad idea IMHO.

vepa on existing kernels is one use-case.

 Regards,

 Anthony Liguori

 Thanks
 Sridhar


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

On Wed, Jan 27, 2010 at 11:36:31AM -0600, Anthony Liguori wrote:
 On 01/27/2010 11:25 AM, Michael S. Tsirkin wrote:
   In this case, the full
 syntax would be:

 -net vepa,if=eth0

 or

 -net vepa,fd=N
  
 I still hope it's extbridge, vepa is an acronym that will likely not be
 known for 99% of users.


 Oh sorry, I don't care about the name at all.  If you prefer extbridge,  
 I'm all for it :-)

 where N is a macvtap fd.

 For raw, I think there's a real problem wrt security.  I think it's
 important that we support running qemu as a non-privileged user.  In
 fact, this seems to be the mode libvirt is now preferring to operate in.

 I think we need to re-evaluate the use of any raw socket by qemu as it's
 very dangerous from a security perspective (assuming we cannot
 introduced a locked raw socket mode).
  
 As was pointed out on netdev and elsewhere this seems to be what
 namespaces/selinux are there for. Can qemu be run within a namespace and
 if yes would that address your concerns?

 It's unclear to me what this would even involve.  But really, we just  
 want an interface to inject packets directly into a physical device.   

Not only. We also want to program filters by mac/vlan, enable/disable
promisc mode, set mac, maybe more, all this in response to guest
activity so it's not as trivial as doing it in a helper script.  The
patches supplied do not do this and do filtering in userspace but I
trust this is short-term.

 raw sockets give us that but it also gives us way more.  Using network  
 namespaces to restrict this is a bit convoluted.  It seems to me that  
 providing an interface that never gives us way more to start with is  
 better overall from a security perspective.

You are thinking about qemu security so custom groups and permissions on
character devices and/or suid scripts with custom configuration files
look nice to you.  But think in terms of an overall system security. If
you write custom kernel interfaces you end up with an unmanageable
security policy. And system administrator not being in control of
security policy is very bad for security.

All the above is basically repeating what others said on netdev.
If you care, pls argue on disablenetwork thread.

 Regards,

 Anthony Liguori

Security is probably a wrong
 reason to use character devices: they are much more likely to have
 security problems than standard interfaces.  Ease of setup/compatibility
 with tap would be a better reason.


 Regards,

 Anthony Liguori

  
 Regards,

 Anthony Liguori

  
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu


On 01/27/2010 12:03 PM, Michael S. Tsirkin wrote:

On Wed, Jan 27, 2010 at 12:02:34PM -0600, Anthony Liguori wrote:
   

On 01/27/2010 11:54 AM, Sridhar Samudrala wrote:
 

I too think that we should not block raw backend in qemu just because of
security reasons. It should be perfectly fine to use raw backend in
scenarios where qemu can be run as a privileged process.

libvirt need not support raw backend until we figure out a secure way to
start qemu when passing raw fd. using network namespaces seems like a
good option.

   

Introducing something that is known to be problematic from a security
perspective without any clear idea of what the use-case for it is is a
bad idea IMHO.
 

vepa on existing kernels is one use-case.
   


Considering VEPA enabled hardware doesn't exist today and the standards 
aren't even finished being defined, I don't think it's a really strong 
use case ;-)


Regards,

Anthony Liguori


Regards,

Anthony Liguori

 

Thanks
Sridhar


   


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] KVM: Introduce modification context for cpu_synchronize_state

On Wed, Jan 27, 2010 at 03:54:08PM +0100, Jan Kiszka wrote:
 This patch originates in the mp_state writeback issue: During runtime
 and even on reset, we must not write the previously saved VCPU state
 back into the kernel in an uncontrolled fashion. E.g mp_state should
 only written on reset or on VCPU setup. Certain clocks (e.g. the TSC)
 may only be written on setup or after vmload.
 
 By introducing additional information about the context of the planned
 vcpu state manipulation, we can simply skip sensitive states like
 mp_state when updating the in-kernel state. The planned modifications
 are defined when calling cpu_synchronize_state. They accumulate, ie.
 once a full writeback was requested, it will stick until it was
 performed.
 
 This patch already fixes existing writeback issues in upstream KVM by
 only selectively writing MSR_IA32_TSC, MSR_KVM_SYSTEM_TIME,
 MSR_KVM_WALL_CLOCK, the mp_state and the vcpu_events.
 
 Signed-off-by: Jan Kiszka jan.kis...@siemens.com
 ---
 
 This patch is intentionally written against uq/master. As upstream is
 less convoluted (yet :) ), it may help understanding the basic idea. An
 add-on patch for qemu-kvm that both cleans up the current code and also
 moves kvm_get/set_lapic into kvm_arch_get/put_registers (hmm, maybe also
 renaming that services...) will follow soon if no one sees fundamental
 problems of this approach.
 
  exec.c|4 ++--
  gdbstub.c |   10 +-
  hw/apic.c |2 +-
  hw/ppc_newworld.c |2 +-
  hw/ppc_oldworld.c |2 +-
  hw/s390-virtio.c  |2 +-
  kvm-all.c |   31 +++
  kvm.h |   13 +
  monitor.c |4 ++--
  target-i386/helper.c  |2 +-
  target-i386/kvm.c |   31 +++
  target-i386/machine.c |4 ++--
  target-ppc/kvm.c  |2 +-
  target-ppc/machine.c  |4 ++--
  target-s390x/kvm.c|   17 -
  15 files changed, 78 insertions(+), 52 deletions(-)

 diff --git a/kvm-all.c b/kvm-all.c
 index f8350c9..8595cd9 100644
 --- a/kvm-all.c
 +++ b/kvm-all.c
 @@ -57,7 +57,8 @@ struct KVMState
  KVMSlot slots[32];
  int fd;
  int vmfd;
 -int regs_modified;
 +int synchronized;
 +int pending_modifications;
  int coalesced_mmio;
  #ifdef KVM_CAP_COALESCED_MMIO
  struct kvm_coalesced_mmio_ring *coalesced_mmio_ring;

Should be per-vcpu.

 @@ -155,10 +156,12 @@ static void kvm_reset_vcpu(void *opaque)
  CPUState *env = opaque;
  
  kvm_arch_reset_vcpu(env);
 -if (kvm_arch_put_registers(env)) {
 +if (kvm_arch_put_registers(env, env-kvm_state-pending_modifications
 +| CPU_MODIFY_RESET)) {
  fprintf(stderr, Fatal: kvm vcpu reset failed\n);
  abort();
  }
 +env-kvm_state-pending_modifications = CPU_MODIFY_NONE;

Can't the writeback here happen at exec_cpu?

 @@ -946,9 +953,9 @@ static void kvm_invoke_set_guest_debug(void *data)
  struct kvm_set_guest_debug_data *dbg_data = data;
  CPUState *env = dbg_data-env;
  
 -if (env-kvm_state-regs_modified) {
 -kvm_arch_put_registers(env);
 -env-kvm_state-regs_modified = 0;
 +if (env-kvm_state-pending_modifications) {
 +kvm_arch_put_registers(env, env-kvm_state-pending_modifications);
 +env-kvm_state-pending_modifications = CPU_MODIFY_NONE;
  }

Why's synchronous writeback needed here?

Otherwise seems fine.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

2010-01-27 Thread Arnd Bergmann

On Wednesday 27 January 2010, Anthony Liguori wrote:
  I think -net socket,fd should just be (trivially) extended to work with raw
  sockets out of the box, with no support for opening it. Then you can have
  libvirt or some wrapper open a raw socket and a private namespace and just 
  pass it
  down.
   
  That'd work. Anthony?
 
 The fundamental problem that I have with all of this is that we should 
 not be introducing new network backends that are based around something 
 only a developer is going to understand.  If I'm a user and I want to 
 use an external switch in VEPA mode, how in the world am I going to know 
 that I'm supposed to use the -net raw backend or the -net socket 
 backend?  It might as well be the -net butterflies backend as far as a 
 user is concerned.

My point is that we already have -net socket,fd and any user that passes
an fd into that already knows what he wants to do with it. Making it
work with raw sockets is just a natural extension to this, which works
on all kernels and (with separate namespaces) is reasonably secure.

I fully agree that we should not introduce further network backends
that would confuse users, but making the existing backends more
flexible is something entirely different.

Arnd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1

2010-01-27 Thread Dustin Kirkland

On Fri, Jan 22, 2010 at 7:12 AM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
 On Fri, 2010-01-22 at 11:26 +, Yann Hamon wrote:
 Hello list,

 I am using Ubuntu 8.04 with the kvm84 and libvirt 0.6.1 backports. I am 
 experiencing regular crashes of my Vms - well, more like  freezes than 
 actual crashes. This is how it looks like: 
 http://waste.mandragor.org/kvmcpu/munin.html

 * The VM keeps running
 * The number of LOC IRQs goes down to 0, as well as the number of context 
 switches
 * The number of processes gradually grows
 * The weird thing: some processes that were running before the crash keep 
 running, but won't be able to fork (as you can see the munin-node continues 
 to work)

 This is bothering me a lot and I have absolutely no idea how to fix it or 
 work around it.
 Has this been experienced by anyone else, and/or fixed in a later version of 
 KVM?

 I saw your blog post yesterday speaking about it. Unfortunately I don't
 have much experience with kvm under Ubuntu, so you might want to talk to
 Dustin, Ubuntu's maintainer of KVM. I saw some replies to your blog post
 suggesting you to use Dustin's PPA, have you tried to do that?

 I am copying Dustin on the message. As I said, I am not very
 knowledgeable with Ubuntu, but perhaps you should try a newer KVM build?
 kvm-84 is kinda... old :) A backport of a more current codebase to 8.04
 could be a good idea.

Thanks for the pointer, Lucas.

I have worked with Yann to get a better KVM onto Ubuntu 8.04 LTS, more
or less at his request.  At the time, I backported the then-current
kvm-84 from Ubuntu 9.04 (Jaunty) to Ubuntu 8.04 (Hardy), as a stop-gap
measure, replacing the purely ancient kvm-62.  Last I heard from Yann,
kvm-84 (and friends) was working much better than kvm-62.

Ubuntu 9.10 (Karmic) has qemu-kvm-0.11, which seems more stable than
kvm-84, in my experience.  And the under-development Ubuntu 10.04 LTS
(Lucid) currently has qemu-kvm-0.12.2.

Once Ubuntu 10.04 LTS (Lucid) ships in April (or, if I get some down
time between now and then), I will attempt to backport qemu-kvm-0.12.2
to Ubuntu 8.04 (Hardy).

There's more than a few complications with doing this backport, and it
takes considerable effort to do so, as there are several pieces that
must be handled, and thoroughly tested, including at least:
 a) the modern kvm kernel module, and getting it building under DKMS
 b) the modern qemu-kvm userspace, getting it building against the
older toolchain
 c) the modern libvirt library, getting it building against the older toolchain
 d) testing the interoperability of all of the above

My efforts are currently 110% committed against developing Ubuntu
10.04 LTS (Lucid), and the virtualization stack there.  Yann, and
anyone wanting a backported virtualization stack against Ubuntu 8.04
LTS should follow the procedures at:
 * https://help.ubuntu.com/community/UbuntuBackports
and ideally someone from the Ubuntu community with backport experience
can help get a new version building and tested.  If there's someone
volunteering to help with that work, I'll gladly mentor them and guide
the process, sign, and upload packages to the Ubuntu repositories on
their behalf.

Cheers,
:-Dustin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1

2010-01-27 Thread Yann Hamon


 Thanks for the pointer, Lucas.
 
 I have worked with Yann to get a better KVM onto Ubuntu 8.04 LTS, more
 or less at his request.  At the time, I backported the then-current
 kvm-84 from Ubuntu 9.04 (Jaunty) to Ubuntu 8.04 (Hardy), as a stop-gap
 measure, replacing the purely ancient kvm-62.  Last I heard from Yann,
 kvm-84 (and friends) was working much better than kvm-62.

Hello Dustin, thanks for replying here, and thank you again for the backports. 
The backports indeed fixes major problems that I was having with kvm62 - 
however I am experiencing regular crashes and haven't been able to figure out 
why, til now. This didn't occured during my testing phase, and even now occur 
fairly rarely (one same VM would crash every month or so) - but becomes an 
issue as you get more vms. 


 Ubuntu 9.10 (Karmic) has qemu-kvm-0.11, which seems more stable than
 kvm-84, in my experience.  And the under-development Ubuntu 10.04 LTS
 (Lucid) currently has qemu-kvm-0.12.2.
 
 Once Ubuntu 10.04 LTS (Lucid) ships in April (or, if I get some down
 time between now and then), I will attempt to backport
 qemu-kvm-0.12.2 to Ubuntu 8.04 (Hardy).

I think it's more me who assumed I would have a more stable KVM if I sticked to 
LTS - KVM being relatively new, I might have been better off upgrading every 6 
months. Am readying my hosts for 10.4 as I speak...

 There's more than a few complications with doing this backport, and
 it
 takes considerable effort to do so, as there are several pieces that
 must be handled, and thoroughly tested, including at least:
  a) the modern kvm kernel module, and getting it building under DKMS
  b) the modern qemu-kvm userspace, getting it building against the
 older toolchain
  c) the modern libvirt library, getting it building against the older
 toolchain
  d) testing the interoperability of all of the above

Indeed. Are you aware of any other production deployment using 8.04 
experiencing issues? If not, maybe it's just not worth it.

 My efforts are currently 110% committed against developing Ubuntu
 10.04 LTS (Lucid), and the virtualization stack there.  Yann, and
 anyone wanting a backported virtualization stack against Ubuntu 8.04
 LTS should follow the procedures at:
  * https://help.ubuntu.com/community/UbuntuBackports
 and ideally someone from the Ubuntu community with backport
 experience
 can help get a new version building and tested.  If there's someone
 volunteering to help with that work, I'll gladly mentor them and
 guide
 the process, sign, and upload packages to the Ubuntu repositories on
 their behalf.

Oh my KVM hosts don't do much more than KVM, so I'd be fine with any version of 
Ubuntu, really. Will probably move my dev vms to lucid alpha, and test for a 
few months - and migrate everything to there after release. From there I might 
do the 6 months upgrade.
Just thought that if the bug I am having was known and fixed I might get a 
quick workaround which would have helped me wait :)

Thanks for your reply

-- 
Yann HAMON
Systems Manager
Oxford Archaeology: Exploring the Human Journey
http://thehumanjourney.net


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2941282 ] Ubuntu 10.04 installer fails due to I/O errors with virtio

Bugs item #2941282, was opened at 2010-01-28 00:19
Message generated for change (Tracker Item Submitted) made by intgr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2941282group_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: Marti Raudsepp (intgr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ubuntu 10.04 installer fails due to I/O errors with virtio

Initial Comment:
I tried installing Ubuntu 10.04 and Fedora 12 in a KVM virtual machine using 
virtio, on a 8G raw file-backed disk. Both installers failed half-way due to 
I/O errors. So I tried reproducing it and managed to repeat it 6 times. The bug 
doesn't occur with IDE emulation. The bug happens fairly quickly with -smp 4 -- 
usually within 5 minutes -- but is much rarer with -smp 1.

Ubuntu installer has kernel 2.6.32-11-generic
Fedora 12 has kernel 2.6.31.5-127.fc12.x86_64
Host has kernel 2.6.32.6 (Arch Linux) and QEMU 0.12.2

When testing with -smp 1, it also produced a kernel oops from 
block/blk-core.c:245. This line warns when the function is called with 
interrupts enabled:
void blk_start_queue(struct request_queue *q)
{
WARN_ON(!irqs_disabled());

queue_flag_clear(QUEUE_FLAG_STOPPED, q);
__blk_run_queue(q);
}


--- host machine ---

[ma...@newn]% qemu-kvm --version
QEMU PC emulator version 0.12.2 (qemu-kvm-0.12.2), Copyright (c) 2003-2008 
Fabrice Bellard
[ma...@newn]% ps aux |grep crash
root 16283 31.4  7.1 427020 289960 ?   Sl   22:44   8:37 
/usr/bin/qemu-kvm -S -M pc-0.11 -enable-kvm -m 256 -smp 1 -name 
ubuntu-crashtest -uuid 0d7d4f2d-5589-160b-1f1b-75d46e293a2c -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/ubuntu-crashtest.monitor,server,nowait
 -monitor chardev:monitor -boot d -drive 
file=/store/iso/lucid-desktop-amd64.iso,if=ide,media=cdrom,index=2,format=raw 
-drive file=/store/virt/ubuntu-crashtest.img,if=virtio,index=0,format=raw -net 
nic,macaddr=52:54:00:45:e7:19,vlan=0,name=nic.0 -net 
tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet 
-vnc 127.0.0.1:1 -k en-us -vga cirrus -soundhw es1370 -balloon virtio
marti17700  0.0  0.0   8360   968 pts/4S+   23:11   0:00 grep crash
[ma...@newn]% stat /store/virt/ubuntu-crashtest.img
  File: `/store/virt/ubuntu-crashtest.img'
  Size: 8589934592  Blocks: 5615368IO Block: 4096   regular file
Device: fe01h/65025dInode: 4718596 Links: 1
Access: (0600/-rw---)  Uid: (0/root)   Gid: (0/root)
Access: 2010-01-27 22:43:45.128113080 +0200
Modify: 2010-01-27 23:09:11.523577452 +0200
Change: 2010-01-27 23:09:11.523577452 +0200
[ma...@newn]% uname -a
Linux newn 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 25 20:33:50 CET 2010 x86_64 AMD 
Phenom(tm) II X4 940 Processor AuthenticAMD GNU/Linux
[ma...@newn]% cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 4
model name  : AMD Phenom(tm) II X4 940 Processor
stepping: 2
cpu MHz : 800.000
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips: 6028.69
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

*snip* three more CPU cores

--- Ubuntu guest VM ---

ubu...@ubuntu:/tmp$ uname -a
Linux ubuntu 2.6.32-11-generic #15-Ubuntu SMP Tue Jan 19 20:38:41 UTC 2010 
x86_64 GNU/Linux
ubu...@ubuntu:/tmp$ cat /sys/block/vda/stat
   7388948289  1661218   39497026765   947851  6284676  9459960
0   987890  9893220
ubu...@ubuntu:/tmp$ dmesg
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.32-11-generic (bui...@crested) (gcc version 
4.4.3 20100116 (prerelease) (Ubuntu 4.4.2-9ubuntu4) ) #15-Ubuntu SMP Tue Jan 19 
20:38:41 UTC 2010 (Ubuntu 2.6.32-11.15-generic)
[0.00] Command line: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity 
initrd=/casper/initrd.lz quiet splash --
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00]

Re: [PATCH 2/2] kvmclock: count total_sleep_time when updating guest clock

On Wed, Jan 27, 2010 at 07:13:49PM +0800, Jason Wang wrote:
 Current kvm wallclock does not consider the total_sleep_time which could cause
 wrong wallclock in guest after host suspend/resume. This patch solve
 this issue by counting total_sleep_time to get the correct host boot time.
 
 Signed-off-by: Jason Wang jasow...@redhat.com

Applied and queued for -stable, thanks.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] QMP: Emit Basic events

On Tue, Jan 26, 2010 at 06:25:08PM -0200, Luiz Capitulino wrote:
 
 While testing QMP on qemu-kvm I found that it's not emitting basic
 events like RESET or POWERDOWN.
 
 The reason is that in QEMU upstream those events are triggered
 in QEMU's main loop (ie. vl.c:main_loop()), but control doesn't
 reach there in qemu-kvm as it has its own main loop in
 qemu-kvm.c:kvm_main_loop().
 
 This commit adds the same set of events there too.
 
 NOTE: The STOP event is not being added because it should be
 triggered in vm_stop() and not in the main loop, this will be
 fixed upstream.
 
 Signed-off-by: Luiz Capitulino lcapitul...@redhat.com

Applied, thanks.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1

2010-01-27 Thread Dustin Kirkland

On Wed, 2010-01-27 at 22:11 +, Yann Hamon wrote:
  Thanks for the pointer, Lucas.
  
  I have worked with Yann to get a better KVM onto Ubuntu 8.04 LTS, more
  or less at his request.  At the time, I backported the then-current
  kvm-84 from Ubuntu 9.04 (Jaunty) to Ubuntu 8.04 (Hardy), as a stop-gap
  measure, replacing the purely ancient kvm-62.  Last I heard from Yann,
  kvm-84 (and friends) was working much better than kvm-62.
 
 Hello Dustin, thanks for replying here, and thank you again for the
 backports. The backports indeed fixes major problems that I was having
 with kvm62 - however I am experiencing regular crashes and haven't
 been able to figure out why, til now. This didn't occured during my
 testing phase, and even now occur fairly rarely (one same VM would
 crash every month or so) - but becomes an issue as you get more vms. 

Right, per our former conversations, kvm-84 seemed significantly better.
I'm sorry that it's still not totally stable.

  Ubuntu 9.10 (Karmic) has qemu-kvm-0.11, which seems more stable than
  kvm-84, in my experience.  And the under-development Ubuntu 10.04 LTS
  (Lucid) currently has qemu-kvm-0.12.2.
  
  Once Ubuntu 10.04 LTS (Lucid) ships in April (or, if I get some down
  time between now and then), I will attempt to backport
  qemu-kvm-0.12.2 to Ubuntu 8.04 (Hardy).
 
 I think it's more me who assumed I would have a more stable KVM if I
 sticked to LTS - KVM being relatively new, I might have been better
 off upgrading every 6 months. Am readying my hosts for 10.4 as I
 speak...

Right, so KVM in particular is a bit of a special case, in that it's
evolving so much faster than traditional server projects (take something
like postfix, bind, or ssh).  For most server workloads, I would
generally point you at an Ubuntu LTS for optimum stability.
Unfortunately, KVM was barely 1 year old when Ubuntu 8.04 released in
April of 2008, and has stabilized tremendously in the last 2 years.
Specifically if your key workload is KVM virtual machine hosting, I
would actually recommending upgrading through the non-LTS Ubuntu
releases.

All that said, I think the KVM (linux-2.6.32 + qemu-kvm-0.12.2) story on
Ubuntu 10.04 LTS is going to be very different than KVM (linux-2.6.24 +
kvm-62) story was on Ubuntu 8.04 LTS.  Stability is absolutely Ubuntu's
focus for the 10.04 release.  And I gather from the upstream KVM and
QEMU developers that releases of KVM in linux 2.6.32 and qemu-kvm 0.12.2
are far more stable as well.

  There's more than a few complications with doing this backport, and
  it
  takes considerable effort to do so, as there are several pieces that
  must be handled, and thoroughly tested, including at least:
   a) the modern kvm kernel module, and getting it building under DKMS
   b) the modern qemu-kvm userspace, getting it building against the
  older toolchain
   c) the modern libvirt library, getting it building against the older
  toolchain
   d) testing the interoperability of all of the above
 
 Indeed. Are you aware of any other production deployment using 8.04
 experiencing issues? If not, maybe it's just not worth it.

There were definitely other people who were able to confirm some of the
issues you raised with Hardy's kvm-62.  All of those (that I know of)
were pleased with the backported kvm-84, for those particular issues, at
least.


  My efforts are currently 110% committed against developing Ubuntu
  10.04 LTS (Lucid), and the virtualization stack there.  Yann, and
  anyone wanting a backported virtualization stack against Ubuntu 8.04
  LTS should follow the procedures at:
   * https://help.ubuntu.com/community/UbuntuBackports
  and ideally someone from the Ubuntu community with backport
  experience
  can help get a new version building and tested.  If there's someone
  volunteering to help with that work, I'll gladly mentor them and
  guide
  the process, sign, and upload packages to the Ubuntu repositories on
  their behalf.
 
 Oh my KVM hosts don't do much more than KVM, so I'd be fine with any
 version of Ubuntu, really. Will probably move my dev vms to lucid
 alpha, and test for a few months - and migrate everything to there
 after release.

I think this would be a very wise approach!  Move one or two physical
systems over to Lucid Alpha3 when it releases next week.  File bugs you
find against Lucid Alpha3 and we'll work through those issues, and
upload fixes with great fervor and a much quicker turn-around.


  From there I might do the 6 months upgrade.
 Just thought that if the bug I am having was known and fixed I might
 get a quick workaround which would have helped me wait :)

Once Ubuntu 10.04 LTS releases, if all of your blocking bugs are fixed,
then I'd stick with that until the next LTS (12.04-ish).  Basically, I'd
only upgrade if there's something in particular that I know is broken in
one release, and is fixed in the next.


:-Dustin


signature.asc
Description: This is a digitally signed message part

qemu-kvm: enable get/set vcpu events on reset and migration


 The last two hunks will cause the same !CONFIG_KVM breakages qemu-kvm's
 mpstate used to as well. You may either fix it up temporarily or wait
 for my refactoring that is now scheduled with highest priority (should
 be ready today or tomorrow).

It needs to go in 0.12-stable, so we'll have to leave with it.

Feel free to revert from master when refactoring.

Gleb/Glauber can you review please.



qemu-kvm should reset and save/restore vcpu events.

Signed-off-by: Marcelo Tosatti mtosa...@redhat.com

diff --git a/kvm.h b/kvm.h
index e2a945b..9fa4e25 100644
--- a/kvm.h
+++ b/kvm.h
@@ -52,6 +52,9 @@ int kvm_set_migration_log(int enable);
 int kvm_has_sync_mmu(void);
 #endif /* KVM_UPSTREAM */
 int kvm_has_vcpu_events(void);
+int kvm_put_vcpu_events(CPUState *env);
+int kvm_get_vcpu_events(CPUState *env);
+
 #ifdef KVM_UPSTREAM
 
 void kvm_setup_guest_memory(void *start, size_t size);
@@ -96,7 +99,9 @@ int kvm_arch_init(KVMState *s, int smp_cpus);
 
 int kvm_arch_init_vcpu(CPUState *env);
 
+#endif
 void kvm_arch_reset_vcpu(CPUState *env);
+#ifdef KVM_UPSTREAM
 
 struct kvm_guest_debug;
 struct kvm_debug_exit_arch;
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 82e362c..7f820a4 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -1457,8 +1457,9 @@ void kvm_arch_push_nmi(void *opaque)
 
 void kvm_arch_cpu_reset(CPUState *env)
 {
-env-interrupt_injected = -1;
+kvm_arch_reset_vcpu(env);
 kvm_arch_load_regs(env);
+kvm_put_vcpu_events(env);
 if (!cpu_is_bsp(env)) {
if (kvm_irqchip_in_kernel()) {
 #ifdef KVM_CAP_MP_STATE
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 1c34846..f891a3e 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2187,6 +2187,11 @@ static int kvm_create_context(void)
 return r;
 }
 
+kvm_state-vcpu_events = 0;
+#ifdef KVM_CAP_VCPU_EVENTS
+kvm_state-vcpu_events = kvm_check_extension(kvm_state, 
KVM_CAP_VCPU_EVENTS);
+#endif
+
 kvm_init_ap();
 if (kvm_irqchip) {
 if (!qemu_kvm_has_gsi_routing()) {
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 9af1e48..79be2d5 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -285,6 +285,7 @@ int kvm_arch_init_vcpu(CPUState *env)
 return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, cpuid_data);
 }
 
+#endif
 void kvm_arch_reset_vcpu(CPUState *env)
 {
 env-exception_injected = -1;
@@ -292,6 +293,7 @@ void kvm_arch_reset_vcpu(CPUState *env)
 env-nmi_injected = 0;
 env-nmi_pending = 0;
 }
+#ifdef KVM_UPSTREAM
 
 static int kvm_has_msr_star(CPUState *env)
 {
@@ -776,8 +778,9 @@ static int kvm_get_mp_state(CPUState *env)
 env-mp_state = mp_state.mp_state;
 return 0;
 }
+#endif
 
-static int kvm_put_vcpu_events(CPUState *env)
+int kvm_put_vcpu_events(CPUState *env)
 {
 #ifdef KVM_CAP_VCPU_EVENTS
 struct kvm_vcpu_events events;
@@ -807,7 +810,7 @@ static int kvm_put_vcpu_events(CPUState *env)
 #endif
 }
 
-static int kvm_get_vcpu_events(CPUState *env)
+int kvm_get_vcpu_events(CPUState *env)
 {
 #ifdef KVM_CAP_VCPU_EVENTS
 struct kvm_vcpu_events events;
@@ -844,6 +847,7 @@ static int kvm_get_vcpu_events(CPUState *env)
 return 0;
 }
 
+#ifdef KVM_UPSTREAM
 int kvm_arch_put_registers(CPUState *env)
 {
 int ret;
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 47ca6e8..0b8a33a 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -323,7 +323,10 @@ static void cpu_pre_save(void *opaque)
 int i;
 
 cpu_synchronize_state(env);
-kvm_save_mpstate(env);
+if (kvm_enabled()) {
+kvm_save_mpstate(env);
+kvm_get_vcpu_events(env);
+}
 
 /* FPU */
 env-fpus_vmstate = (env-fpus  ~0x3800) | (env-fpstt  0x7)  11;
@@ -374,6 +377,7 @@ static int cpu_post_load(void *opaque, int version_id)
 
 kvm_load_tsc(env);
 kvm_load_mpstate(env);
+kvm_put_vcpu_events(env);
 }
 
 return 0;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

2010-01-27 Thread Sridhar Samudrala

On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote:
 On Wednesday 27 January 2010, Anthony Liguori wrote:
   I think -net socket,fd should just be (trivially) extended to work with 
   raw
   sockets out of the box, with no support for opening it. Then you can have
   libvirt or some wrapper open a raw socket and a private namespace and 
   just pass it
   down.

   That'd work. Anthony?
  
  The fundamental problem that I have with all of this is that we should 
  not be introducing new network backends that are based around something 
  only a developer is going to understand.  If I'm a user and I want to 
  use an external switch in VEPA mode, how in the world am I going to know 
  that I'm supposed to use the -net raw backend or the -net socket 
  backend?  It might as well be the -net butterflies backend as far as a 
  user is concerned.
 
 My point is that we already have -net socket,fd and any user that passes
 an fd into that already knows what he wants to do with it. Making it
 work with raw sockets is just a natural extension to this, which works
 on all kernels and (with separate namespaces) is reasonably secure.

Didn't realize that -net socket is already there and supports TCP and
UDP sockets. I will look into extending -net socket to support AF_PACKET
SOCK_RAW type sockets.

Thanks
Sridhar

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2924683 ] Stable USB Windows XP BSOD with Epson V700 scanner

Bugs item #2924683, was opened at 2010-01-01 15:53
Message generated for change (Comment added) made by iggy_cav
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2924683group_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: qemu
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: marten (akunitskiy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Stable USB Windows XP BSOD with Epson V700 scanner

Initial Comment:
kvm causes stable BSOD in Windowsx XP / XP 64 with Epson V700 USB scanner. How 
I can help to fix this?

--

Comment By: Brian Jackson (iggy_cav)
Date: 2010-01-27 17:35

Message:
Here's a few things to try:
Try the latest qemu-kvm from the files page
Try with upstream qemu
Try connecting the device to a usb1.1 hub - sometimes devices get
configured as usb2 and don't like going back

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2924683group_id=180599
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2930756 ] sdl window intermittently scales instead of resizing

Bugs item #2930756, was opened at 2010-01-12 11:20
Message generated for change (Comment added) made by iggy_cav
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2930756group_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: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: sdl window intermittently scales instead of resizing

Initial Comment:
CPU: Intel(R) Core(TM)2 Duo CPU T8300  @ 2.40GHz
Host OS: Ubuntu 9.10 (karmic) 64-bit
Guest OS: all

Normally, the SDL output window for a VM resizes to match the VM's resolution. 
However, intermittently the output is instead scaled within the window. I can't 
seem to find any pattern to when the output is scaled versus when the window is 
resized. I would prefer that the window be resized as needed to display the VM 
in a 1:1 manner.

The Ubuntu report for this can be found here: 
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/504368

--

Comment By: Brian Jackson (iggy_cav)
Date: 2010-01-27 17:37

Message:
Can you reproduce with qemu-kvm-0.12.x?

--

Comment By: Jamin W. Collins (jamincollins)
Date: 2010-01-12 11:26

Message:
Sorry, should probably have included the version of KVM:
$ kvm --version
QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0), Copyright (c) 2003-2008
Fabrice Bellard
$ apt-cache policy kvm
kvm:
  Installed: 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2930756group_id=180599
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

KVM problems with Xeon L5530

2010-01-27 Thread Matteo Ghezzi

Hi!

I'm a long time KVM user, but I've encountered a problem that I couldn't solve.
I've switched my good old Core2 Quad with gentoo (2.6.27 kernel) for a
Dual Xeon L5530 with Arch (2.6.32 kernel).
I've tried starting the old vmachines on the new hardware but if I
enable kvm acceleration in qemu I got a black screen via vnc, and the
logs are filled with this message:

handle_exception: unexpected, vectoring info 0x800d intr info 0x8b0d

I've tried creating new virtual machines directly on the new hardware
but with the same result.
I've tried any combination of virtualization options in the bios,
tested any bios revision for my motherboard (Asus Z8DNA-D6), checked
the ram on another system... all in vain.

If I've to provide more info please let me know.
Thanks for your help.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

KVM Forum 2010 - save the date

2010-01-27 Thread Chris Wright

We are pleased to announce that planning is underway for the
2010 KVM Forum.  The plan is to co-locate the KVM Forum in
Boston with the Linux Foundation's LinuxCon 2010 in August.
The KVM Forum is planned for Aug 9-10, 2010.  Pencil in those
dates and begin thinking about what work you would like to
present ;-)

Stay tuned for a proper announcement and call for papers.

thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2941282 ] Ubuntu 10.04 installer fails due to I/O errors with virtio