kvm-devel — kernel virtual machine development

[kvm-devel] Подлог векселя

[Вексельный о. <te...@cq...>]

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

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

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

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

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

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

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

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

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

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

Re: [kvm-devel] Protected mode transitions and big real mode... still an issue

[Guillaume T. <gui...@ex...>]

On Thu, 15 May 2008 10:33:38 +0300
Avi Kivity <av...@qu...> wrote:

> Marcelo Tosatti wrote:
> > 1) add is storing the result in the wrong register
> >
> >     6486:       66 64 89 3e 72 01       mov    %edi,%fs:0x172
> >     648c:       66 be 8d 03 00 00       mov    $0x38d,%esi
> >     6492:       66 c1 e6 04             shl    $0x4,%esi
> >     6496:       66 b8 98 0a 00 00       mov    $0xa98,%eax
> >     649c:       66 03 f0                add    %eax,%esi
> >
> > The destination for the add is "%esi", but the emulation stores the 
> > result in eax, because:
> >
> >                 if ((c->d & ModRM) && c->modrm_mod == 3) {
> >                         u8 reg;
> >                         c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
> >                         c->dst.ptr = decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
> >                 }
> >
> > modrm_reg contains "6", which is the correct register index, but
> > modrm_rm contains 0, so the result is stored in "eax" (see hack).
> >   
> 
> What version are you looking at?  Current code doesn't have exactly this.

It's in my patch. I added this because in gfxboot code there is an
instruction "add %eax, %esp" that needs to be emulated and with the
normal path, if I remember well, we have c->dst.bytes == 0 and thus,
the emulate_2op_SrcV() function just do nothing.

Regards,
Guillaume

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

[Avi K. <av...@qu...>]

Daniel P. Berrange wrote:
> With this kind of syntax, now tools generating config files need to make
> up unique names for each drive. So you'll probably end up with them just
> naming things based on the class name + a number appended.
>   

I would hope that tools don't have to resort to reading and writing 
these config files.  Usually a management system would prefer storing 
parameters in its own database, and writing a temporary config file just 
to pass the data seems awkward.  I would much prefer to see the command 
line and monitor retain full control over every configurable parameter.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

[Tomasz C. <ma...@wp...>]

Dor Laor schrieb:

(...)

>>> FWIW, virtio-net is much better with my patches applied.  The difference 
>>> between the e1000 and virtio-net is that e1000 consumes almost twice as 
>>> much CPU as virtio-net so in my testing, the performance improvement 
>>> with virtio-net is about 2x.  We were loosing about 20-30% throughput 
>>> because of the delays in handling incoming packets.
>> Do you by chance have any recent numbers on disk performance (i.e., Windows 
>> guest vs Linux host)?
>>
>>
> 
> At the moment there is no pv block driver for Windows guests. (there is
> for linux)
> You can use scsi for windows, it should perform well.

How well, when compared to "bare metal"? Or when compared to a Linux guest with 
a pv block driver? Do you have any numbers?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

[Avi K. <av...@qu...>]

Anthony Liguori wrote:
> FWIW, virtio-net is much better with my patches applied.

The can_receive patches?

Again, I'm not opposed to them in principle, I just think that if they 
help that this points at a virtio deficiency.  Virtio should never leave 
the rx queue empty.  Consider the case where the virtio queue isn't tied 
to a socket buffer, but directly to hardware.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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

[Nick P. <np...@su...>]

On Wed, May 14, 2008 at 06:26:25AM -0500, Robin Holt wrote:
> On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
> > 
> > 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.
> 
> I assume by coherent domains, your are actually talking about system
> images.

Yes

>  Our memory coherence domain on the 3700 family is 512 processors
> on 128 nodes.  On the 4700 family, it is 16,384 processors on 4096 nodes.
> We extend a "Read-Exclusive" mode beyond the coherence domain so any
> processor is able to read any cacheline on the system.  We also provide
> uncached access for certain types of memory beyond the coherence domain.

Yes, I understand the basics.

 
> For the other partitions, the exporting partition does not know what
> virtual address the imported pages are mapped.  The pages are frequently
> mapped in a different order by the MPI library to help with MPI collective
> operations.
> 
> For the exporting side to do those TLB flushes, we would need to replicate
> all that importing information back to the exporting side.

Right. Or the exporting side could be passed tokens that it tracks itself,
rather than virtual addresses.

 
> Additionally, the hardware that does the TLB flushing is protected
> by a spinlock on each system image.  We would need to change that
> simple spinlock into a type of hardware lock that would work (on 3700)
> outside the processors coherence domain.  The only way to do that is to
> use uncached addresses with our Atomic Memory Operations which do the
> cmpxchg at the memory controller.  The uncached accesses are an order
> of magnitude or more slower.

I'm not sure if you're thinking about what I'm thinking of. With the
scheme I'm imagining, all you will need is some way to raise an IPI-like
interrupt on the target domain. The IPI target will have a driver to
handle the interrupt, which will determine the mm and virtual addresses
which are to be invalidated, and will then tear down those page tables
and issue hardware TLB flushes within its domain. On the Linux side,
I don't see why this can't be done.

 
> > 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).
> 
> But it isn't that we are having a problem adapting to just the hardware.
> One of the limiting factors is Linux on the other partition.

In what way is the Linux limiting? 


> > > 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).
> 
> zap_page_range calls unmap_vmas which walks to vma->next.  Are you saying
> that can be walked without grabbing the mmap_sem at least readably?

Oh, I get that confused because of the mixed up naming conventions
there: unmap_page_range should actually be called zap_page_range. But
at any rate, yes we can easily zap pagetables without holding mmap_sem.


> I feel my understanding of list management and locking completely
> shifting.

FWIW, mmap_sem isn't held to protect vma->next there anyway, because at
that point the vmas are detached from the mm's rbtree and linked list.
But sure, in that particular path it is held for other reasons.

 
> > >  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)?
> 
> Are you suggesting the sending side would not need to sleep or the
> receiving side?  Assuming you meant the sender, it spins waiting for the
> remote side to acknowledge the invalidate request?  We place the data
> into a previously agreed upon buffer and send an interrupt.  At this
> point, we would need to start spinning and waiting for completion.
> Let's assume we never run out of buffer space.

How would you run out of buffer space if it is synchronous?

 
> The receiving side receives an interrupt.  The interrupt currently wakes
> an XPC thread to do the work of transfering and delivering the message
> to XPMEM.  The transfer of the data which XPC does uses the BTE engine
> which takes up to 28 seconds to timeout (hardware timeout before raising
> and error) and the BTE code automatically does a retry for certain
> types of failure.  We currently need to grab semaphores which _MAY_
> be able to be reworked into other types of locks.

Sure, you obviously would need to rework your code because it's been
written with the assumption that it can sleep.

What is XPMEM exactly anyway? I'd assumed it is a Linux driver.

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

[Avi K. <av...@qu...>]

Jan Kiszka wrote:
> Hi,
>
> before going wild with my idea, I would like to collect some comments on
> this approach:
>
> While doing first kernel debugging with my debug register patches for
> kvm, I quickly ran into the 4-breakpoints-only limitation that comes
> from the fact that we blindly map software to hardware breakpoints.
> Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
> in the generic interface is not fair to arch that may support more.
> Moreover, we do not support watchpoints although this would easily be
> feasible. But if we supported watchpoints (via debug registers on x86),
> we would need the break out of the 4 slots limitations even earlier. In
> short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
> interface is required.
>   

The current interface is limited, yes.


> Why do we set breakpoints in the kernel? Why not simply catching all
> debug traps, inserting software breakpoint ops into the guest code, and
> handling all this stuff as normal debuggers do? And the hardware
> breakpoints should just be pushed through the kernel interface like
> ptrace does.
>   

The problem is that the breakpoints are visible to the guest.  If the 
guest swaps a page, the breakpoint will be swapped with it.  If it 
reallocates a page to a different use it will overwrite the breakpoint.  
It's very brittle.

For Linux kernel debugging these issues don't show up in practice, but 
other kernels are able to swap their own memory.

> The new KVM_DEBUG_GUEST interface I currently have in mind would look
> like this:
>
> #define KVM_DBGGUEST_ENABLE		0x01
> #define KVM_DBGGUEST_SINGLESTEP		0x02
>
> struct kvm_debug_guest {
> 	__u32 control;
>   

[pad]

> 	struct kvm_debug_guest_arch arch;
> }
>   

The guest debug inteface can probablty be 100% arch specific.

> Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
> userspace first, which can then decide to handle or re-inject them.
> KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
> would look like this:
>
> struct kvm_debug_guest_arch {
> 	__u32 use_hw_breakpoints;
>   

[pad]

> 	__u64 debugreg[8];
> }
>
> If use_hw_breakpoints is non-zero, KVM would completely overwrite the
> guest's debug registers with the content of debugreg, giving full
> control of this feature to the host-side debugger (faking the content of
> debug registers, effectively disabling them for the guest - as we now do
> all the time).
>   

There's much more that can be done. Branch stepping, last branch 
recording, etc.

> Questions:
> - Does anyone see traps and pitfalls in this approach?
>   

It seems workable, modulo the non-transparency of the debugger.

> - May I replace the existing interface with this one, or am I overseeing
>   some use case that already worked with the current code so that ABI
>   compatibility is required (most debug stuff should have been simply
>   broken so far, also due to bugs in userland)?
>   

This will break compilation of older userspace, so a new interface is 
preferred, complete with KVM_CAP_...

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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

[Avi K. <av...@qu...>]

Bernd Schubert wrote:
> 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?
>   

Do you have CONFIG_KVM_GUEST or CONFIG_KVM_CLOCK in your config?  If so, 
this may be a paravirt problem.  Try turning them off and let us know.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [kvm-devel] Protected mode transitions and big real mode... still an issue

[Avi K. <av...@qu...>]

Marcelo Tosatti wrote:
> 1) add is storing the result in the wrong register
>
>     6486:       66 64 89 3e 72 01       mov    %edi,%fs:0x172
>     648c:       66 be 8d 03 00 00       mov    $0x38d,%esi
>     6492:       66 c1 e6 04             shl    $0x4,%esi
>     6496:       66 b8 98 0a 00 00       mov    $0xa98,%eax
>     649c:       66 03 f0                add    %eax,%esi
>
> The destination for the add is "%esi", but the emulation stores the 
> result in eax, because:
>
>                 if ((c->d & ModRM) && c->modrm_mod == 3) {
>                         u8 reg;
>                         c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
>                         c->dst.ptr = decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
>                 }
>
> modrm_reg contains "6", which is the correct register index, but
> modrm_rm contains 0, so the result is stored in "eax" (see hack).
>   

What version are you looking at?  Current code doesn't have exactly this.

But register-in-modrm decoding is a mess, yes.  I think the best thing 
is to have decode_modrm() accept a struct operand parameter and decode 
into that.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

[Dor L. <dor...@qu...>]

On Wed, 2008-05-14 at 23:09 +0200, Tomasz Chmielewski wrote:
> Anthony Liguori schrieb:
> 
> (...)
> 
> >>> So, a PV network driver can do about 700Mb/s, and an emulated NIC can 
> >>> do about 600 Mb/s, Windows guest to host?
> >>>
> >>> That would be about 20% improvement?
> >>>     
> > 
> > FWIW, virtio-net is much better with my patches applied.  The difference 
> > between the e1000 and virtio-net is that e1000 consumes almost twice as 
> > much CPU as virtio-net so in my testing, the performance improvement 
> > with virtio-net is about 2x.  We were loosing about 20-30% throughput 
> > because of the delays in handling incoming packets.
> 
> Do you by chance have any recent numbers on disk performance (i.e., Windows 
> guest vs Linux host)?
> 
> 

At the moment there is no pv block driver for Windows guests. (there is
for linux)
You can use scsi for windows, it should perform well.

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

[Chris W. <ch...@so...>]

* Anthony Liguori (an...@co...) wrote:
>  From a quick look, I suspect that the number of wildly off TSC 
> calibrations correspond to the VMs that are misbehaving.  I think this 
> may mean that we have to re-examine the tsc delta computation.
> 
> 10_serial.log:time.c: Detected 1995.038 MHz processor.
> 11_serial.log:time.c: Detected 2363.195 MHz processor.
> 12_serial.log:time.c: Detected 2492.675 MHz processor.
> 13_serial.log:time.c: Detected 1995.061 MHz processor.
> 14_serial.log:time.c: Detected 1994.917 MHz processor.
> 15_serial.log:time.c: Detected 4100.735 MHz processor.
> 16_serial.log:time.c: Detected 2075.800 MHz processor.
> 17_serial.log:time.c: Detected 2674.350 MHz processor.
> 18_serial.log:time.c: Detected 1995.002 MHz processor.
> 19_serial.log:time.c: Detected 1994.978 MHz processor.
> 1_serial.log:time.c: Detected 4384.310 MHz processor.

Is this with pinning?  We at least know we're losing small bits on
migration.  From my measurements it's ~3000 (outliers are 10-20k).

Also, what happens if you roll back to kvm-userspace 7f5c4d15ece5?

I'm using this:

diff -up arch/x86/kvm/svm.c~svm arch/x86/kvm/svm.c
--- arch/x86/kvm/svm.c~svm	2008-04-16 19:49:44.000000000 -0700
+++ arch/x86/kvm/svm.c	2008-05-14 23:44:18.000000000 -0700
@@ -621,6 +621,13 @@ static void svm_free_vcpu(struct kvm_vcp
 	kmem_cache_free(kvm_vcpu_cache, svm);
 }
 
+static void svm_tsc_update(void *arg)
+{
+	struct vcpu_svm *svm = arg;
+	rdtscll(svm->vcpu.arch.host_tsc);
+
+}
+
 static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
@@ -633,6 +640,9 @@ static void svm_vcpu_load(struct kvm_vcp
 		 * Make sure that the guest sees a monotonically
 		 * increasing TSC.
 		 */
+		if (vcpu->cpu != -1)
+			smp_call_function_single(vcpu->cpu, svm_tsc_update,
+						 svm, 0, 1);
 		rdtscll(tsc_this);
 		delta = vcpu->arch.host_tsc - tsc_this;
 		svm->vmcb->control.tsc_offset += delta;

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

[Jiang, Y. <yun...@in...>]

It's working now, thanks very much!

-- Yunhong Jiang

Dor Laor <mailto:dor...@qu...> wrote:
> On Wed, 2008-05-14 at 08:55 +0800, Jiang, Yunhong wrote:
>> Hi, Dor, I just checked the URL and seems it is not updated still,
>> willyou update it?
> 
> Avi, since it passed regression, we can release it (also with the .pdb
> file). 
> 
>> 
>> -- Yunhong Jiang
>> 
>> Dor Laor <mailto:dor...@qu...> wrote:
>>> On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote:
>>>> Avi Kivity <mailto:av...@qu...> 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...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm trace support for ppc

[Tan, L. <li...@in...>]

-----Original Message-----
From: Hollis Blanchard [mailto:ho...@us...] 
Sent: 2008年5月15日 5:37
To: Tan, Li
Cc: kvm-devel; kvm...@li...
Subject: Re: kvm trace support for ppc

On Tuesday 13 May 2008 03:06:19 Tan, Li wrote:
> Hollisb,
> I have 2 more questions:
> 1. seems record won't be overwritten because current code is as following:
> /*
>  *  The relay channel is used in "no-overwrite" mode, it keeps trace of how
>  *  many times we encountered a full subbuffer, to tell user space app the
>  *  lost records there were.
>  */
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
> 				     void *prev_subbuf, size_t prev_padding)
> {
> 	struct kvm_trace *kt;
> 
> 	if (!relay_buf_full(buf))
> 		return 1;
> 
> 	kt = buf->chan->private_data;
> 	atomic_inc(&kt->lost_records);
> 
> 	return 0;
> }
> 
> 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use 
existing relayfs to output struct metadata with kmagic, if we update code as 
following?
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
> 				     void *prev_subbuf, size_t prev_padding)
> {
> 	struct kvm_trace *kt;
> 
> 	if (!relay_buf_full(buf))
> 	{
> 		if (!prev_subbuf) {
> 			//here is executed only once (when the channel is opened)
> 			subbuf_start_reserve(buf, sizeof(struct metadata));
> 			((struct metadata *)subbuf)->kmagic = 0x1234;
> 		}
> 		
> 		return 1;
> 	}
> 
> 	kt = buf->chan->private_data;
> 	atomic_inc(&kt->lost_records);
> 
> 	return 0;
> }

Ah, I didn't understand what the "lost records" handling was about. Given that 
it won't be lost, it would be OK for the kernel to export the header, and in 
that case I guess you would want it to be the same size as the other records. 
I'm not sure how I feel about that from a layering point of view, but at 
least it would be functional.

[tan] The relay channel is used in "no-overwrite" mode, so it will lost any new items if encounters a full subbuffer, "lost records" is to count lost records. Yes, metadata is the same size as the other records.

This solution needn't change kvmtrace user app, only need to change kvmtrace_format.pl like following:
        if i == 1:
            line = sys.stdin.read(struct.calcsize(HDRREC))
            (kmgc, umgc, mgcpad) = struct.unpack(HDRREC, line)

            if kmgc == 0x1234:
                rev = False
            else:
                rev = True
	    continue

	# If i > 1:
        line = sys.stdin.read(struct.calcsize(HDRREC))
	(event, pid, vcpu_id) = struct.unpack(HDRREC, line)
	...
	if rev:
		event = reverse_int(event)
		pid = reverse_int(pid)
		vcpu_id = reverse_int(vcpu_id)
	    tsc = reverse_qword(tsc)
	    d1 = reverse_int(d1)
	    d2 = reverse_int(d2)
	    d3 = reverse_int(d3)
	    d4 = reverse_int(d4)
	    d5 = reverse_int(d5)

 -- 
Hollis Blanchard
IBM Linux Technology Center

Re: [kvm-devel] Automatically hibernate XP guest on suspend?

[David A. <da...@bo...>]

on Sat Apr 26 2008, Avi Kivity <avi-AT-qumranet.com> wrote:

> David Abrahams wrote:
>> If I suspend my host while running a Windows XP guest, the whole machine
>> crashes, so I was hoping to automate hibernation of the guest OS and
>> integrate that into my host's suspend process.  Does anyone know how to
>> do that?
>>
>>   
>
> It's doable (not sure how), but kvm ought not to crash when resuming.

If I run the same disk image using virt-manager I can suspend it quickly
through the virt-manager interface (or virsh), and suspend/resume works.
However, I don't know how to replicate the networking I get from

  kvm -no-acpi -smp 1 -m 1000 -redir tcp:3389::3389 -usb -usbdevice tablet -boot c /mnt/usr_local/vm/xp-overlay.qcow2 

which is my usual launch command.  In particular, I don't know how to
reproduce the -redir tcp:3389::3389 in that VM file, and the guest seems
to think it's running on different hardware.  If I could figure out how
to get the equivalent of virsh's suspend command when invoking kvm from
the command line, or how to get virtual-manager to run my existing VM
as-is, I'd be all set.  Knowing both would be best of all ;-)

Any hints?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

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

[Anthony L. <an...@co...>]

Marcelo Tosatti wrote:
> On Mon, May 12, 2008 at 02:19:24PM -0500, Ryan Harper wrote:
>   
> Hi Ryan,
>
> There are two places that attempt to use delivery mode 7: kexec crash
> and io_apic_64.c::check_timer().
>
> The later will happen if the guest fails to receive PIT IRQ's for 10
> ticks. If you're using HZ=1000 thats 10ms. See timer_irq_works().
>
> The in-kernel pit emulation has logic which avoids injecting more than
> one IRQ during 10ms.
>
> Note that the guest 10ms delay is TSC based and uses only the lower
> 32-bits of the value. It is quite likely that the TSC adjustment results
> in them increasing more rapidly then they should.
>   

Or that the TSC is terribly miscalibrated.  Here is the log of all 48 
guests.  In this case, the host detects 1995.008 as the frequency.  This 
is a Barcelona.  I suspect that we're masking the 
X86_FEATURE_CONSTANT_TSC though.

 From a quick look, I suspect that the number of wildly off TSC 
calibrations correspond to the VMs that are misbehaving.  I think this 
may mean that we have to re-examine the tsc delta computation.

10_serial.log:time.c: Detected 1995.038 MHz processor.
11_serial.log:time.c: Detected 2363.195 MHz processor.
12_serial.log:time.c: Detected 2492.675 MHz processor.
13_serial.log:time.c: Detected 1995.061 MHz processor.
14_serial.log:time.c: Detected 1994.917 MHz processor.
15_serial.log:time.c: Detected 4100.735 MHz processor.
16_serial.log:time.c: Detected 2075.800 MHz processor.
17_serial.log:time.c: Detected 2674.350 MHz processor.
18_serial.log:time.c: Detected 1995.002 MHz processor.
19_serial.log:time.c: Detected 1994.978 MHz processor.
1_serial.log:time.c: Detected 4384.310 MHz processor.
20_serial.log:time.c: Detected 1994.969 MHz processor.
21_serial.log:time.c: Detected 3670.696 MHz processor.
22_serial.log:time.c: Detected 1994.997 MHz processor.
23_serial.log:time.c: Detected 2218.613 MHz processor.
24_serial.log:time.c: Detected 1995.048 MHz processor.
25_serial.log:time.c: Detected 1995.015 MHz processor.
26_serial.log:time.c: Detected 1994.957 MHz processor.
27_serial.log:time.c: Detected 1995.051 MHz processor.
28_serial.log:time.c: Detected 1995.021 MHz processor.
29_serial.log:time.c: Detected 3679.640 MHz processor.
2_serial.log:time.c: Detected 2191.105 MHz processor.
30_serial.log:time.c: Detected 1995.086 MHz processor.
31_serial.log:time.c: Detected 1995.071 MHz processor.
32_serial.log:time.c: Detected 1995.051 MHz processor.
33_serial.log:time.c: Detected 2331.760 MHz processor.
34_serial.log:time.c: Detected 1995.011 MHz processor.
35_serial.log:time.c: Detected 1995.050 MHz processor.
36_serial.log:time.c: Detected 1994.911 MHz processor.
37_serial.log:time.c: Detected 1994.905 MHz processor.
38_serial.log:time.c: Detected 1994.881 MHz processor.
39_serial.log:time.c: Detected 1995.027 MHz processor.
3_serial.log:time.c: Detected 2051.467 MHz processor.
40_serial.log:time.c: Detected 1994.987 MHz processor.
41_serial.log:time.c: Detected 1994.970 MHz processor.
42_serial.log:time.c: Detected 1994.952 MHz processor.
43_serial.log:time.c: Detected 1995.042 MHz processor.
44_serial.log:time.c: Detected 1994.998 MHz processor.
45_serial.log:time.c: Detected 1995.016 MHz processor.
46_serial.log:time.c: Detected 1995.006 MHz processor.
47_serial.log:time.c: Detected 1995.000 MHz processor.
4_serial.log:time.c: Detected 1995.112 MHz processor.
5_serial.log:time.c: Detected 1995.081 MHz processor.
6_serial.log:time.c: Detected 2017.303 MHz processor.
7_serial.log:time.c: Detected 1995.046 MHz processor.
8_serial.log:time.c: Detected 1994.951 MHz processor.
9_serial.log:time.c: Detected 2184.754 MHz processor.

Regards,

Anthony Liguori

> So can you try setting KVM_MAX_PIT_INTR_INTERVAL to a lower value? HZ/10
> or something.
>
> You can confirm this theory by booting the guests with "apic=debug".
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm...@li...
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   

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

[Marcelo T. <mto...@re...>]

On Mon, May 12, 2008 at 02:19:24PM -0500, Ryan Harper wrote:
> I've been digging into some of the instability we see when running
> larger numbers of guests at the same time.  The test I'm currently using
> involves launching 64 1vcpu guests on an 8-way AMD box.  With the latest
> kvm-userspace git and kvm.git + Gerd's kvmclock fixes, I can launch all
> 64 of these 1 second apart, and only a handful (1 to 3)  end up not
> making it up.  In dmesg on the host, I get a couple messages:
> 
> [321365.362534] vcpu not ready for apic_round_robin
> 
> and 
> 
> [321503.023788] Unsupported delivery mode 7
> 
> Now, the interesting bit for me was when I used numactl to pin the guest
> to a processor, all of the guests come up with no issues at all.  As I
> looked into it, it means that we're not running any of the vcpu
> migration code which on svm is comprised of tsc_offset recalibration and
> apic migration, and on vmx, a little more per-vcpu work

Hi Ryan,

There are two places that attempt to use delivery mode 7: kexec crash
and io_apic_64.c::check_timer().

The later will happen if the guest fails to receive PIT IRQ's for 10
ticks. If you're using HZ=1000 thats 10ms. See timer_irq_works().

The in-kernel pit emulation has logic which avoids injecting more than
one IRQ during 10ms.

Note that the guest 10ms delay is TSC based and uses only the lower
32-bits of the value. It is quite likely that the TSC adjustment results
in them increasing more rapidly then they should.

So can you try setting KVM_MAX_PIT_INTR_INTERVAL to a lower value? HZ/10
or something.

You can confirm this theory by booting the guests with "apic=debug".

Re: [kvm-devel] kvm trace support for ppc

[Hollis B. <ho...@us...>]

On Tuesday 13 May 2008 03:06:19 Tan, Li wrote:
> Hollisb,
> I have 2 more questions:
> 1. seems record won't be overwritten because current code is as following:
> /*
>  *  The relay channel is used in "no-overwrite" mode, it keeps trace of how
>  *  many times we encountered a full subbuffer, to tell user space app the
>  *  lost records there were.
>  */
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
> 				     void *prev_subbuf, size_t prev_padding)
> {
> 	struct kvm_trace *kt;
> 
> 	if (!relay_buf_full(buf))
> 		return 1;
> 
> 	kt = buf->chan->private_data;
> 	atomic_inc(&kt->lost_records);
> 
> 	return 0;
> }
> 
> 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use 
existing relayfs to output struct metadata with kmagic, if we update code as 
following?
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
> 				     void *prev_subbuf, size_t prev_padding)
> {
> 	struct kvm_trace *kt;
> 
> 	if (!relay_buf_full(buf))
> 	{
> 		if (!prev_subbuf) {
> 			//here is executed only once (when the channel is opened)
> 			subbuf_start_reserve(buf, sizeof(struct metadata));
> 			((struct metadata *)subbuf)->kmagic = 0x1234;
> 		}
> 		
> 		return 1;
> 	}
> 
> 	kt = buf->chan->private_data;
> 	atomic_inc(&kt->lost_records);
> 
> 	return 0;
> }

Ah, I didn't understand what the "lost records" handling was about. Given that 
it won't be lost, it would be OK for the kernel to export the header, and in 
that case I guess you would want it to be the same size as the other records. 
I'm not sure how I feel about that from a layering point of view, but at 
least it would be functional.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [kvm-devel] Protected mode transitions and big real mode... still an issue

[Marcelo T. <mto...@re...>]

Hi Guillaume,

On Wed, May 14, 2008 at 09:29:11AM +0200, Guillaume Thouvenin wrote:
> On Tue, 6 May 2008 20:05:39 +0300
> "Mohammed Gamal" <m.g...@gm...> wrote:
> 
> 
> > > > > WinXP fails with the patch applied too. Ubuntu 7.10 live CD and
> > > > > FreeDOS don't boot but complain about instruction mov 0x11,sreg not
> > > > > being emulated.
> 
> Mohammed, can you try the patch at the end of this mail? Here it's
> working with FreeDOS now (I added the emulation of 0x90 that is an xchg
> instruction). I can also boot winXP Professional X64 edition. I still
> have a weird issue with Ubuntu 7.10 that crashes sometimes with the
> error:
> 
> kvm_run: failed entry, reason 5
> kvm_run returned -8
> 
> It's a little bit strange because this error appears very often with
> the wmii window manager but never with XFCE. And with wmii, it only
> occurs when I move the mouse above the Qemu/KVM window. If I wait 30s
> until the automatic boot it works... 

This appears to be due to the vmport save/load bug:
https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/219165 

I'll look into it if nobody beats me to it.

Regarding FreeDOS, it necessary to emulate software interrupts and NOP
to get the "HIMEM XMS-memory driver" version to boot (with the FreeOSZOO
image).

The "maximum RAM free, using EMM86" version is more complicated, requiring 
ldt, ltr and a few other things.

There are two problems remaining:

1) add is storing the result in the wrong register

    6486:       66 64 89 3e 72 01       mov    %edi,%fs:0x172
    648c:       66 be 8d 03 00 00       mov    $0x38d,%esi
    6492:       66 c1 e6 04             shl    $0x4,%esi
    6496:       66 b8 98 0a 00 00       mov    $0xa98,%eax
    649c:       66 03 f0                add    %eax,%esi

The destination for the add is "%esi", but the emulation stores the 
result in eax, because:

                if ((c->d & ModRM) && c->modrm_mod == 3) {
                        u8 reg;
                        c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
                        c->dst.ptr = decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
                }

modrm_reg contains "6", which is the correct register index, but
modrm_rm contains 0, so the result is stored in "eax" (see hack).

2) iretl generates pagefaults

  1226df:       0f 06                   clts
  1226e1:       b8 14 00                mov    $0x14,%ax
  1226e4:       8e e0                   mov    %ax,%fs
  1226e6:       66 64 a1 50 01          mov    %fs:0x150,%eax
  1226eb:       0f 22 d8                mov    %eax,%cr3
  1226ee:       0f 20 c0                mov    %cr0,%eax
  1226f1:       66 0d 00 00 00 80       or     $0x80000000,%eax
  1226f7:       0f 22 c0                mov    %eax,%cr0
  1226fa:       66 cf                   iretl

The iretl which happens after enabling paging faults in different ways:

kvm_inject_page_fault: EIP=1226fa
kvm_inject_page_fault: ADDR=1226fa

kvm_inject_page_fault: EIP=1226fa
kvm_inject_page_fault: ADDR=1237d1
kvm: inject_page_fault: double fault 0x1237d1


Index: kvm.tip/arch/x86/kvm/vmx.c
===================================================================
--- kvm.tip.orig/arch/x86/kvm/vmx.c
+++ kvm.tip/arch/x86/kvm/vmx.c
@@ -194,6 +194,12 @@ static inline int is_external_interrupt(
 		== (INTR_TYPE_EXT_INTR | INTR_INFO_VALID_MASK);
 }
 
+static inline int is_software_interrupt(u32 intr_info)
+{
+	return (intr_info & (INTR_TYPE_SOFT_INTR | INTR_INFO_VALID_MASK))
+		== (INTR_TYPE_SOFT_INTR | INTR_INFO_VALID_MASK);
+}
+
 static inline int cpu_has_vmx_msr_bitmap(void)
 {
 	return (vmcs_config.cpu_based_exec_ctrl & CPU_BASED_USE_MSR_BITMAPS);
@@ -2190,8 +2196,10 @@ static void kvm_guest_debug_pre(struct k
 }
 
 static int handle_rmode_exception(struct kvm_vcpu *vcpu,
-				  int vec, u32 err_code)
+				  u32 intr_info, u32 err_code)
 {
+	int vec = intr_info & INTR_INFO_VECTOR_MASK;
+
 	if (!vcpu->arch.rmode.active)
 		return 0;
 
@@ -2202,6 +2210,10 @@ static int handle_rmode_exception(struct
 	if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0)
 		if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
 			return 1;
+	if (is_software_interrupt(intr_info) && err_code == 0) {
+		if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
+			return 1;
+		}
 	return 0;
 }
 
@@ -2257,8 +2269,7 @@ static int handle_exception(struct kvm_v
 	}
 
 	if (vcpu->arch.rmode.active &&
-	    handle_rmode_exception(vcpu, intr_info & INTR_INFO_VECTOR_MASK,
-								error_code)) {
+	    handle_rmode_exception(vcpu, intr_info, error_code)) {
 		if (vcpu->arch.halt_request) {
 			vcpu->arch.halt_request = 0;
 			return kvm_emulate_halt(vcpu);
Index: kvm.tip/arch/x86/kvm/x86.c
===================================================================
--- kvm.tip.orig/arch/x86/kvm/x86.c
+++ kvm.tip/arch/x86/kvm/x86.c
@@ -3294,13 +3294,21 @@ int load_segment_descriptor(struct kvm_v
 
 	if (load_segment_descriptor_to_kvm_desct(vcpu, selector, &kvm_seg))
 		return 1;
-	kvm_seg.type |= type_bits;
 
 	if (seg != VCPU_SREG_SS && seg != VCPU_SREG_CS &&
 	    seg != VCPU_SREG_LDTR)
 		if (!kvm_seg.s)
 			kvm_seg.unusable = 1;
 
+	if (seg == VCPU_SREG_CS && !kvm_seg.s) {
+		switch (kvm_seg.type) {
+		case 9: /* TSS */
+			return kvm_task_switch(vcpu, selector, TASK_SWITCH_JMP);
+		default:
+		}
+	}
+
+	kvm_seg.type |= type_bits;
 	set_segment(vcpu, &kvm_seg, seg);
 	return 0;
 }
Index: kvm.tip/arch/x86/kvm/x86_emulate.c
===================================================================
--- kvm.tip.orig/arch/x86/kvm/x86_emulate.c
+++ kvm.tip/arch/x86/kvm/x86_emulate.c
@@ -99,7 +99,7 @@ static u16 opcode_table[256] = {
 	/* 0x28 - 0x2F */
 	ByteOp | DstMem | SrcReg | ModRM, DstMem | SrcReg | ModRM,
 	ByteOp | DstReg | SrcMem | ModRM, DstReg | SrcMem | ModRM,
-	0, 0, 0, 0,
+	DstReg | SrcImm, DstReg | SrcImm, 0, 0,
 	/* 0x30 - 0x37 */
 	ByteOp | DstMem | SrcReg | ModRM, DstMem | SrcReg | ModRM,
 	ByteOp | DstReg | SrcMem | ModRM, DstReg | SrcMem | ModRM,
@@ -107,7 +107,7 @@ static u16 opcode_table[256] = {
 	/* 0x38 - 0x3F */
 	ByteOp | DstMem | SrcReg | ModRM, DstMem | SrcReg | ModRM,
 	ByteOp | DstReg | SrcMem | ModRM, DstReg | SrcMem | ModRM,
-	0, 0, 0, 0,
+	0, ByteOp | DstReg | SrcImm, 0, 0,
 	/* 0x40 - 0x47 */
 	DstReg, DstReg, DstReg, DstReg, DstReg, DstReg, DstReg, DstReg,
 	/* 0x48 - 0x4F */
@@ -154,8 +154,10 @@ static u16 opcode_table[256] = {
 	ByteOp | ImplicitOps | Mov | String, ImplicitOps | Mov | String,
 	ByteOp | ImplicitOps | String, ImplicitOps | String,
 	/* 0xB0 - 0xBF */
-	0, 0, 0, 0, 0, 0, 0, 0,
 	DstReg | SrcImm | Mov, 0, 0, 0, 0, 0, 0, 0,
+	DstReg | SrcImm | Mov, DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+	DstReg | SrcImm | Mov, DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+	DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
 	/* 0xC0 - 0xC7 */
 	ByteOp | DstMem | SrcImm | ModRM, DstMem | SrcImmByte | ModRM,
 	0, ImplicitOps | Stack, 0, 0,
@@ -169,7 +171,7 @@ static u16 opcode_table[256] = {
 	/* 0xD8 - 0xDF */
 	0, 0, 0, 0, 0, 0, 0, 0,
 	/* 0xE0 - 0xE7 */
-	0, 0, 0, 0, 0, 0, 0, 0,
+	0, 0, SrcImmByte, 0, 0, 0, 0, 0,
 	/* 0xE8 - 0xEF */
 	ImplicitOps | Stack, SrcImm | ImplicitOps, ImplicitOps, SrcImmByte | ImplicitOps,
 	0, 0, 0, 0,
@@ -183,7 +185,8 @@ static u16 opcode_table[256] = {
 
 static u16 twobyte_table[256] = {
 	/* 0x00 - 0x0F */
-	0, Group | GroupDual | Group7, 0, 0, 0, 0, ImplicitOps, 0,
+	SrcReg|SrcMem16|ModRM,
+	Group | GroupDual | Group7, 0, 0, 0, 0, ImplicitOps, 0,
 	ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps | ModRM, 0, 0,
 	/* 0x10 - 0x1F */
 	0, 0, 0, 0, 0, 0, 0, 0, ImplicitOps | ModRM, 0, 0, 0, 0, 0, 0, 0,
@@ -275,7 +278,8 @@ static u16 group_table[] = {
 	0, 0, 0, 0, 0, 0,
 	[Group5*8] =
 	DstMem | SrcNone | ModRM, DstMem | SrcNone | ModRM, 0, 0,
-	SrcMem | ModRM, 0, SrcMem | ModRM | Stack, 0,
+	SrcMem | ModRM, ImplicitOps | ModRM, SrcMem | ModRM | Stack, 0,
+
 	[Group7*8] =
 	0, 0, ModRM | SrcMem, ModRM | SrcMem,
 	SrcNone | ModRM | DstMem | Mov, 0,
@@ -951,8 +955,8 @@ done_prefixes:
 	}
 
 	/* Unrecognised? */
-	if (c->d == 0) {
-		DPRINTF("Cannot emulate %02x\n", c->b);
+	if (c->d == 0 && (c->b != 0xcc) && (c->b != 0x90) && (c->b != 0xf)) {
+		DPRINTF("Cannot emulate %02x %x\n", c->b, c->eip);
 		return -1;
 	}
 
@@ -1359,8 +1363,15 @@ special_insn:
 	case 0x00 ... 0x05:
 	      add:		/* add */
 		if ((c->d & ModRM) && c->modrm_mod == 3) {
+			u8 reg;
 			c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
-			c->dst.ptr =  decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
+
+			if (ctxt->cs_base + c->eip == 0x649f)
+				reg = c->modrm_rm|c->modrm_reg;
+			else
+				reg = c->modrm_rm;
+
+			c->dst.ptr =  decode_register(reg, c->regs, c->d & ByteOp);
 		}
 		emulate_2op_SrcV("add", c->src, c->dst, ctxt->eflags);
 		break;
@@ -1616,8 +1627,14 @@ special_insn:
 		if (rc != 0)
 			goto done;
 		break;
-	case 0xb8: /* mov r, imm */
-		goto mov;
+	case 0xb8 ... 0xbf: /* mov r, imm */
+		{
+			int reg = c->b & 0x7;
+			c->dst.ptr = (unsigned long *)&c->regs[VCPU_REGS_RAX + reg];
+			goto mov;
+		}
+	case 0x90: /* nop */
+		break;
 	case 0x9c: /* pushf */
 		c->src.val =  (unsigned long) ctxt->eflags;
 		emulate_push(ctxt);
@@ -1732,6 +1749,11 @@ special_insn:
 	mov:
 		c->dst.val = c->src.val;
 		break;
+	case 0xcc ... 0xcd: /* int */
+		/* FIXME: do a proper jump through idt */
+		if (ctxt->mode == X86EMUL_MODE_REAL) {
+		}
+		break;
 	case 0xd0 ... 0xd1:	/* Grp2 */
 		c->src.val = 1;
 		emulate_grp2(ctxt);
@@ -1740,6 +1762,12 @@ special_insn:
 		c->src.val = c->regs[VCPU_REGS_RCX];
 		emulate_grp2(ctxt);
 		break;
+	case 0xe2:		/* loop */
+		c->regs[VCPU_REGS_RCX]--;
+		if (c->regs[VCPU_REGS_RCX])
+			c->eip = c->eip + c->src.val;
+		c->dst.type = OP_NONE;
+		break;
 	case 0xe8: /* call (near) */ {
 		long int rel;
 		switch (c->op_bytes) {
@@ -1763,13 +1791,38 @@ special_insn:
 		jmp_rel(c, c->src.val);
 		c->dst.type = OP_NONE; /* Disable writeback. */
 		break;
-	case 0xea: /* jmp far */ {
+	case 0xea:
+	jmpfar: /* jmp far */ {
 		uint32_t eip;
 		uint16_t sel;
 
 		/* enable switch_perso */
 		switch_perso = 1;
 
+		if (c->b == 0xff) {
+			rc = ops->read_emulated(c->modrm_ea, &eip, 
+						c->op_bytes, ctxt->vcpu);
+			if (rc != 0)
+				goto cannot_emulate;
+
+			c->modrm_ea += c->op_bytes;
+			rc = ops->read_emulated(c->modrm_ea, &sel, 
+						2, ctxt->vcpu);
+			if (rc != 0)
+				goto cannot_emulate;
+
+			c->eip = eip;
+			if (load_segment_descriptor(ctxt->vcpu, sel, 9,
+			    VCPU_SREG_CS) < 0) {
+				printk("failed to load cs!\n");
+				goto cannot_emulate;
+			}
+			goto done;
+			/* FIXME: if this is not a TSS jump need to
+ 			 * perform register writeback.
+ 			 * break;
+ 			 */
+		}
 		switch (c->op_bytes) {
 		case 2:
 			eip = insn_fetch(u16, 2, c->eip);
@@ -1823,6 +1876,8 @@ special_insn:
 		c->dst.type = OP_NONE;	/* Disable writeback. */
 		break;
 	case 0xfe ... 0xff:	/* Grp4/Grp5 */
+		if (c->modrm_reg == 5)
+			goto jmpfar;
 		rc = emulate_grp45(ctxt, ops);
 		if (rc != 0)
 			goto done;
@@ -1847,6 +1902,22 @@ done:
 
 twobyte_insn:
 	switch (c->b) {
+	case 0x0:
+		switch (c->modrm_reg) {
+		case 2: /* ldt */
+			if (load_segment_descriptor(ctxt->vcpu, c->src.val,
+						    0, VCPU_SREG_LDTR))
+				goto cannot_emulate;
+			break;
+		case 3: /* ltr */
+			if (load_segment_descriptor(ctxt->vcpu, c->src.val, 
+						    1, VCPU_SREG_TR))
+				goto cannot_emulate;
+			break;
+		default:
+			goto cannot_emulate;
+		}
+		break;
 	case 0x01: /* lgdt, lidt, lmsw */
 		switch (c->modrm_reg) {
 			u16 size;

Re: [kvm-devel] [kvm-ppc-devel] [RFC] Reworking KVM_DEBUG_GUEST

[Hollis B. <ho...@us...>]

On Wednesday 14 May 2008 16:11:39 Hollis Blanchard wrote:
> On Wednesday 14 May 2008 16:06:00 Hollis Blanchard wrote:
> > In 
> > fact, in the case of soft breakpoints, KVM doesn't even know where all the 
> > set breakpoints are.
> 
> Side note: I'm retract this sentence: I wrote it before I sketched out the 
> pseudocode, and forgot to remove it. :)

Er no, let me try that again:

In my proposed design, the stub needs to know where all breakpoints are, HW or 
SW. (That means it must implement Z0/Z1.)

However, KVM itself doesn't need to know any of that: all breakpoints are 
referred to the stub for handling, and the stub will notify KVM if further 
action is needed in-kernel.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [kvm-devel] [kvm-ppc-devel] [RFC] Reworking KVM_DEBUG_GUEST

[Hollis B. <ho...@us...>]

On Wednesday 14 May 2008 16:06:00 Hollis Blanchard wrote:
> In 
> fact, in the case of soft breakpoints, KVM doesn't even know where all the 
> set breakpoints are.

Side note: I'm retract this sentence: I wrote it before I sketched out the 
pseudocode, and forgot to remove it. :)

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

[Tomasz C. <ma...@wp...>]

Anthony Liguori schrieb:

(...)

>>> So, a PV network driver can do about 700Mb/s, and an emulated NIC can 
>>> do about 600 Mb/s, Windows guest to host?
>>>
>>> That would be about 20% improvement?
>>>     
> 
> FWIW, virtio-net is much better with my patches applied.  The difference 
> between the e1000 and virtio-net is that e1000 consumes almost twice as 
> much CPU as virtio-net so in my testing, the performance improvement 
> with virtio-net is about 2x.  We were loosing about 20-30% throughput 
> because of the delays in handling incoming packets.

Do you by chance have any recent numbers on disk performance (i.e., Windows 
guest vs Linux host)?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

[Hollis B. <ho...@us...>]

On Wednesday 14 May 2008 14:49:02 Jan Kiszka wrote:
> > In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would 
> > just need to see if that address is for a breakpoint Qemu set or not. If 
so, 
> > it's happy. If not, (commence handwaving) tell KVM to forward the debug 
> > interrupt to the guest. This way, the list of breakpoints is maintained in 
> > userspace (in the qemu gdb stub), which is nice because it could be 
> > arbitrarily large.
> 
> Yes, but I would rather pass the debug registers (more general: some
> arch dependent state set) back in this slot. Those contain everything
> the gdbstub needs to know to catch relevant hardware-BP/watchpoint
> events (and report them to the gdb frontend).

But what would the stub *do* with the contents of the debug registers? The 
only reason they were set is on behalf of the stub in the first place. In 
fact, in the case of soft breakpoints, KVM doesn't even know where all the 
set breakpoints are. The only thing KVM needs to report is the address of the 
breakpoint that was just hit.

Sorry if this gets formatted badly:

gdb					qemu stub				KVM
break *0xf00
sends Z0 packet 0xf00
					0xf00 -> BP list
					ioctl(KVM_DEBUG, 0xf00)
continue
					ioctl(KVM_RUN)
											running...
											breakpoint hit
											exit_reason = KVM_EXIT_DEBUG
											kvm_run.debug.address = current PC value
					search BP list for address
bp hit			<---	present        not present --->	send debug interrupt to guest

Notes:
- KVM_DEBUG in this case will set a hardware breakpoint. The alternative is to 
write an int3 into guest memory.
- The stub doesn't care how the hardware registers were configured. All it 
needs to know is a) that a breakpoint was hit, and b) at what address.

Does this make sense?

-- 
Hollis Blanchard
IBM Linux Technology Center

[kvm-devel] Forget all your diseases with our help.

[Sascha <Sas...@FO...>]

This will be the only place you will ever need for all you cravings. http://www.noppoeai.com/

[kvm-devel] Юридический спецкурс для бухгалтеров

[Ответственность г. б. < <ipm...@bl...>]

Юридический спецкурс для бухгалтеров

Курс ориентирован на бухгалтеров и работников финансовых служб, коммерческих
директоров, желающих получить дополнительные знания в области договорного права

02 - 04 июня, Санкт - Петербург

В рамках мероприятия:
Иерархия нормативных правовых актов, регулирующих вопросы налогообложения и бухгалтерского учета, гражданского права.
Характеристика хозяйственных договоров, виды договоров (порядок заключения, изменения, расторжение договоров, существенные условия договоров и пр.) Гражданско-правовые и налоговые последствия несоблюдения установленных законом форм сделок. и их государственной регистрации. - Что такое свобода договора с точки зрения закона и руководителя организации. Виды договоров, определенные ГК РФ. Группировка договоров для целей налогообложения. Договоры, имеющие особый порядок налогообложения. Определение вида деятельности в зависимости от вида заключаемого договора
Значение заключаемых договоров и их взаимосвязь с отражением в бухгалтерском учете хозяйственных операций. Некоторые ограничения в договорах, вызываемые действием законодательства о налогах и сборах. Толкование договора для финансовых и налоговых целей
Договорная и налоговая цена сделки.
Договорная цена сделки и порядок ее формирования. Цена сделки как объект налогообложения. Соотношение договорной и налоговой цены сделки. Когда налоговые органы вправе проверить договорную цену сделки и порядок осуществления налогового контроля. Товарообменные (бартерные) операции
Особенности заключения некоторых договоров и налоговые последствия: Договоры купли-продажи и посредничества. Договор аренды. Договор займа
Расчеты по договору и налогообложение. Не денежные формы расчетов по договору и налогообложение
Использование договоров для целей налогового планирования. Общие принципы налогообложения. Возможность оптимизации налогообложения путем заключения определенных видов договоров. Практическое использование особенностей различных договоров для целей налогового планирования
Трудовые договоры: порядок заключения, изменения, расторжения. Условия и порядок увольнения работников. Выплата компенсаций при увольнении
Органы налогового контроля: виды проверок. Основания для проведения проверок. Правовое положение руководителя организации и должностных лиц. Права и обязанности бухгалтера при осуществлении проверок. Выездная и камеральная налоговая проверка - порядок осуществления с учетом всех последних изменений. Акт налоговой проверки. Виды санкций
Ответственность главного бухгалтера

Информация по регистрации участников: (812) 983-54-39

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

[David S. A. <da...@ci...>]

Avi Kivity wrote:
> Not so fast...  the patch updates the flood count to 5.  Can you check
> if a lower value still works?  Also, whether updating the flood count to
> 5 (without the rest of the patch) works?
> 
> Unconditionally bumping the flood count to 5 will likely cause a
> performance regression on other guests.

I put the flood count back to 3, and the RHEL3 guest performance is even
better.

> 
> While I was able to see excessive flooding, I couldn't reproduce your
> kscand problem.  Running /bin/true always returned immediately for me.

A poor attempt at finding a simplistic, minimal re-create. The use case
I am investigating has over 500 processes/threads with a base memory
consumption around 1GB. I was finding it nearly impossible to have a
generic re-create of the problem for you to use in your investigations
on CentOS.

Thanks for the patch.

david