date:20080513

On Tue, May 13, 2008 at 10:43:59PM -0700, Benjamin Herrenschmidt wrote:
> 
> On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> > ea.
> > 
> > I don't see why you're bending over so far backwards to accommodate
> > this GRU thing that we don't even have numbers for and could actually
> > potentially be batched up in other ways (eg. using mmu_gather or
> > mmu_gather-like idea).
> 
> I agree, we're better off generalizing the mmu_gather batching
> instead...

Well, the first thing would be just to get rid of the whole start/end
idea, which completely departs from the standard Linux system of
clearing ptes, then flushing TLBs, then freeing memory.

The onus would then be on GRU to come up with some numbers to justify
batching, and a patch which works nicely with the rest of the Linux
mm. And yes, mmu-gather is *the* obvious first choice of places to
look if one wanted batching hooks.

> I had some never-finished patches to use the mmu_gather for pretty much
> everything except single page faults, tho various subtle differences
> between archs and lack of time caused me to let them take the dust and
> not finish them...
> 
> I can try to dig some of that out when I'm back from my current travel,
> though it's probably worth re-doing from scratch now.

I always liked the idea as you know. But I don't think that should
be mixed in with the first iteration of the mmu notifiers patch
anyway. GRU actually can work without batching, but there is simply
some (unquantified to me) penalty for not batching it. I think it
is far better to first put in a clean and simple and working functionality
first. The idea that we have to unload some monster be-all-and-end-all
solution onto mainline in a single go seems counter productive to me.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-13 Thread Benjamin Herrenschmidt

On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> ea.
> 
> I don't see why you're bending over so far backwards to accommodate
> this GRU thing that we don't even have numbers for and could actually
> potentially be batched up in other ways (eg. using mmu_gather or
> mmu_gather-like idea).

I agree, we're better off generalizing the mmu_gather batching
instead...

I had some never-finished patches to use the mmu_gather for pretty much
everything except single page faults, tho various subtle differences
between archs and lack of time caused me to let them take the dust and
not finish them...

I can try to dig some of that out when I'm back from my current travel,
though it's probably worth re-doing from scratch now.

Ben.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] KVM: LAPIC: ignore pending timers if LVTT is disabled

2008-05-13 Thread Marcelo Tosatti


Only use the APIC pending timers count to break out of HLT emulation if
the timer vector is enabled.

Certain configurations of Windows simply mask out the vector without
disabling the timer.

Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 7652f88..d41e34c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -961,7 +961,7 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu)
 {
struct kvm_lapic *lapic = vcpu->arch.apic;
 
-   if (lapic)
+   if (lapic && apic_enabled(lapic) && apic_lvt_enabled(lapic, APIC_LVTT))
return atomic_read(&lapic->timer.pending);
 
return 0;



-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM: kvm_vcpu_block task state race

2008-05-13 Thread Marcelo Tosatti

On Sun, May 11, 2008 at 05:26:06PM +0300, Avi Kivity wrote:
> >So do you want to give wait_event_interruptible() a try or wait for that
> >change until userspace never issues vcpu ioctl's to a possibly busy vcpu
> >(and go with the patch above)?
> >  
> 
> Do we have anything critical that issues vcpu ioctls outside its 
> thread?  While I much prefer wait_event_interruptible(), I don't want to 
> break existing userspace.

Well debugging can be critical, so IMO better avoid wait_event_interruptible() 
for now.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote:
> On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> > On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > > In order to invalidate the remote page table entries, we need to message
> > > (uses XPC) to the remote side.  The remote side needs to acquire the
> > > importing process's mmap_sem and call zap_page_range().  Between the
> > > messaging and the acquiring a sleeping lock, I would argue this will
> > > require sleeping locks in the path prior to the mmu_notifier invalidate_*
> > > callouts().
> > 
> > Why do you need to take mmap_sem in order to shoot down pagetables of
> > the process? It would be nice if this can just be done without
> > sleeping.
> 
> We are trying to shoot down page tables of a different process running
> on a different instance of Linux running on Numa-link connected portions
> of the same machine.

Right. You can zap page tables without sleeping, if you're careful. I
don't know that we quite do that for anonymous pages at the moment, but it
should be possible with a bit of thought, I believe.

> The messaging is clearly going to require sleeping.  Are you suggesting
> we need to rework XPC communications to not require sleeping?  I think
> that is going to be impossible since the transfer engine requires a
> sleeping context.

I guess that you have found a way to perform TLB flushing within coherent
domains over the numalink interconnect without sleeping. I'm sure it would
be possible to send similar messages between non coherent domains.

So yes, I'd much rather rework such highly specialized system to fit in
closer with Linux than rework Linux to fit with these machines (and
apparently slow everyone else down).

> Additionally, the call to zap_page_range expects to have the mmap_sem
> held.  I suppose we could use something other than zap_page_range and
> atomically clear the process page tables.

zap_page_range does not expect to have mmap_sem held. I think for anon
pages it is always called with mmap_sem, however try_to_unmap_anon is
not (although it expects page lock to be held, I think we should be able
to avoid that).

>  Doing that will not alleviate
> the need to sleep for the messaging to the other partitions.

No, but I'd venture to guess that is not impossible to implement even
on your current hardware (maybe a firmware update is needed)?

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [patch 1/2] KVM: hlt emulation should take in-kernel APIC/PIT timers into account

2008-05-13 Thread Yang, Sheng

On Tuesday 13 May 2008 00:40:05 Marcelo Tosatti wrote:
> On Sat, May 10, 2008 at 10:12:02AM +0800, Yang, Sheng wrote:
> > > Did you have kvm.git commit 8ae6dc90ac84d9734e343210c8ec709f50cd9d89
> > > when testing this?
> > >
> > > I believe it should fix that issue, because "ps->inject_pending" won't
> > > be set by kvm_pit_timer_intr_post() if the IRQ is masked. Please
> > > correct me if I'm wrong.
> >
> > Oh, sorry, I missed that commit. But... It just solved an half of the
> > problem. LAPIC suffered from it as well, and the current HLT emulation
> > still didn't work... And I can't find something like inject_pending in
> > LAPIC timer.
> >
> > I have to say, I think my method is more preciously, directly and
> > efficient... It also can be extended easily if we got more clock sources
> > (though I don't think this would happen in near future...). In fact, I
> > think take care of pending counts is some kind of *wrong concept*... We
> > should take care of the window, or when the increment of pending counters
> > happened, CMIIW. And it got nothing to do with the current counter number
> > (yeah, I realized it after saw the hlt behaviour in XP, not before ;) ).
>
> Sheng,
>
> The problem is that you don't want to emulate hlt if you have a pending
> timer _and_ the guest is accepting events. So for example if there are
> two apic timers pending, you inject one of them, guest execute's hlt, we
> end up in vcpu_block().
>
> Does this work for you?

Yeah. I also suggest using the consistent implement for all the 
_has_pending_timer. (in fact, if take pending counters as the interrupts 
which have to delay their injection, the explanation is well :) )

-- 
Thanks
Yang, Sheng
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 7652f88..d41e34c 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -961,7 +961,7 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu)
>  {
>   struct kvm_lapic *lapic = vcpu->arch.apic;
>
> - if (lapic)
> + if (lapic && apic_enabled(lapic) && apic_lvt_enabled(lapic, APIC_LVTT))
>   return atomic_read(&lapic->timer.pending);
>
>   return 0;



-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Windows PV driver for KVM

2008-05-13 Thread Jiang, Yunhong

Hi, Dor, I just checked the URL and seems it is not updated still,
willyou update it?

-- Yunhong Jiang

Dor Laor  wrote:
> On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote:
>> Avi Kivity  wrote:
>>> Jiang, Yunhong wrote:
 I noticed there is a windows PV driver based on virtIO in
 http://sourceforge.net/project/showfiles.php?group_id=180599
 
 But when I enable the driver in guest, the guest will hang. I'm
using
 changeset around April, 18. Since the driver is created in March, I
 assume the changeset in Apri should be ok.
 
 Are there any special action needed to enable the PV driver in
windows?
 Have anyone tried it recently?
 
>>> 
>>> We are using it in production.  What HAL is the guest using?  Are
you
>>> running with smp?
>> 
>> The HAL is ACPI multipprocessor PC.
>> It is a UP guest. But I do notice one thing strange. When I use
device
>> manager->Processors, I see a lot of CPU listed. But it is really a UP
>> system and I can only get one cpu in the task manager->performance
>> window. Not sure if that's the reason of the hang.
>> 
> 
> We just fixed an smp bug for virtio (also triggered by single
processor
> with ACPI multiprocessor HAL). We'll publish a new binary tomorrow.
> 
> The reason you see multiple cpus although there is only one is that we
> expose the maximum number in the bios. The system is actually uses the
> required number so this behavior is ok.
> 
> 
>> -- Yunhong Jiang
>> 
>>> 
>>> --
>>> Any sufficiently difficult bug is indistinguishable from a feature.
>> 
>> 
> ---
> --
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save
$100.
>> Use priority code J8TL2D2. 
>> 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.
> sun.com/javaone
>> ___
>> kvm-devel mailing list
>> kvm-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/kvm-devel

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Add support for a configuration file

2008-05-13 Thread Daniel P. Berrange

On Tue, May 13, 2008 at 06:07:08PM -0500, Anthony Liguori wrote:
> Anthony Liguori wrote:
> > I think this is pretty useful as-is.  I think it also gives us a reasonable
> > way to move forward that will keep everyone pretty happy.
> > 
> > Here's a short example:
> > 
> > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
> > 
> > Would become `foo.qemu':
> > 
> >  # Main disk image
> >  hda=/home/anthony/images/linux.img
> > 
> >  # Redirect disk writes to a temporary image
> >  snapshot
> > 
> >  # Make the graphical display available on port 5902
> >  vnc=:2
> > 
> > With:
> > 
> > qemu-system-x86_64 -config foo.qemu
> 
> One thought I had, is that it would be very nice to break up the -drive 
> file=foo.img,if=scsi syntax within the config file.  In general, I'm 
> thinking something like:

Yes, that would be the main concern I have with the plain conversion
of existing command line args. It would essentially be limiting the 
expressiveness of the config file to that of the command line - flat
key,value pairs. All we'd be gaining  is avoidance of command line 
length limits and persistent storage. Two worthy goals, but IMHO it
could be worth striving for more structure, so the config can explicitly
represent arrays and hashes as concepts.

> [drive]
> file=foo.img
> if=scsi

This just feels like a bad 1/2 house compromise. Adds the complexity
of a more structured config file without giving the full benefits of
a more expressive format such as the 2 you show below.

> drive {
>file=foo.img
>if=scsi
> }

I like both this & the next format because they're very expressive.

> or even:
> 
> drive:
>file=foo.img
>if=scsi

That's very nearly YAML format[1], which is attractive because parsers
are available in every major programming language, and it is still
pretty human friendly.

So my preference would be to go with the last option and make sure
it really is YAML compliant so people can use standard tools for 
generating and parsing the format.

Regards,
Daniel

[1]  http://yaml.org/spec/1.2/
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Add support for a configuration file

Anthony Liguori wrote:
> I think this is pretty useful as-is.  I think it also gives us a reasonable
> way to move forward that will keep everyone pretty happy.
> 
> Here's a short example:
> 
> qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
> 
> Would become `foo.qemu':
> 
>  # Main disk image
>  hda=/home/anthony/images/linux.img
> 
>  # Redirect disk writes to a temporary image
>  snapshot
> 
>  # Make the graphical display available on port 5902
>  vnc=:2
> 
> With:
> 
> qemu-system-x86_64 -config foo.qemu

One thought I had, is that it would be very nice to break up the -drive 
file=foo.img,if=scsi syntax within the config file.  In general, I'm 
thinking something like:

[drive]
file=foo.img
if=scsi

or:

drive {
   file=foo.img
   if=scsi
}

or even:

drive:
   file=foo.img
   if=scsi

Basically, I'm looking for a syntax for sub-options.  This would be 
useful for -drive or -net but I also think would lay the foundations for 
specifying a full machine config.

It would get very unwieldy on the command line to have a large number of 
suboptions but it works reasonably well within a config.

Regards,

Anthony Liguori

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] Add support for a configuration file

There has been an awful lot of discussion about a configuration file with
almost no general agreement except that one is strongly desired.

I thought about it a bit, and I think a nice step would be to simply allow
the current configuration parameters to be stored in a file using a pretty
familiar format.

I think this is pretty useful as-is.  I think it also gives us a reasonable
way to move forward that will keep everyone pretty happy.

Here's a short example:

qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2

Would become `foo.qemu':

 # Main disk image
 hda=/home/anthony/images/linux.img

 # Redirect disk writes to a temporary image
 snapshot

 # Make the graphical display available on port 5902
 vnc=:2

With:

qemu-system-x86_64 -config foo.qemu

Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>

diff --git a/qemu-doc.texi b/qemu-doc.texi
index cca483c..4861fc0 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -395,6 +395,12 @@ Sets the @var{name} of the guest.
 This name will be display in the SDL window caption.
 The @var{name} will also be used for the VNC server.
 
[EMAIL PROTECTED] -config @var{file}
+Reads configuration options from @var{file}.  The format of @var{file} is the
+same as the command line options, except no dash ``-'' is required.  Options
+that take an argument are in the format @var{option=value}.  A pound ``#''
+character can be used as a comment.
+
 @end table
 
 Display options:
diff --git a/vl.c b/vl.c
index 67712f0..2eb39dd 100644
--- a/vl.c
+++ b/vl.c
@@ -7276,6 +7276,7 @@ static void help(int exitcode)
"-clock  force the use of the given methods for timer 
alarm.\n"
"To see what timers are available use -clock ?\n"
"-startdate  select initial date of the clock\n"
+  "-config FILEread command line options from FILE\n"
"\n"
"During emulation, the following keys are useful:\n"
"ctrl-alt-f  toggle full screen\n"
@@ -7379,6 +7380,7 @@ enum {
 QEMU_OPTION_old_param,
 QEMU_OPTION_clock,
 QEMU_OPTION_startdate,
+QEMU_OPTION_config,
 };
 
 typedef struct QEMUOption {
@@ -7490,6 +7492,7 @@ const QEMUOption qemu_options[] = {
 #endif
 { "clock", HAS_ARG, QEMU_OPTION_clock },
 { "startdate", HAS_ARG, QEMU_OPTION_startdate },
+{ "config", HAS_ARG, QEMU_OPTION_config },
 { NULL },
 };
 
@@ -7665,9 +7668,106 @@ static BOOL WINAPI qemu_ctrl_handler(DWORD type)
 }
 #endif
 
+static char **insert_opts(char **old_argv, int *old_argc, int index,
+ char **argv, int argc)
+{
+char **new_argv;
+
+/* Allocate larger array */
+new_argv = realloc(old_argv, (*old_argc + argc) * sizeof(old_argv[0]));
+if (new_argv == NULL) {
+   fprintf(stderr, "allocate failed in insert_opts\n");
+   exit(1);
+}
+
+/* move elements after insertion point to end of array */
+memmove(new_argv+index + argc, new_argv + index,
+   (*old_argc - index) * sizeof(argv[0]));
+
+/* copy in new elements */
+memcpy(new_argv + index, argv, argc * sizeof(argv[0]));
+
+*old_argc += argc;
+
+if (0) { /* for debugging */
+   int i;
+   printf("argv[] = {");
+   for (i = 0; i < *old_argc; i++) {
+   if (i)
+   printf(", ");
+   printf("\"%s\"", new_argv[i]);
+   }
+   printf("}\n");
+}
+
+return new_argv;
+}
+
+static char **parse_config_file(const char *file, int *pargc)
+{
+FILE *f;
+char buffer[4096];
+char **argv = NULL;
+int argc = 0;
+
+f = fopen(file, "r");
+if (f == NULL)
+   return NULL;
+
+while (fgets(buffer, sizeof(buffer), f)) {
+   char *ptr = buffer;
+   char *tok, *key, *val;
+   char *targv[2];
+   int targc = 0;
+
+   /* skip whitespace */
+   while (isspace(*ptr)) ptr++;
+
+   /* skip comments or empty lines */
+   if (*ptr == '#' || *ptr == 0)
+   continue;
+
+   /* trim new line and carriage return if necessary */
+   tok = strchr(ptr, '\n');
+   if (tok)
+   *tok = 0;
+   tok = strchr(ptr, '\r');
+   if (tok)
+   *tok = 0;
+
+   /* check if it has an argument */
+   tok = strchr(ptr, '=');
+   if (tok)
+   *tok = 0;
+
+   /* add key */
+   if (asprintf(&key, "--%s", ptr) == -1)
+   return NULL;
+   targv[targc++] = key;
+
+   /* add argument (optionally) */
+   if (tok) {
+   if (asprintf(&val, "%s", tok + 1) == -1)
+   return NULL;
+   targv[targc++] = val;
+   }
+
+   /* insert new arguments */
+   argv = insert_opts(argv, &argc, argc, targv, targc);
+   if (argv == NULL)
+   return NULL;
+}
+
+fclose(f);
+
+*pargc = argc;
+
+return argv;
+}
+
 #define MAX_NET_CLIENTS 32
 
-int main(int argc, char **argv)
+int main(int orig_argc, char **orig_argv)
 {
 #ifdef CONFIG_GDBSTUB
 int use_gdbstub;
@@

[kvm-devel] [PATCH 1/4] Add method to send fragmented packets

We need to be able to send fragmented packets in KVM to avoid an extra copy
in the TX path.  This patch adds a qemu_sendv_packet() function to send
fragemented packets.  It also provides backwards compatibility for old clients
that don't support the new interface.

Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>

diff --git a/qemu/net.h b/qemu/net.h
index 13daa27..5fb190e 100644
--- a/qemu/net.h
+++ b/qemu/net.h
@@ -1,12 +1,17 @@
 #ifndef QEMU_NET_H
 #define QEMU_NET_H
 
+#include 
+
 /* VLANs support */
 
+typedef ssize_t (IOReadvHandler)(void *, const struct iovec *, int);
+
 typedef struct VLANClientState VLANClientState;
 
 struct VLANClientState {
 IOReadHandler *fd_read;
+IOReadvHandler *fd_readv;
 /* Packets may still be sent if this returns zero.  It's used to
rate-limit the slirp code.  */
 IOCanRWHandler *fd_can_read;
@@ -30,6 +35,8 @@ VLANClientState *qemu_new_vlan_client(VLANState *vlan,
   void *opaque);
 int qemu_can_send_packet(VLANClientState *vc);
 void qemu_send_packet(VLANClientState *vc, const uint8_t *buf, int size);
+ssize_t qemu_sendv_packet(VLANClientState *vc, const struct iovec *iov,
+ int iovcnt);
 void qemu_handler_true(void *opaque);
 
 void do_info_network(void);
diff --git a/qemu/vl.c b/qemu/vl.c
index 45c97af..1f0a6ac 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -3820,6 +3820,50 @@ void qemu_send_packet(VLANClientState *vc1, const 
uint8_t *buf, int size)
 }
 }
 
+static ssize_t vc_sendv_compat(VLANClientState *vc, const struct iovec *iov,
+  int iovcnt)
+{
+char buffer[4096];
+size_t offset = 0;
+int i;
+
+for (i = 0; i < iovcnt; i++) {
+   size_t len;
+
+   len = MIN(sizeof(buffer) - offset, iov[i].iov_len);
+   memcpy(buffer + offset, iov[i].iov_base, len);
+   offset += len;
+}
+
+vc->fd_read(vc->opaque, buffer, offset);
+
+return offset;
+}
+
+ssize_t qemu_sendv_packet(VLANClientState *vc1, const struct iovec *iov,
+ int iovcnt)
+{
+VLANState *vlan = vc1->vlan;
+VLANClientState *vc;
+ssize_t max_len = 0;
+
+for (vc = vlan->first_client; vc != NULL; vc = vc->next) {
+   ssize_t len = 0;
+
+   if (vc == vc1)
+   continue;
+
+   if (vc->fd_readv)
+   len = vc->fd_readv(vc->opaque, iov, iovcnt);
+   else if (vc->fd_read)
+   len = vc_sendv_compat(vc, iov, iovcnt);
+
+   max_len = MAX(max_len, len);
+}
+
+return max_len;
+}
+
 #if defined(CONFIG_SLIRP)
 
 /* slirp network adapter */

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 2/4] Add fd_readv handler to tap

This allows fragmented packets to be sent with no additional copies over the
tap interface.

Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>

diff --git a/qemu/vl.c b/qemu/vl.c
index 1f0a6ac..7900b76 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -4086,6 +4086,19 @@ static void tap_receive(void *opaque, const uint8_t 
*buf, int size)
 }
 }
 
+static ssize_t tap_readv(void *opaque, const struct iovec *iov,
+int iovcnt)
+{
+TAPState *s = opaque;
+ssize_t len;
+
+do {
+   len = writev(s->fd, iov, iovcnt);
+} while (len == -1 && (errno == EINTR || errno == EAGAIN));
+
+return len;
+}
+
 static void tap_send(void *opaque)
 {
 TAPState *s = opaque;
@@ -4135,6 +4148,7 @@ static TAPState *net_tap_fd_init(VLANState *vlan, int fd)
 s->no_poll = 0;
 enable_sigio_timer(fd);
 s->vc = qemu_new_vlan_client(vlan, tap_receive, NULL, s);
+s->vc->fd_readv = tap_readv;
 qemu_set_fd_handler2(s->fd, tap_read_poll, tap_send, NULL, s);
 snprintf(s->vc->info_str, sizeof(s->vc->info_str), "tap: fd=%d", fd);
 return s;

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 3/4] Use fragmented send for virtio

This patch converts virtio-net to use the new fragmented send interface.
We should have always supported this.

Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>

diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 85cc9d2..93bca1d 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -239,23 +239,15 @@ again:
 static void virtio_net_flush_tx(VirtIONet *n, VirtQueue *vq)
 {
 VirtQueueElement elem;
-int count = 0;
 
 if (!(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK))
 return;
 
 while (virtqueue_pop(vq, &elem)) {
-   int i;
-   size_t len = 0;
+   ssize_t len = 0;
 
/* ignore the header for now */
-   for (i = 1; i < elem.out_num; i++) {
-   qemu_send_packet(n->vc, elem.out_sg[i].iov_base,
-elem.out_sg[i].iov_len);
-   len += elem.out_sg[i].iov_len;
-   }
-
-   count++;
+   len = qemu_sendv_packet(n->vc, &elem.out_sg[1], elem.out_num - 1);
 
virtqueue_push(vq, &elem, sizeof(struct virtio_net_hdr) + len);
virtio_notify(&n->vdev, vq);

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] D e ntists Database in the United States

2008-05-13 Thread Lauren O Rice






Fully exportable and can be used for any purpose:

+ 164,323 D.entists 
+ 158,954 Civic Addresses
+ 163,539 Telephone Numbers
+ 77,236 Fax Numbers
+ 45,650 office emails

Until May 16 the new lowered price is $292

Please reply to [EMAIL PROTECTED]  




to get off please email with 84128 for a subject

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 4/4] Validate virtio-net TX header

Missed this one in my last series.

Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>

diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 93bca1d..ca45775 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -246,6 +246,12 @@ static void virtio_net_flush_tx(VirtIONet *n, VirtQueue 
*vq)
 while (virtqueue_pop(vq, &elem)) {
ssize_t len = 0;
 
+   if (elem.out_num < 1 ||
+   elem.out_sg[0].iov_len != sizeof(struct virtio_net_hdr)) {
+   fprintf(stderr, "virtio-net header not in first element\n");
+   exit(1);
+   }
+
/* ignore the header for now */
len = qemu_sendv_packet(n->vc, &elem.out_sg[1], elem.out_num - 1);
 

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] pinning, tsc and apic

2008-05-13 Thread Ryan Harper

* Anthony Liguori <[EMAIL PROTECTED]> [2008-05-12 17:00]:
> Ryan Harper wrote:
> >>BTW, what if you don't pace-out the startups?  Do we still have issues 
> >>with that?
> >>
> >
> >Do you mean without the 1 second delay or with a longer delay?  My
> >experience is that delay helps (fewer hangs), but doesn't solve things
> >completely.
> >  
> 
> So you see problems when using numactrl to pin and using a 0-second 
> delay?  The short delay may help reduce the number of CPU migrations 
> which would explain your observation.
> 
> If there are problems when doing a 0-second delay and numactl, then 
> perhaps it's not just a cpu-migration issue.

nodelay, w/pinning -> all OK
delay, w/pinning   -> all OK

with -no-kvm-irqchip (with or without any delay (1 to 30 seconds), I get
in some guests:

..MP-BIOS bug: 8254 timer not connected to IO-APIC
Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the
'noapic' kernel parameter

> >In svm.c, I do think we account for most of that time since the delta
> >calculation will shift the guest time forward to the tsc value read in
> >svm_vcpu_load().  We'll still miss the time between fixing the offset
> >and when the guest can actually read its tsc.
> >  
> 
> Yes, which is the duration that the guest isn't scheduled on any 
> processor and the next time it runs happens to be on a different process.
> 
> >>A possible way to fix this (that's only valid on a processor with a 
> >>fixed-frequency TSC), is to take a high-res timestamp on vcpu_put, and 
> >>then on vcpu_load, take the delta timestamp since the old TSC was saved, 
> >>and use the TSC frequency on the new pcpu to calculate the number of 
> >>elapsed cycles.
> >>
> >>Assuming a fixed frequency TSC, and a calibrated TSC across all 
> >>processors, you could get the same affects by using the VT tsc delta 
> >>logic.  Basically, it always uses the new CPU's TSC unless that would 
> >>cause the guest to move backwards in time.  As long as you have a 
> >>stable, calibrated TSC, this would work out.
> >>
> >>Can you try your old patch that did this and see if it fixes the problem?
> >>
> >
> >Yeah, I'll give it a spin.

Testing the old patch with no-pinning, but just the tsc check doesn't
help the situation.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
[EMAIL PROTECTED]

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Налоговые претензии при вексел ьных схемах

2008-05-13 Thread Сделки с векселем

Применение векселя в хозяйственном обороте. Расчетные схемы, налоговые
последствия, правовые риски участников вексельного оборота

Однодневный семинар / 19 мая 2008 г. / Москва

Программа семинара

1. Правовая природа векселя и сделок с ним.
∙ Содержание вексельного обязательства. Виды векселей. Конструкция обязательств
в простых и переводных векселях
∙ Типовое ("стандартное") применение векселей в хозяйственной деятельности.
Правовая характеристика сделок, лежащих в основании выдачи, передачи и
погашения векселей. Займы под вексель, встречные векселя, продажа и залог
векселей и др..
∙ Типовые (базовые) схемы "вексельных" взаиморасчетов.

2. Налоговые последствия базовых схем взаиморасчетов с применением простых
векселей.
∙ НДС при расчетах собственными простыми векселями покупателя. Расчеты путем
акцепта переводных векселей.
∙ НДС при расчетах векселями третьих лиц.
∙ НДС при расчетах переводными векселями.
∙ Налог на прибыль при операциях с дисконтным и процентным векселем.

3. Налоговые риски в случае нестандартных схем применения векселей в
хозяйственной деятельности.
∙ Концепция реальных затрат в налогообложении НДС. Возможные налоговые
претензии при наличии вспомогательных вексельных схем..
∙ Другие схемы

4. Основные правовые риски участников вексельного оборота и способы защиты
прав.
∙ Обзор возможных возражений против требований об оплате векселя. Требования к
форме, к процедуре предъявления к оплате. Понятие недобросовестного
приобретения векселя и приобретения в ущерб должнику.
∙ Действия держателя в случае похищения или утраты векселя. Вызывное
производство и связанные с этой процедурой риски.
∙ Действия векселеучастников в случае обнаружения подлога векселя. Средства
доказывания факта подлога. Распределение обязанности доказывания.
Несовершенство института публичной достоверности векселя.

Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу).
Место обучения: г. Москва, 5 мин. пешком от м. Академическая.
Стоимость обучения: 4900 руб. (с НДС).
(В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане).

Для регистрации на семинар необходимо отправить нам реквизиты организации, тему
и дату семинара, полное ФИО участников, контактный телефон и факс.

Получить подробную программу и зарегистрироваться можно
по телефону: ( 4 9 5 ) 5 43 = 8 8 = 4 6

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Reminder: register now for KVM Forum 2008

If you haven't already, please sign up for KVM Developer's Forum 2008.  
The final agenda (now boasting twenty presentations) has been posted at:

http://kforum.qumranet.com/KVMForum/agenda.php

Registration details are at:

   http://kforum.qumranet.com/KVMForum/register_now.php

-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-13 Thread Robin Holt

On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > In order to invalidate the remote page table entries, we need to message
> > (uses XPC) to the remote side.  The remote side needs to acquire the
> > importing process's mmap_sem and call zap_page_range().  Between the
> > messaging and the acquiring a sleeping lock, I would argue this will
> > require sleeping locks in the path prior to the mmu_notifier invalidate_*
> > callouts().
> 
> Why do you need to take mmap_sem in order to shoot down pagetables of
> the process? It would be nice if this can just be done without
> sleeping.

We are trying to shoot down page tables of a different process running
on a different instance of Linux running on Numa-link connected portions
of the same machine.

The messaging is clearly going to require sleeping.  Are you suggesting
we need to rework XPC communications to not require sleeping?  I think
that is going to be impossible since the transfer engine requires a
sleeping context.

Additionally, the call to zap_page_range expects to have the mmap_sem
held.  I suppose we could use something other than zap_page_range and
atomically clear the process page tables.  Doing that will not alleviate
the need to sleep for the messaging to the other partitions.

Thanks,
Robin

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Vmware ESX under KVM - guest GPF in installer

2008-05-13 Thread Ian Kirk

Hi,

I wanted to try running Vmware ESX without the effort of finding a
physical machine. Googling around I found that it is possible to run ESX
under other hypervisors/emulators, e.g. Vmware Workstation. So I thought
i'd give KVM a go.

Using kvm-66 on 2.6.24.4-64.fc8PAE, the (mostly text mode) installer
crashes after starting with "esx text". (I can't easily test kvm-68 at the
mo due to needing to do a reboot of the host)

Microsoft Virtual Server R2-SP1 kinda works, however the virtual NIC
is unsupported by the ESX installer.

Qemu 0.9.1 (for Windows) fails at a similar point.

Is this a "fixed in newer kvm" or a generic problem (be it kvm or ESX
installer CDROM kernel) ?

I hadn't even got as far as installing/running ESX.

Regards,
Ian


host dmesg says:
kvm: emulating exchange as write
kvm: 9329: cpu0 unhandled rdmsr: 0xc080
kvm: 9350: cpu0 unhandled rdmsr: 0xc080

guest kernel says:
Intel machine check reporting enabled on CPU#0.
general protection fault: 
CPU:0
EIP:0060:[]Not tainted
EFLAGS: 00010206

EIP is at  (2.4.21-47.0.1.ELBOOT/i686)
eax: 0191abfd   ebx: c0293580   ecx: c080   edx: 0001
esi: 0001   edi: 0002   ebp: c0293580   esp: c02b5fc8
ds: 0068   cs: 0060   es: 0068   ss: 0068
Process swapper (pid: 0, stackpage=c02b5000)
Stack: c02ba34a c0293580 c0293580 0800 00039800 c0107000 0002e000
c02b6192
   c0293580 c02b6679 0001fff0 0001fff0 c02e8480 c010018c
Call Trace:   []  (0xc02b5fdc)

Code: 0f 32 a9 00 08 00 00 74 09 a1 74 0e 2d c0 85 c0 74 0d c7 05

Kernel panic: Fatal exception
In idle task - not syncing


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

On Thursday 08 May 2008 11:34, Andrea Arcangeli wrote:
> Sorry for not having completely answered to this. I initially thought
> stop_machine could work when you mentioned it, but I don't think it
> can even removing xpmem block-inside-mmu-notifier-method requirements.
>
> For stop_machine to solve this (besides being slower and potentially
> not more safe as running stop_machine in a loop isn't nice), we'd need
> to prevent preemption in between invalidate_range_start/end.
>
> I think there are two ways:
>
> 1) add global lock around mm_lock to remove the sorting
>
> 2) remove invalidate_range_start/end, nuke mm_lock as consequence of
>it, and replace all three with invalidate_pages issued inside the
>PT lock, one invalidation for each 512 pte_t modified, so
>serialization against get_user_pages becomes trivial but this will
>be not ok at all for SGI as it increases a lot their invalidation
>frequency

This is what I suggested to begin with before this crazy locking was
developed to handle these corner cases... because I wanted the locking
to match with the tried and tested Linux core mm/ locking rather than
introducing this new idea.

I don't see why you're bending over so far backwards to accommodate
this GRU thing that we don't even have numbers for and could actually
potentially be batched up in other ways (eg. using mmu_gather or
mmu_gather-like idea).

The bare essential, matches-with-Linux-mm mmu notifiers that I first
saw of yours was pretty elegant and nice. The idea that "only one
solution must go in and handle everything perfectly" is stupid because
it is quite obvious that the sleeping invalidate idea is just an order
of magnitude or two more complex than the simple atomic invalidates
needed by you. We should and could easily have had that code upstream
long ago :(

I'm not saying we ignore the sleeping or batching cases, but we should
introduce the ideas slowly and carefully and assess the pros and cons
of each step along the way.

>
> For KVM both ways are almost the same.
>
> I'll implement 1 now then we'll see...
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [EMAIL PROTECTED]  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"[EMAIL PROTECTED]"> [EMAIL PROTECTED] 

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

On Thursday 08 May 2008 10:38, Robin Holt wrote:
> On Wed, May 07, 2008 at 02:36:57PM -0700, Linus Torvalds wrote:
> > On Wed, 7 May 2008, Andrea Arcangeli wrote:
> > > I think the spinlock->rwsem conversion is ok under config option, as
> > > you can see I complained myself to various of those patches and I'll
> > > take care they're in a mergeable state the moment I submit them. What
> > > XPMEM requires are different semantics for the methods, and we never
> > > had to do any blocking I/O during vmtruncate before, now we have to.
> >
> > I really suspect we don't really have to, and that it would be better to
> > just fix the code that does that.
>
> That fix is going to be fairly difficult.  I will argue impossible.
>
> First, a little background.  SGI allows one large numa-link connected
> machine to be broken into seperate single-system images which we call
> partitions.
>
> XPMEM allows, at its most extreme, one process on one partition to
> grant access to a portion of its virtual address range to processes on
> another partition.  Those processes can then fault pages and directly
> share the memory.
>
> In order to invalidate the remote page table entries, we need to message
> (uses XPC) to the remote side.  The remote side needs to acquire the
> importing process's mmap_sem and call zap_page_range().  Between the
> messaging and the acquiring a sleeping lock, I would argue this will
> require sleeping locks in the path prior to the mmu_notifier invalidate_*
> callouts().

Why do you need to take mmap_sem in order to shoot down pagetables of
the process? It would be nice if this can just be done without
sleeping.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Supplements to promote sexual pleasure

2008-05-13 Thread Tomeny

Find out why Kevin Federline has it so easy http://www.ranetys.com/

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [CentOS-devel] KVM-66 packages in testing

2008-05-13 Thread Farkas Levente

Avi Kivity wrote:
> Farkas Levente wrote:
>> mandrake 9, 10 and winxp run but neither centos-5.1 i386 nor x86_64 
>> are   boot:-( i386 give a kernel panic x86_64 simple hang during boot.
>>   
> 
> Can you post the panic?
> 
> It's probably the 3Dnow! bug which is fixed for kvm-69.

unfortunately i can't reproduce the kernel crash, now it's usually hang 
at "starting udev" both centos-5.1 i386 and x86_64.
anyway i build kvm-68 and it's working.

-- 
   Levente   "Si vis pacem para bellum!"

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 9071a6c.., userspace 4b1a087..

Yunfeng Zhao wrote:
> Hi All,
>  
> This is today's KVM test result against kvm.git 
> 9071a6c25634d037adb7129dc84814a7f5c7c34a and kvm-userspace.git 
> 4b1a087a96ca9a7bf5ed1124367f7f3ac785c0d5.
>
> Five Old Issues:
> 
> 1. Fails to restore guests in real mode
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959950&group_id=180599
>   

This should be fixed by 662beb8baa37481d1cb32aff8354c931f8a73441, which 
is included in the the sources you tested.

> 3. linux virtio drivers won't work after runing save/restore
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959443&group_id=180599
>   
This should be fixed by a00f04bd370738d65235387c1b3ccd394b595571 and 
c15c33996040e8d407a348ac4d9ccb84893429a4, also included.

Perhaps you have stale binaries?

> 5. KVM Guest Drivers fail on Windows
> https://sourceforge.net/tracker/index.php?func=detail&aid=1920897&group_id=180599&atid=893831
> We met the issue too while testing Windows drivers on XP.
>
>   

A new driver will be released soon which corrects the problem 
(encountered on the ACPI Multiprocessor PC HAL).

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC][PATCH] svm.c: tsc unsigned delta calculation

2008-05-13 Thread Joerg Roedel

On Wed, May 07, 2008 at 05:01:02PM -0500, Ryan Harper wrote:
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 5528121..c919ddd 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -685,8 +685,14 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>* increasing TSC.
>*/
>   rdtscll(tsc_this);
> - delta = vcpu->arch.host_tsc - tsc_this;
> - svm->vmcb->control.tsc_offset += delta;
> + /* we only need to adjust this if the old tsc was ahead
> + * also, we'll generate a massively large u64 value if
> + * tsc_this is less than host_tsc because of unsigned math
> + */
> + if (tsc_this < vcpu->arch.host_tsc) {
> + delta = vcpu->arch.host_tsc - tsc_this;
> + svm->vmcb->control.tsc_offset += delta;
> + }
>   vcpu->cpu = cpu;
>   kvm_migrate_apic_timer(vcpu);
>   }

Hmm, I think this can result in inaccurate guest time because it makes
the tsc hopping. Does it fix the problem when you make delta an s64?

Joerg

-- 
   |   AMD Saxony Limited Liability Company & Co. KG
 Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System|  Register Court Dresden: HRA 4896
 Research  |  General Partner authorized to represent:
 Center| AMD Saxony LLC (Wilmington, Delaware, US)
   | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] can't boot 2.6.26-rcX

2008-05-13 Thread Bernd Schubert

Hello,

there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at

Calibrating delay using timer specific routine.. 4016.92 BogoMIPS
(lpj=8033846)

The kvm process then takes 100% of my host CPU.

This is with kvm-67 on an AM64-X2-

I'm not yet familiar with kvm and debugging. Will a sysrq+t trace of the
host show something useful? Or will only full git-bisect help?


Thanks,
Bernd


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] KVM Test result, kernel 9071a6c.., userspace 4b1a087..

2008-05-13 Thread Yunfeng Zhao

Hi All,

This is today's KVM test result against kvm.git
9071a6c25634d037adb7129dc84814a7f5c7c34a and kvm-userspace.git
4b1a087a96ca9a7bf5ed1124367f7f3ac785c0d5.

Five Old Issues:

1. Fails to restore guests in real mode
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959950&group_id=180599
2. XP crashes while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_id=180599
3. linux virtio drivers won't work after runing save/restore
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959443&group_id=180599
4.Cannot boot guests with hugetlbfs
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599
5. KVM Guest Drivers fail on Windows
https://sourceforge.net/tracker/index.php?func=detail&aid=1920897&group_id=180599&atid=893831
We met the issue too while testing Windows drivers on XP.

Test environment

PlatformWoodcrest
CPU 4
Memory size 8G'

Details

IA32-pae:
1. boot guest with 256M memory PASS
2. boot two windows xp guest PASS
3. boot 4 same guest in parallelPASS
4. boot linux and windows guest in parallel PASS
5. boot guest with 1500M memory PASS
6. boot windows 2003 with ACPI enabled PASS
7. boot Windows xp with ACPI enabled PASS
8. boot Windows 2000 without ACPI PASS
9. kernel build on SMP linux guestPASS
10. LTP on linux guest PASS
11. boot base kernel linux PASS
12. save/restore smp 32-bit HVM guests PASS
13. live migration smp 32-bit HVM guests PASS
14. boot SMP Windows xp with ACPI enabledPASS
15. boot SMP Windows 2003 with ACPI enabled PASS
16. boot SMP Windows 2000 with ACPI enabled PASS
17. boot SMP Windows 2008 with ACPI enabled PASS

IA32e:
1. boot four 32-bit guest in
parallel PASS
2. boot four 64-bit guest in
parallel PASS
3. boot 4G 64-bit
guest PASS
4. boot 4G pae
guest PASS
5. boot 32-bit linux and 32 bit windows guest in parallelPASS
6. boot 32-bit guest with 1500M memory PASS
7. boot 64-bit guest with 1500M memory PASS
8. boot 32-bit guest with 256M memory PASS
9. boot 64-bit guest with 256M memory PASS
10. boot two 32-bit windows xp in parallelPASS
11. boot four 32-bit different guest in para
PASS
12. save/restore smp 64-bit linux
guests PASS
13. save/restore smp 32-bit linux
guests PASS
14. boot 32-bit SMP windows 2003 with ACPI enabled PASS
15. boot 32-bit SMP windows 2008 with ACPI enabled PASS
16. boot 32-bit SMP Windows 2000 with ACPI enabled PASS
17. boot 32-bit SMP Windows xp with ACPI enabledPASS
18. boot 32-bit Windows 2000 without ACPIPASS
19. boot 64-bit Windows xp with ACPI enabledPASS
20. boot 32-bit Windows xp without ACPIPASS
21. boot 64-bit UP
vista PASS
22. boot 64-bit SMP
vista PASS
23. kernel build in 32-bit linux guest OS PASS
24. kernel build in 64-bit linux guest OS PASS
25. LTP on 32-bit linux guest OSPASS
26. LTP on 64-bit linux guest OSPASS
27. boot 64-bit guests with ACPI enabled PASS
28. boot 32-bit
x-server PASS
29. boot 64-bit SMP windows XP with ACPI enabled PASS
30. boot 64-bit SMP windows 2003 with ACPI enabled PASS
31. boot 64-bit SMP windows 2008 with ACPI enabled PASS
32. live migration smp 64bit linux
guests PASS
33. live migration smp 32bit linux
guests PASS
34. reboot 32bit windows xp guest PASS
35. reboot 32bit windows xp guest

Re: [kvm-devel] [PATCH 3/4] kvm/host: fix paravirt clocksource to be compatible with xen.

Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
> ---
>  arch/x86/kvm/x86.c |   63 +++
>  1 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 979f983..6906d54 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -493,7 +493,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t 
> wall_clock)
>  {
>   static int version;
>   struct kvm_wall_clock wc;
> - struct timespec wc_ts;
> + struct timespec now,sys,boot;
>   

Add spaces.

>  
>   if (!wall_clock)
>   return;
> @@ -502,9 +502,16 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t 
> wall_clock)
>  
>   kvm_write_guest(kvm, wall_clock, &version, sizeof(version));
>  
> - wc_ts = current_kernel_time();
> - wc.wc_sec = wc_ts.tv_sec;
> - wc.wc_nsec = wc_ts.tv_nsec;
> +#if 0
> + /* Hmm, getboottime() isn't exported to modules ... */
> + getboottime(&boot);
> +#else
> + now = current_kernel_time();
> + ktime_get_ts(&sys);
> + boot = ns_to_timespec(timespec_to_ns(&now) - timespec_to_ns(&sys));
> +#endif
> + wc.wc_sec = boot.tv_sec;
> + wc.wc_nsec = boot.tv_nsec;
>   

Please drop the #if 0.

>   wc.wc_version = version;
>  
>   kvm_write_guest(kvm, wall_clock, &wc, sizeof(wc));
> @@ -537,20 +544,58 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
>   /*
>* The interface expects us to write an even number signaling that the
>* update is finished. Since the guest won't see the intermediate
> -  * state, we just write "2" at the end
> +  * state, we just increase by 2 at the end.
>*/
> - vcpu->hv_clock.version = 2;
> + vcpu->hv_clock.version += 2;
>  
>   shared_kaddr = kmap_atomic(vcpu->time_page, KM_USER0);
>  
>   memcpy(shared_kaddr + vcpu->time_offset, &vcpu->hv_clock,
> - sizeof(vcpu->hv_clock));
> +sizeof(vcpu->hv_clock));
>  
>   kunmap_atomic(shared_kaddr, KM_USER0);
>  
>   mark_page_dirty(v->kvm, vcpu->time >> PAGE_SHIFT);
>  }
>  
> +static uint32_t div_frac(uint32_t dividend, uint32_t divisor)
> +{
> + uint32_t quotient, remainder;
> +
> + __asm__ ( "divl %4"
> +   : "=a" (quotient), "=d" (remainder)
> +   : "0" (0), "1" (dividend), "r" (divisor) );
> + return quotient;
> +}
>   

do_div()?

> +
> +static void kvm_set_time_scale(uint32_t tsc_khz, struct kvm_vcpu_time_info 
> *hv_clock)
> +{
> + uint64_t nsecs = 10LL;
> + int32_t  shift = 0;
> + uint64_t tps64;
> + uint32_t tps32;
> +
> + tps64 = tsc_khz * 1000LL;
> + while (tps64 > nsecs*2) {
> + tps64 >>= 1;
> + shift--;
> + }
> +
> + tps32 = (uint32_t)tps64;
> + while (tps32 <= (uint32_t)nsecs) {
> + tps32 <<= 1;
> + shift++;
> + }
> +
> + hv_clock->tsc_shift = shift;
> + hv_clock->tsc_to_system_mul = div_frac(nsecs, tps32);
> +
> +#if 0
> + printk(KERN_DEBUG "%s: tsc_khz %u, tsc_shift %d, tsc_mul %u\n",
> +__FUNCTION__, tsc_khz, hv_clock->tsc_shift,
> +hv_clock->tsc_to_system_mul);
> +#endif
> +}
>   

pr_debug() or something?

>  
>  int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>  {
> @@ -599,9 +644,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, 
> u64 data)
>   /* ...but clean it before doing the actual write */
>   vcpu->arch.time_offset = data & ~(PAGE_MASK | 1);
>  
> - vcpu->arch.hv_clock.tsc_to_system_mul =
> - clocksource_khz2mult(tsc_khz, 22);
> - vcpu->arch.hv_clock.tsc_shift = 22;
> + kvm_set_time_scale(tsc_khz, &vcpu->arch.hv_clock);
>  
What if the tsc frequency changes later on?  we need to adjust the 
multiplier, no?

-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Существенные условия договора строительного подряда

2008-05-13 Thread Юридичесикий отдел

Договоры в строительстве (практические рекомендации)

Однодневный семинар / 16 мая 2008 г. / Москва

Программа семинара

Договоры в строительстве: общие положения
∙ Общая характеристика договоров, сопровождающих строительную деятельность.
∙ Обзор договоров подрядного типа и практической сферы их применения.
∙ Анализ типичных спорных ситуаций с участием субподрядных организаций.

Документальное оформление договорных отношений
∙ Виды документов, оформляющих договорные отношения, их назначение и правила
составления.
∙ Правовое значение протоколов о намерениях и протоколов разногласий.
∙ Судебно-арбитражная практика по спорам, связанным с использованием
предварительных договоров в строительной деятельности (анализ конкретных
арбитражных решений).

Договорные условия
∙ Существенные условия договора строительного подряда.
∙ Обзор судебно-арбитражной практики по спорам о несогласованных (неверно
согласованных) существенных условиях договора.

Тендерный отбор контрагентов (преимущества и недостатки)
∙ Особенности заключения договора по результатам торгов (включая специфику
государственных заказов).
∙ Обобщение судебно-арбитражной практики по спорам о признании торгов
недействительными.
∙ Анализ конкретных ситуаций исполнения договоров строительного подряда с
организациями, отобранными на конкурсной основе.

Обеспечение интересов заказчика в договорных отношениях
∙ Способы обеспечения прав заказчика в договоре строительного подряда.
∙ Цена договора и порядок расчетов. Установление условий о цене с учетом
инфляции, удорожания материалов, рабочей силы и других тенденций изменения
рыночных цен.
∙ Основные подходы к расчетам с подрядчиками, законодательные ограничения,
возможные споры.

Оформление сдачи-приемки работ
∙ Основные документы, правила подписания, законодательные ограничения.
∙ Судебно-арбитражная практика оспаривания оформления сдачи-приемки работ,
оплаты работ по оформленным актам, полномочиям лиц, осуществившим приемку
работ.

Ответственность за нарушение договорных обязательств в строительной
деятельности
∙ Основные меры ответственности за нарушение договорных обязательств.
∙ Практика взыскания, обобщение типичных судебных споров.

Ответы на вопросы участников семинара.

При отсутствии возможности посетить семинар, мы предлагаем приобрести его
видеоверсию на DVD/CD дисках или видеокассетах (прилагается авторский
раздаточный материал).
Цена видеокурса - 3500 рублей, с учетом НДС.

Для регистрации на семинар необходимо отправить нам по факсу: реквизиты
организации, тему и дату семинара, полное ФИО участников, контактный телефон и
факс.
Для заказа видеокурса необходимо отправить нам по факсу: реквизиты организации,
тему видеокурса, указать носитель (ДВД или СД диски), телефон, факс, контактное
лицо и точный адрес доставки.

Получить дополнительную информацию и зарегистрироваться можно:
по т/ф: ( Ч 9 5 ) 5 Ч З - 8 8 - Ч 6

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)