t; >> >
> > >> >This does mean that some reads will be fast and some will be
> > >> >slow, and it's a bit sad that we seem to be optimizing
> > >> >for specific guests, but I just can't come up with
> > >> >anything be
; >
> > +static bool msix_mmio_in_range(struct kvm_assigned_dev_kernel *adev,
> > + gpa_t addr, int len)
> > +{
> > + gpa_t start, end;
> > +
> > + BUG_ON(adev->msix_mmio_base == 0);
> > + start = adev->msix_mmio_ba
be checked:
1. If two devices' MMIO have been registered successfully.
2. If you can see the mask bit accessing in kernel from both devices.
--
regards
Yang, Sheng
>
>
> #ifdef KVM_CAP_MSIX_MASK
> if (cap_mask) {
> memset(&msix_mmio, 0, sizeof
On Wednesday 01 December 2010 17:02:57 Yang, Sheng wrote:
> On Wednesday 01 December 2010 16:54:16 lidong chen wrote:
> > yes, i patch qemu as well.
> >
> > and i found the address of second vf is not in mmio range. the first
> > one is fine.
>
> So looks like s
mem_map() of the 4th patch for QEmu? I suppose
something wrong with it. I would try to reproduce it here.
And if you only use one vf, how about the gain?
--
regards
Yang, Sheng
>
> 2010/12/1 Yang, Sheng :
> > On Wednesday 01 December 2010 16:41:38 lidong chen wrote:
> >>
www.spinics.net/lists/kvm/msg44795.html
--
regards
Yang, Sheng
>
> static int msix_mmio_write(struct kvm_io_device *this, gpa_t addr, int len,
> const void *val)
> {
> struct kvm_assigned_dev_kernel *adev =
> container_of(thi
it's impossible for kernel part to work
alone...
http://www.mail-archive.com/kvm@vger.kernel.org/msg44368.html
--
regards
Yang, Sheng
>
> static int msix_mmio_write(struct kvm_io_device *this, gpa_t addr, int len,
> const void *val)
> {
> s
On Tuesday 30 November 2010 22:15:29 Avi Kivity wrote:
> On 11/26/2010 04:35 AM, Yang, Sheng wrote:
> > > > Shouldn't kvm also service reads from the pending bitmask?
> > >
> > > Of course KVM should service reading from pending bitmask. For
> > &
ste more cpu resource to deal with MSIX
> mask. and we can see how xen deal with MSIX mask.
>
> if this problem sloved, maybe with MSIX enabled, the performace is better.
Please refer to my posted patches for this issue.
http://www.spinics.net/lists/kvm/msg44992.html
--
regards
Yang,
On Wednesday 24 November 2010 09:59:23 Yang, Sheng wrote:
> On Tuesday 23 November 2010 22:06:20 Avi Kivity wrote:
> > On 11/23/2010 03:57 PM, Yang, Sheng wrote:
> > > > > Yeah, but won't be included in this patchset.
> > > >
> > > > What
On Tuesday 23 November 2010 22:06:20 Avi Kivity wrote:
> On 11/23/2010 03:57 PM, Yang, Sheng wrote:
> > > > Yeah, but won't be included in this patchset.
> > >
> > > What API changes are needed? I'd like to see the complete API.
> >
> &
On Tuesday 23 November 2010 20:04:16 Michael S. Tsirkin wrote:
> On Tue, Nov 23, 2010 at 02:09:52PM +0800, Yang, Sheng wrote:
> > Hi Avi,
> >
> > I've purposed the following API for mask bit support.
> >
> > The main point is, QEmu can know which entr
On Tuesday 23 November 2010 20:47:33 Avi Kivity wrote:
> On 11/23/2010 10:30 AM, Yang, Sheng wrote:
> > On Tuesday 23 November 2010 15:54:40 Avi Kivity wrote:
> > > On 11/23/2010 08:35 AM, Yang, Sheng wrote:
> > > > On Tuesday 23 November 2010 14:17:28 Avi Kivity
On Tuesday 23 November 2010 15:54:40 Avi Kivity wrote:
> On 11/23/2010 08:35 AM, Yang, Sheng wrote:
> > On Tuesday 23 November 2010 14:17:28 Avi Kivity wrote:
> > > On 11/23/2010 08:09 AM, Yang, Sheng wrote:
> > > > Hi Avi,
> > > >
> > &g
On Tuesday 23 November 2010 14:17:28 Avi Kivity wrote:
> On 11/23/2010 08:09 AM, Yang, Sheng wrote:
> > Hi Avi,
> >
> > I've purposed the following API for mask bit support.
> >
> > The main point is, QEmu can know which entries are enabled(by
> >
> __u32 max_entries_nr;
> __u32 flags;
> __u32 reserved[6];
> };
--
kvm)
> > + kvm_apic_nmi_wd_deliver(vcpu);
> > + }
> > +}
> > +
> > +static enum hrtimer_restart pit_timer_fn(struct hrtimer *data)
> > +{
> > + struct kvm_timer *ktimer = container_of(data, struct kvm_timer, timer);
On Tuesday 25 May 2010 22:01:50 Jan Kiszka wrote:
> Memory allocation may fail. Propagate such errors.
>
> Signed-off-by: Jan Kiszka
> ---
Reviewed-by: Sheng Yang
--
regards
Yang, Sheng
> arch/x86/include/asm/kvm_host.h |2 +-
> arch/x86/kvm/svm.c |7 +
gt; [] ? kvm_set_pic_irq+0x0/0x50 [kvm]
> [] ? paging64_walk_addr+0x25f/0x750 [kvm]
> [] ? __mutex_lock_slowpath+0x25d/0x350
> [] ? kvm_assigned_dev_ack_irq+0x35/0x90 [kvm]
> [] ? kvm_notify_acked_irq+0x71/0x120 [kvm]
Seems this time is kvm_notify_acked_irq() with RCU.
--
regards
Ya
, 1);
Or could we make kvm_set_irq() atomic? Though the code path is a little long
for spinlock.
>
> - spin_unlock_irq(&assigned_dev->assigned_dev_lock);
> }
>
> static irqreturn_t kvm_assigned_dev_intr(int irq, void *dev_id)
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine to me.
Acked-by: Sheng Yang
--
regards
Yang, Sheng
>
> Signed-off-by: Marcelo Tosatti
>
> Index: b/arch/x86/kvm/vmx.c
> ===
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1748,6 +1
On Monday 27 July 2009 17:08:42 Jan Kiszka wrote:
> [ carrying this to LKML ]
>
> Yang, Sheng wrote:
> > On Monday 27 July 2009 03:16:27 H. Peter Anvin wrote:
> >> Jan Kiszka wrote:
> >>> Avi Kivity wrote:
> >>>> On 07/24/2009 12:41 PM, Jan
d another field for virtualization feature for it, but
some concern again userspace tools raised.
For we got indeed quite a lot features, and would get more, would it better to
export the part of struct vmcs_config entries(that's pin_based_exec_ctrl,
cpu_based_exec_ctrl, and cpu_based_2nd_exe
v2.6.30...
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
page-table setup is happening within the kernel.
> >
> > As it stands, there is the shared knowledge that the qemu-kvm bios
> > just happens to know that the kvm kernel code has reserved a
> > particular page of the address space.
> >
> > It would be much easier to
On Tuesday 23 June 2009 00:09:28 Alex Williamson wrote:
> On Mon, 2009-06-22 at 13:32 +0800, Yang, Sheng wrote:
> > On Friday 19 June 2009 21:44:40 Alex Williamson wrote:
> > > On Fri, 2009-06-19 at 15:27 +0800, Yang, Sheng wrote:
> > > > On Friday 19 June 2009
On Friday 19 June 2009 21:44:40 Alex Williamson wrote:
> On Fri, 2009-06-19 at 15:27 +0800, Yang, Sheng wrote:
> > On Friday 19 June 2009 00:28:41 Alex Williamson wrote:
> > > The one oddity I noticed is that even when the enable bit is clear, the
> > > guest can read
On Friday 19 June 2009 00:28:41 Alex Williamson wrote:
> On Thu, 2009-06-18 at 13:30 +0800, Yang, Sheng wrote:
> > On Tuesday 16 June 2009 00:29:17 Alex Williamson wrote:
> > > The PCI code already knows about option ROMs, so we just need to
> > > mmap some space for it,
to the ROM, I think the
guest would be killed for QEmu would receive a SIGSEGV? I am not sure if it's
too severe...
--
regards
Yang, Sheng
> ---
>
> hw/device-assignment.c | 60
> hw/device-assignment.h |
> 5 +---
(rsvd_bits() is in mmu.c, both untested)
Maybe we can put cpuid_max_physaddr as a field in vcpu struct?
--
regards
Yang, Sheng
>
> Index: kvm/arch/x86/kvm/x86.c
> ===
> --- kvm.orig/arch/x86/kvm/x86.c
> +++ kvm/arch/x8
e.
>
> Handle this event and print useful information for diagnostics.
Looks fine to me, thanks!
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is can mean only a few minutes of usable run time. Instead, track
> used GSIs in a bitmap.
>
> Signed-off-by: Alex Williamson
> ---
Acked.
--
regards
Yang, Sheng
>
> v2: Added mutex to protect gsi bitmap
> v3: Updated for comments from Michael Tsirkin
> No longer dep
On Wednesday 13 May 2009 12:45:11 Alex Williamson wrote:
> Use 'r' for the return value since gsi is unsigned.
>
> Signed-off-by: Alex Williamson
> ---
Acked.
--
regards
Yang, Sheng
>
> v2: Use 'r' instead of a cast, per Sheng Yang
>
> hw/device-
On Wednesday 13 May 2009 12:10:34 Alex Williamson wrote:
> On Tue, 2009-05-12 at 21:42 -0600, Alex Williamson wrote:
> > On Wed, 2009-05-13 at 11:30 +0800, Yang, Sheng wrote:
> > > > + kvm->used_gsi_bitmap = malloc(gsi_bytes);
> > > &g
On Wednesday 13 May 2009 11:55:50 Alex Williamson wrote:
> On Wed, 2009-05-13 at 11:36 +0800, Yang, Sheng wrote:
> > On Wednesday 13 May 2009 06:14:01 Alex Williamson wrote:
> > > --- a/hw/device-assignment.c
> > > +++ b/hw/device-assignment.c
> >
if ((int)(assigned_dev->entry->gsi) < 0) {
> perror("assigned_dev_update_msi: kvm_get_irq_route_gsi");
> return;
> }
Use a return value(r) seems better.
And I realized there is memory leak here. Entry seems haven't been freed for
err
gt; + pthread_mutex_init(&kvm->gsi_mutex, NULL);
> +
> + gsi_count = kvm_get_gsi_count(kvm);
> + /* Round up so we can search ints using ffs */
> + gsi_bytes = (gsi_count + 31) / 32;
CMIW, should it be gsi_bytes = (gsi_count + 7) / 8? This looks like bits-to-
int.
_host_irq() mutex_lock(&kvm->lock);
> -> cancel_work_sync() [blocked]
>
> Workaround the issue by dropping kvm->lock for cancel_work_sync().
>
> Reported-by: Alex Williamson
> From: Sheng Yang
> Signed-off-by: Marcelo Tosatti
Another calling pat
> change the IRQ injection to use a separate spinlock, kill the workqueue
> and call kvm_set_irq from the assigned device interrupt handler.
Peferred the latter, though needs more work. But the only reason for put a
workqueue here is because kvm->lock is a mutex? I can't believe... If so,
ync() [blocked]
> I wonder if we need finer granularity locking to avoid this.
> Suggestions? Thanks,
This part again...
I think simply move kvm_deassign_irq() out of critical region is OK, and I
also add the lock which seems missing in deassign_guest_irq(). Would post a
patch soon.
se
> -return KVM_IOAPIC_NUM_PINS;
> + if (!kvm->max_gsi) {
> + int i;
> +
> + /* Round the number of GSIs supported to a 4 byte
> + * value so we can search it using ints and ffs */
> + i = kvm_get_gsi_count(k
On Monday 09 March 2009 11:42:05 Yang, Sheng wrote:
> On Sunday 08 March 2009 22:30:16 Avi Kivity wrote:
> > Matthew Wilcox wrote:
> > > On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
> > >> Do those patches allow using a VF on the host (in other words,
y what's happened. I
think the problem is caused by guest driver, but didn't confirm(and I have
some misunderstandings with ZhaoYu for I thought we are agree on the reason,
but after confirm with him, he didn't agree). I am doing more investigations
to find the real cause.
--
rega
On Saturday 28 February 2009 01:54:31 Marcelo Tosatti wrote:
> On Fri, Feb 27, 2009 at 12:17:01PM +0800, Yang, Sheng wrote:
> > On Friday 27 February 2009 07:50:54 Marcelo Tosatti wrote:
> > > Can someone with HW test this please?
> >
> > Good catch! The patch works f
ms more proper here, though more changes are needed for MSI-X(seems we need
one ack notifier for one vector in MSI-X).
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
than that, having the interrupt handler and work handlers run in
> parallel sounds like asking for trouble (could not spot any obvious
> problem, but better not have to, its fragile).
Well, my original purpose is a FIFO between interrupt handler and work(for
MSI-X), but seems too complex... A
the future.
>
> The following patch (which contains the bugfix for 1) and disabled
> reinjection) fixes the severe time drift on RHEL4 with "clock=tsc".
> What I'm proposing is to condition reinjection with an option
> (-kvm-pit-no-reinject or something).
I agree th
this if we see a Windows bug or if the
> change is incorrect (but me feeling tends to the former).
Confirmed that "-cpu pentium" solve the problem. But...
Sorry for that I've found that I neglected some info on the spec. SDM 3B
5.3.1 "External Interrupts".
&
state after software enable (a
little more possibility).
I will give a update if I got more infos.
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
tch still not checked in, so I
haven't written a complete version because of lacking code base. I only got a
experiment patch by hand, expose MSI cap to guest and enable MSI when guest
wrote MSI enable bit. Well, I prefer to give you a complete version after
Amit's patch is there. (I wil
On Saturday 13 September 2008 16:55:27 Avi Kivity wrote:
> Avi Kivity wrote:
> > Yang, Sheng wrote:
> >> On Thursday 04 September 2008 11:30:20 Yang, Sheng wrote:
> >>> From ebe4ea311305d2910dcdcff2510662da0dc2c742 Mon Sep 17 00:00:00 2001
> >>> From: Shen
v_kernel {
> > int host_busnr;
> > int host_devfn;
> > int host_irq;
> > + u16 guest_msi_addr;
>
> u32? or even u64?
Oops...
Well, here is enough for MSI (I mean u16 for msi_data), for PCI spec define
the size. But I'd better extend m
[Oops, outlook even didn't notice that last mail don't have subject then send
it out...]
>From eab008da232cd9cc09dd8071bd15796c8e46f6bd Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 2 Oct 2008 14:21:06 +0800
Subject: [PATCH 2/2] KVM: Implement OR logic on guest shared I
>From eab008da232cd9cc09dd8071bd15796c8e46f6bd Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 2 Oct 2008 14:21:06 +0800
Subject: [PATCH 2/2] KVM: Implement OR logic on guest shared IRQ line
Now IOAPIC and PIC treat every kvm_set_irq() as from one separate interrupt
source
>From e6b784985c14afe9805bfc8706858884b0259ab5 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 2 Oct 2008 14:20:22 +0800
Subject: [PATCH 1/2] KVM: Separate interrupt sources
Keep a record of current interrupt state before update, and don't
assert/deassert repeatly. So that
Linux Desktop in the company also down, have
to post patch with outlook)...
Thanks!
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 24 September 2008 17:51:24 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> 2. shared guest pci interrupts
> >>
> >> That's a correctness issue. No matter how many interrupts we have, we
> >> may have sharing issues. Of course with only three t
sue.
Let's wait host to disable the IRQ line - of course, the guest device can't
be recovered too.
It's just a initial purpose, I think it may work. The problem is if the gap is
easy to catch... But at least, I think a physical continuous one should be
much different f
work?
And about the mask of pci irq, how about disable PCI device interrupt using
Device Control Register bit 10? Not sure if it would affect the pending
transaction, also not sure all device support this (though they should
support).
--
regards
Yang, Sheng
--
To unsubscribe from this list
On Wednesday 24 September 2008 16:38:35 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> - Shared Interrupt support
> >
> > I still don't know who would do this. It's very important for VT-d real
> > usable. If nobody interested in it, I would pick it
fy MTRR msr in MP. Especially, step 4 enter no-fill cache mode(set CR0.CD
bit and clean NW bit), step 12 re-enabled the caching(clear this two bits).
We based on these behaviors to detect MTRR update.
(Forgot to raise the bug to Avi, recalled it now...)
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
; and "device" file, e.g. some
fix up by host PCI subsystem in kernel.
Maybe it can be delay a little for a following patch, but we should address
this issue... Maybe we can use libpci? There are more fields than vender and
device got this problem, like "irq".
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
uld got two bugs. :)
--
regards
Yang, Sheng
> /Jd
>
> --- On Wed, 9/24/08, Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > From: Yang, Sheng <[EMAIL PROTECTED]>
> > Subject: Re: KVM Migration fails
> > To: kvm@vger.kernel.org, "[EMAIL PROTECTED]" <
il&aid=2106661&group_id=180599&atid=893831
I think a git bisect can also help.
--
regards
Yang, Sheng
>
> /Jd
>
> Details
> ===
>
> migration: write failed (Connection reset by peer)^M
> Migration failed! ret=0 error=9
>
> Source : KVM-73, Cent OS 5.2, 64 b
On Thursday 25 September 2008 12:54:46 Yang, Sheng wrote:
> On Tuesday 23 September 2008 22:54:53 Amit Shah wrote:
> > From: Or Sagi <[EMAIL PROTECTED]>
> > From: Nir Peleg <[EMAIL PROTECTED]>
> > From: Amit Shah <[EMAIL PROTECTED]>
> > From: Ben-Ami
ailed
Can you have a look at it? (and the patch you sent to Weidong don't got this
problem.)
Thanks.
--
regards
Yang, Sheng
> Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
> ---
> qemu/Makefile.target|1 +
> qemu/hw/device-assignment.c | 665
>
On Tuesday 23 September 2008 23:04:48 Jan Kiszka wrote:
> Yang, Sheng wrote:
> > On Friday 19 September 2008 20:03:02 Jan Kiszka wrote:
> >> LINT0 of the LAPIC can be used to route PIT events as NMI watchdog
> >> ticks into the guest. This patch aligns the in-kernel irqc
On Wednesday 24 September 2008 17:22:53 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> We only have three pci interrupts at this point (though this could be
> >> easily extended); if you start the guest with a non-trivial number of
> >> devices, you will have shared g
On Wednesday 24 September 2008 16:53:15 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> Shared guest interrupts is a prerequisite for merging into mainline.
> >> Without this, device assignment is useless in anything but a benchmark
> >> scenario. I won't push devi
On Wednesday 24 September 2008 16:38:35 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> - MSI support (WIP)
> >> - MTRR/PAT support of EPT (WIP)
> >> - MTRR/PAT support of shadow (WIP)
> >> - Basic FLR support (WIP)
> >
>
id you mean?
>
Got confused...
I think we are talking about share host interrupts, that is pre-assigned
device shared IRQ with other devices.
Why share guest interrupts is a prerequisite...
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm&
his. It's very important for VT-d real
usable. If nobody interested in it, I would pick it up, but after Oct. 6
(after National Holiday in China).
--
regards
Yang, Sheng
> - Add dummy driver to hide/unbind passthrough device from host
> kernel
>
> If I omit some good feat
On Tuesday 23 September 2008 17:45:44 Gleb Natapov wrote:
> On Tue, Sep 23, 2008 at 05:42:02PM +0800, Yang, Sheng wrote:
> > > > That is exactly what I am using. Run it with SMP hal and do
> > > > hibernate.
> > >
> > > Oh... Finally found how to ena
On Tuesday 23 September 2008 17:37:00 Yang, Sheng wrote:
> On Tuesday 23 September 2008 17:26:55 Gleb Natapov wrote:
> > On Tue, Sep 23, 2008 at 05:24:50PM +0800, Yang, Sheng wrote:
> > > On Tuesday 23 September 2008 17:15:09 Gleb Natapov wrote:
> > > > On Tue, Se
On Tuesday 23 September 2008 17:26:55 Gleb Natapov wrote:
> On Tue, Sep 23, 2008 at 05:24:50PM +0800, Yang, Sheng wrote:
> > On Tuesday 23 September 2008 17:15:09 Gleb Natapov wrote:
> > > On Tue, Sep 23, 2008 at 05:08:09PM +0800, Yang, Sheng wrote:
> > > > >
On Tuesday 23 September 2008 17:15:09 Gleb Natapov wrote:
> On Tue, Sep 23, 2008 at 05:08:09PM +0800, Yang, Sheng wrote:
> > > > >>> We still get here with vmx->soft_vnmi_blocked = 1. Trying to find
> > > > >>> out how.
> > > > >&
On Tuesday 23 September 2008 17:15:09 Gleb Natapov wrote:
> On Tue, Sep 23, 2008 at 05:08:09PM +0800, Yang, Sheng wrote:
> > > > >>> We still get here with vmx->soft_vnmi_blocked = 1. Trying to find
> > > > >>> out how.
> > > > >&
te_interrupts, but only if the exit
> > takes place after the NMI has been successfully delivered to the guest
> > (which is not the case if invoking the handler raises an exception). So
> > far for the theory...
>
> Okey, I have this one in dmesg:
> kvm_handle_exit:
On Tuesday 23 September 2008 16:47:54 Jan Kiszka wrote:
> Yang, Sheng wrote:
> > On Monday 22 September 2008 19:00:38 Avi Kivity wrote:
> >> Jan Kiszka wrote:
> >>>> Maybe the answer is to generate the local nmi via an IPI-to-self
> >>>> command to t
t kvm_
> vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, cpu_based_vm_exec_control);
> ++vcpu->stat.nmi_window_exits;
>
> + /*
> +* If the user space waits to inject a NNI, exit as soon as
> possible +*/
o... found a typo :)
And also
ropped it
because it cause BSOD on some version of Windows(IRQ_NOT_EQUAL_OR_LESS). I
don't remember the exactly situation there, but you may have a try.
--
regards
Yang, Sheng
>
> Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
> ---
> arch/x86/kvm/i8254.c | 15 +
we needn't worry about that, and this shouldn't cause any trouble AFAIK...
Jan, seems we need to do more investigating on the issues you met...
--
regards
Yang, Sheng
> > And is it safe to
> > assume VMX == LAPIC available and usable?
>
> Yes.
>
> > However,
to replace
NMI window here, otherwise for the period between IRET and VMEXIT, host
physical NMIs would be handled by guest handler.
4. Check "IRQ Window" exit, if "Blocking by NMI" is cleared(also STI and SS),
we can inject NMI.
It's just untested idea, and I think it&#x
On Thursday 04 September 2008 11:30:20 Yang, Sheng wrote:
> From ebe4ea311305d2910dcdcff2510662da0dc2c742 Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Thu, 4 Sep 2008 03:11:48 +0800
> Subject: [PATCH] KVM: VMX: Move private memory slot position
>
&g
On Thursday 11 September 2008 16:50:37 Avi Kivity wrote:
> Yang, Sheng wrote:
> > From: Sheng Yang <[EMAIL PROTECTED]>
> > Date: Thu, 31 Jul 2008 13:43:58 +0800
> > Subject: [PATCH] KVM: Fix QEmu interrupted HLT emulation
> >
> > QEmu can interrupt VCPU from
ssor/manuals/
It contains EPT and VPID and other new things on Nehalem. I would work on
clearing up the code according to the latest spec soon (yeah, we also only
got it for days...)
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
On Sunday 07 September 2008 21:31:54 Avi Kivity wrote:
> Why not to a
>
> if (!shadow_access_mask)
>return 0;
>
> in the beginning?
Oops...
>
> I guess returning 'old' is safer than returning 'young'.
Yeah, me too, though possibly cause thrashing.
How about this one?
--
From: Sheng Ya
s/pci/iova.h" and "drivers/pci/intel-iommu.h"
> >already exists. And I get both files rejected.
> >So I take the headers from the KVM 1/2 Patchfile and use these a
> >"iova.h" and "intel-iommu.h". Kernel compiles without errors.
> >
> >
From ebe4ea311305d2910dcdcff2510662da0dc2c742 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 4 Sep 2008 03:11:48 +0800
Subject: [PATCH] KVM: VMX: Move private memory slot position
PCI device assignment would map guest MMIO spaces as separate slot, so it is
possible that t
From f95d06a16a820d4fff59ccc88b422f7d051e7330 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 4 Sep 2008 03:21:38 +0800
Subject: [PATCH] kvm: libkvm: Modify userspace memory slot limit to 32
To keep consistent with kernel space.
Signed-off-by: Sheng Yang <[EMAIL PROTECTED
Hi Avi
It seems something wrong with my git-send-email, and I can't got my post from
kvm@vger.kernel.org, so resend it. Sorry for inconvenient.
Thanks!
--
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Mon, 1 Sep 2008 13:22:09 +0800
Subject: [PATCH] KVM: VMX: Always return 0 for clear_flush_young(
Amit's latest userspace patch? What's about kernel part?
--
regards
Yang, Sheng
> 1) // Applied Micro Circuits Corp. APCI1500 Signal processing controller
>
> Warning: No DNS servers found
> Registered host PCI device 03:00.0 ("03:00.0") as guest device 00:03.0
> assigned_de
t has already been enabled... did you load the
> >driver for the NIC in the host? With pass-through the device is
> >"owned" by the guest.
>
> No.
> The driver was not loaded.
> It is not possible to start qemu with a pci-device used by the host.
> (I try this
send/received.
>
> What can i do to find the problem? (Debugging?)
Hi Gregor
Can you have a look at your dmesg and post it here? I think we can got some
clue.
Thanks!
--
regards
Yang, Sheng
>
> Regards,
>
> Gregor Glomm
> --
> To unsubscribe from this list: send
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Mon, 1 Sep 2008 17:28:59 +0800
Subject: [PATCH] KVM: MMU: Fix overflow of SHADOW_PT_INDEX with EPT in 32pae
EPT is 4 level by default in 32pae (48bits), but virtual address only
got 32 bits. This result in SHADOW_PT_INDEX() overflow when try to
fetch leve
On Sunday 31 August 2008 23:13:54 Avi Kivity wrote:
> [EMAIL PROTECTED] wrote:
> > From: Sheng Yang <[EMAIL PROTECTED]>
> >
> > We use a "fake" A/D bit for EPT, to keep epte behaviour consistent with
> > shadow spte. But it's not that good for MMU notifier. Now we can only
> > expect return young=0
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Fri, 29 Aug 2008 14:02:29 +0800
Subject: [PATCH] KVM: MMU: Add shadow_accessed_shift
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/mmu.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
On Thursday 21 August 2008 09:45:29 Yang, Sheng wrote:
> On Thursday 21 August 2008 00:43:22 Muli Ben-Yehuda wrote:
> > On Wed, Aug 20, 2008 at 06:04:26PM +0300, Avi Kivity wrote:
> > > Other noteworthy changes: speedups of both virtio-net and qcow2
> > > with cache=o
ification... I think we mentioned that in recent comments, and I
meant to remind Ben about that, but forgot it...
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From a8ca7dd8f5fe0125e7b7d0a21f5caddacd754911 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Mon, 18 Aug 2008 11:04:22 +0800
Subject: [PATCH] KVM: Fix wrong KVM_GET_LAPIC
Which caused migration fail in recent commits.
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x8
1 - 100 of 165 matches
Mail list logo
