Joerg Roedel wrote:
> On Mon, Apr 28, 2008 at 07:35:10PM +0200, Jan Kiszka wrote:
>> Hi,
>>
>> sorry, the test environment is not really reproducible (stock kvm-66,
>> yet unpublished NMI support by Sheng Yang and me, special guest), but
>> I'm just fishing for some ideas on what may cause the floo
On Tue, Apr 29, 2008 at 10:38:41AM +0200, Jan Kiszka wrote:
> Joerg Roedel wrote:
> > Hmm, seems we have to check for DF and triple faults in the
> > kvm_queue_exception functions too. Does the attached patch fix the
> > problem (patch is against kvm-66).
>
> Thanks, it indeed fixes the warnings (
From: Avi Kivity <[EMAIL PROTECTED]>
Date: Sun, 27 Apr 2008 12:40:29 +0300
> Avi Kivity wrote:
> > I propose moving the kvm lists to vger.kernel.org, for the following
> > benefits:
> >
> > - better spam control
> > - faster service (I see significant lag with the sourceforge lists)
> > - no ads
Joerg Roedel wrote:
> On Tue, Apr 29, 2008 at 10:38:41AM +0200, Jan Kiszka wrote:
>> Joerg Roedel wrote:
>>> Hmm, seems we have to check for DF and triple faults in the
>>> kvm_queue_exception functions too. Does the attached patch fix the
>>> problem (patch is against kvm-66).
>> Thanks, it indeed
We make the dma_mapping_ops structure to point to our structure
so that every DMA access goes through us.
We make a hypercall for every device that does a DMA operation
to find out if it is an assigned device -- so that we can make
hypercalls on each DMA access. The result of this hypercall is
cac
This patchset implements PVDMA for handling DMA requests from
devices assigned to the guest from the host machine.
They're also available from
git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git pvdma
These patches are based on my pci-passthrough tree, which is available
from
g
We introduce three hypercalls:
1. When the guest wants to check if a particular device is an assigned device
(this is done once per device by the guest to enable / disable hypercall-
based translation of addresses)
2. map: to convert guest phyical addresses to host physical address to pass o
dma_alloc_coherent() doesn't call dma_ops->alloc_coherent in case no IOMMU
translations are necessary. However, if the device doing the DMA is a
physical device assigned to the guest OS by the host, we need to map
all the DMA addresses to the host machine addresses. This is done via
hypercalls to t
The -kernel option generates a new boot sector for
the boot drive which jumps directly to the supplied
kernel rather than running the standard bootloader.
Trivially fix generate_bootsect() to handle the
case where we're booting using extboot.
Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
---
On Tue, 29 Apr 2008, Andrea Arcangeli wrote:
>
> My point of view is that there was no rcu when I wrote that code, yet
> there was no reference count and yet all locking looks still exactly
> the same as I wrote it. There's even still the page_table_lock to
> serialize threads taking the mmap_sem
Hi,
looks like we are getting better and better here in hitting yet
unsupported corner-case features of KVM :). This time our guest fiddles
with hardware debugging registers, but quickly gets unhappy as they do
not yet have the expected effect.
Joerg, I found you SVM-related patch series in the a
Amit Shah <[EMAIL PROTECTED]> writes:
> This patchset implements PVDMA for handling DMA requests from
> devices assigned to the guest from the host machine.
You forgot to post a high level design overview of how this works,
what it is good for, what are the design trade offs etc.?
Include that
Amit Shah <[EMAIL PROTECTED]> writes:
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 388b113..678cafb 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -443,6 +443,17 @@ dma_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dm
Amit Shah <[EMAIL PROTECTED]> writes:
> +
> +static struct page *page;
> +static unsigned long page_gfn;
Bad variable names
> +
> +const struct dma_mapping_ops *orig_dma_ops;
I suspect real dma ops stacking will need some further thought than
your simple hacks
> +
> + match = find_matching_pt
Hello,
This patch should solve the problem observed during protected mode
transitions that appears for example during the installation of
openSuse-10.3. Unfortunately there is an issue that crashes
kvm-userspace. I'm not sure if it's a problem introduced by the
patch or if the patch is good and r
Hi Hugh!!
On Tue, Apr 29, 2008 at 11:49:11AM +0100, Hugh Dickins wrote:
> [I'm scarcely following the mmu notifiers to-and-fro, which seems
> to be in good hands, amongst faster thinkers than me: who actually
> need and can test this stuff. Don't let me slow you down; but I
> can quickly clarify
On Tuesday 29 April 2008 19:01:32 Andi Kleen wrote:
> Amit Shah <[EMAIL PROTECTED]> writes:
> > +const struct dma_mapping_ops *orig_dma_ops;
>
> I suspect real dma ops stacking will need some further thought than
> your simple hacks
Yes; that's something we're planning to do.
> Haven't read furt
On Tuesday 29 April 2008 18:44:23 Andi Kleen wrote:
> Amit Shah <[EMAIL PROTECTED]> writes:
> > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> > index 388b113..678cafb 100644
> > --- a/arch/x86/kernel/pci-dma.c
> > +++ b/arch/x86/kernel/pci-dma.c
> > @@ -443,6 +443,17 @@ dma_a
This patch allows VMA's that contain no backing page to be used for guest
memory. This is a drop-in replacement for Ben-Ami's first page in his direct
mmio series. Here, we continue to allow mmio pages to be represented in the
rmap.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git
On Tue, Apr 29, 2008 at 03:07:25PM +0200, Jan Kiszka wrote:
> Hi,
>
> looks like we are getting better and better here in hitting yet
> unsupported corner-case features of KVM :). This time our guest fiddles
> with hardware debugging registers, but quickly gets unhappy as they do
> not yet have th
Amit Shah wrote:
> We introduce three hypercalls:
> 1. When the guest wants to check if a particular device is an assigned device
>(this is done once per device by the guest to enable / disable hypercall-
>based translation of addresses)
>
> 2. map: to convert guest phyical addresses to ho
On Tue, Apr 29, 2008 at 09:32:09AM -0500, Anthony Liguori wrote:
> + vma = find_vma(current->mm, addr);
> + if (vma == NULL) {
> + get_page(bad_page);
> + return page_to_pfn(bad_page);
> + }
Here you must check vm_start ad
The current KVM x86 exception code handles double and triple faults only for
page fault exceptions. This patch extends this detection for every exception
that gets queued for the guest.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Cc: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 3
On Monday 28 April 2008 16:23:04 Jerone Young wrote:
> +/* This function is to manipulate a cell with multiple values */
> +void dt_cell_multi(void *fdt, char *node_path, char *property,
> + uint32_t *val_array, int size)
> +{
> +
> + int offset;
> + int ret
* Anthony Liguori <[EMAIL PROTECTED]> [2008-04-28 17:30]:
> We hold qemu_mutex while machine->init() executes, which issues a VCPU create.
> We need to make sure to not return from the VCPU creation until the VCPU
> file descriptor is valid to ensure that APIC creation succeeds.
>
> However, we al
Andrea Arcangeli wrote:
> On Tue, Apr 29, 2008 at 09:32:09AM -0500, Anthony Liguori wrote:
>
>> +vma = find_vma(current->mm, addr);
>> +if (vma == NULL) {
>> +get_page(bad_page);
>> +return page_to_pfn(bad_page);
>> +}
>
This patch eliminates the use of sigtimedwait() in the IO thread. To avoid the
signal/select race condition, we use a pipe that we write to in the signal
handlers. This was suggested by Rusty and seems to work well.
There are a lot of cleanup/simplification opportunities with this but I've
limit
On Mon, Apr 28, 2008 at 06:28:06PM -0700, Christoph Lameter wrote:
> On Tue, 29 Apr 2008, Andrea Arcangeli wrote:
>
> > Frankly I've absolutely no idea why rcu is needed in all rmap code
> > when walking the page->mapping. Definitely the PG_locked is taken so
> > there's no way page->mapping could
> I however doubt this will bring us back to the same performance of the
> current spinlock version, as the real overhead should come out of
> overscheduling in down_write ai anon_vma_link. Here an initially
> spinning lock would help but that's gray area, it greatly depends on
> timings, and on ve
On Tuesday 29 April 2008 20:14:16 Glauber Costa wrote:
> Amit Shah wrote:
> > +static struct kvm_pv_dma_map*
> > +find_pci_pv_dmap(struct list_head *head, dma_addr_t dma)
> > +{
>
> might be better to prefix those functions with kvm? Even though they are
> static, it seems to be the current practi
On Tue, Apr 29, 2008 at 10:50:30AM -0500, Robin Holt wrote:
> You have said this continually about a CONFIG option. I am unsure how
> that could be achieved. Could you provide a patch?
I'm busy with the reserved ram patch against 2.6.25 and latest kvm.git
that is moving from pages to pfn for pci
Joerg Roedel wrote:
> On Tue, Apr 29, 2008 at 03:07:25PM +0200, Jan Kiszka wrote:
>> Hi,
>>
>> looks like we are getting better and better here in hitting yet
>> unsupported corner-case features of KVM :). This time our guest fiddles
>> with hardware debugging registers, but quickly gets unhappy as
On Tue, 2008-04-29 at 10:06 -0500, Hollis Blanchard wrote:
> On Monday 28 April 2008 16:23:04 Jerone Young wrote:
> > +/* This function is to manipulate a cell with multiple values */
> > +void dt_cell_multi(void *fdt, char *node_path, char *property,
> > + uint32_t *val_array
Guillaume Thouvenin wrote:
> Hello,
>
> This patch should solve the problem observed during protected mode
> transitions that appears for example during the installation of
> openSuse-10.3. Unfortunately there is an issue that crashes
> kvm-userspace. I'm not sure if it's a problem introduced by t
Guillaume Thouvenin wrote:
> Hello,
>
> This patch should solve the problem observed during protected mode
> transitions that appears for example during the installation of
> openSuse-10.3. Unfortunately there is an issue that crashes
> kvm-userspace. I'm not sure if it's a problem introduced by
Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
> Guillaume Thouvenin wrote:
> > Hello,
> >
> > This patch should solve the problem observed during protected mode
> > transitions that appears for example during the installation of
> > openSuse-10.3. Unfortunately there is an issue
Le mardi 29 avril 2008 à 19:09 +0200, Laurent Vivier a écrit :
> Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
> > Guillaume Thouvenin wrote:
> > > Hello,
> > >
> > > This patch should solve the problem observed during protected mode
> > > transitions that appears for example du
Guillaume Thouvenin wrote:
> Hello,
>
> It's strange because handle_vmentry_failure() is not called. I'm trying
> to see where is the problem, any comments are welcome
>
[ 979.761321] handle_exception: unexpected, vectoring info 0x8306
intr info 0x8b0d
Is the error I'm seeing.
Regar
Laurent Vivier wrote:
> Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
>
>> Guillaume Thouvenin wrote:
>>
>>> Hello,
>>>
>>> This patch should solve the problem observed during protected mode
>>> transitions that appears for example during the installation of
>>> openSuse-
This patch allows VMA's that contain no backing page to be used for guest
memory. This is a drop-in replacement for Ben-Ami's first page in his direct
mmio series. Here, we continue to allow mmio pages to be represented in the
rmap.
Since v1, I've taken into account Andrea's suggestions at using
This patch goes towards the direction of increasing general modularity of the
code. Code in vl.c that used to live inside target ifdefs, are moved to inside
the
target directories, in a new file called machine.c. They are the cpu save/load
and machine
registration
---
Makefile.target|
Hi. This is a proposal for reducing the impact of kvm functions in core qemu
code. This is by all means not ready, but I felt like posting it, so a
discussion
on it could follow.
The idea in this patch is to replace the specific kvm details from core qemu
files
like vl.c, with driver_yyy() funct
On 29/04/2008, Glauber Costa <[EMAIL PROTECTED]> wrote:
> This patch goes towards the direction of increasing general modularity of the
> code. Code in vl.c that used to live inside target ifdefs, are moved to
> inside the
> target directories, in a new file called machine.c. They are the cpu
>
Acked-by: Hollis Blanchard <[EMAIL PROTECTED]>
Avi, please apply for 2.6.26.
--
Hollis Blanchard
IBM Linux Technology Center
--- Begin Message ---
From: Christian Ehrhardt <[EMAIL PROTECTED]>
This patch adds the delivery of INTERRUPT_FP_UNAVAIL exceptions to the guest.
It's needed if a guest us
David Miller wrote:
> Should I create the list(s) now? If so, please let me know the
> names they should have.
>
I sent an email a couple of days ago to [EMAIL PROTECTED]:
> Hi, please create the following lists for kvm:
>
> kvm (x86 and general discussion)
> kvm-ppc (powerpc, managed by Ho
Anthony Liguori wrote:
> This patch allows VMA's that contain no backing page to be used for guest
> memory. This is a drop-in replacement for Ben-Ami's first page in his direct
> mmio series. Here, we continue to allow mmio pages to be represented in the
> rmap.
>
>
I like this very much, as
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> This patch allows VMA's that contain no backing page to be used for guest
>> memory. This is a drop-in replacement for Ben-Ami's first page in his direct
>> mmio series. Here, we continue to allow mmio pages to be represented in the
>> rmap.
>>
>
Hi Anthony,
How is -no-kvm-irqchip working with the patch?
On Tue, Apr 29, 2008 at 09:28:14AM -0500, Anthony Liguori wrote:
> This patch eliminates the use of sigtimedwait() in the IO thread. To avoid
> the
> signal/select race condition, we use a pipe that we write to in the signal
> handlers.
Glauber Costa wrote:
> Hi. This is a proposal for reducing the impact of kvm functions in core qemu
> code. This is by all means not ready, but I felt like posting it, so a
> discussion
> on it could follow.
>
> The idea in this patch is to replace the specific kvm details from core qemu
> files
Anthony Liguori wrote:
>>
>>
>>>
>>> struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
>>> {
>>> -return pfn_to_page(gfn_to_pfn(kvm, gfn));
>>> +pfn_t pfn;
>>> +
>>> +pfn = gfn_to_pfn(kvm, gfn);
>>> +if (pfn_valid(pfn))
>>> +return pfn_to_page(pfn);
>>> +
>>> +r
Marcelo Tosatti wrote:
> Hi Anthony,
>
> How is -no-kvm-irqchip working with the patch?
>
Seems to work fine. What is your expectation?
> On Tue, Apr 29, 2008 at 09:28:14AM -0500, Anthony Liguori wrote:
>
>> This patch eliminates the use of sigtimedwait() in the IO thread. To avoid
>> th
Amit Shah wrote:
>
>>> + if (is_error_page(host_page)) {
>>> + printk(KERN_INFO "%s: gfn %p not valid\n",
>>> + __func__, (void *)page_gfn);
>>> + r = -1;
>>>
>> r = -1 is not really informative. Better use some meaningful error.
>>
>
> The error's
Avi Kivity wrote:
> It depends on what's going on? Does a page table point to mmio? Or
> the glommerclock?
>
> Not sure there is a single answer.
>
>> Perhaps we should be replacing consumers of gfn_to_page() with
>> copy_to_user() instead?
>
> Indeed we should. The problem is access in atomic
Anthony Liguori wrote:
> Avi Kivity wrote:
>> It depends on what's going on? Does a page table point to mmio? Or
>> the glommerclock?
>>
>> Not sure there is a single answer.
>>
>>> Perhaps we should be replacing consumers of gfn_to_page() with
>>> copy_to_user() instead?
>>
>> Indeed we should
On Tuesday 29 April 2008 17:17:49 Avi Kivity wrote:
> Anthony Liguori wrote:
> > This patch allows VMA's that contain no backing page to be used for guest
> > memory. This is a drop-in replacement for Ben-Ami's first page in his
direct
> > mmio series. Here, we continue to allow mmio pages to be
On Tue, Apr 29, 2008 at 05:42:51PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti wrote:
> >Hi Anthony,
> >
> >How is -no-kvm-irqchip working with the patch?
> >
>
> Seems to work fine. What is your expectation?
Just wondering if vcpu's are being properly awake.
> >Make sure the IO thread ha
Jan Kiszka wrote:
> This still leaves me with the question how to handle the case when the
> host sets and arms some debug registers to debug the guest and the
> latter does the same to debug itself. Guest access will be trapped, OK,
> but KVM will then have to decide which value should actually be
Hollis Blanchard wrote:
> On Tuesday 29 April 2008 17:17:49 Avi Kivity wrote:
>
>> I like this very much, as it only affects accessors and not the mmu core
>> itself.
>>
>> Hollis/Xiantao/Carsten, can you confirm that this approach works for
>> you? Carsten, I believe you don't have mmio, but
Marcelo Tosatti wrote:
> Problem is if the IO thread _receives_ SIGIPI instead of some vcpu
> thread.
>
> So there is potential harm in not blocking it.
>
Hrm, aren't SIG_IPIs delivered to a particular thread-id though? When
would the IO thread receive a SIG_IPI?
>>> What is the reason for
Laurent Vivier wrote:
>> Why dst.val is not 0x53e10 ?
>>
>
> I can answer myself to this one:
>
> emulate_2op_SrcB("sal", c->src, c->dst, ctxt->eflags);
>
> does nothing if dst.byte == 0
>
> So next question is the good question...
>
>
>> Why dst.byte is 0 ?
>>
>>
Because dst.by
Fabian Deutsch wrote:
> Hey.
>
> I've been trying Microsoft Windows 2003 a couple of times. The wiki
> tells me that "everything" should work okay. It does, when using -smp 1,
> but gets ugly when using -smp 2 or so.
>
> SO might it be useful, to add the column "smp" to the "Guest Support
> Status"
Anthony Liguori wrote:
> We hold qemu_mutex while machine->init() executes, which issues a VCPU create.
> We need to make sure to not return from the VCPU creation until the VCPU
> file descriptor is valid to ensure that APIC creation succeeds.
>
> However, we also need to make sure that the VCPU t
On Tue, Apr 29, 2008 at 06:15:58PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti wrote:
> >Problem is if the IO thread _receives_ SIGIPI instead of some vcpu
> >thread.
> >
> >So there is potential harm in not blocking it.
> >
>
> Hrm, aren't SIG_IPIs delivered to a particular thread-id thoug
Avi Kivity wrote:
> Glauber Costa wrote:
>> Hi. This is a proposal for reducing the impact of kvm functions in
>> core qemu
>> code. This is by all means not ready, but I felt like posting it, so a
>> discussion
>> on it could follow.
>>
>> The idea in this patch is to replace the specific kvm de
Marcelo Tosatti wrote:
> Why? If you leave data in the pipe the next select() won't block.
>
> Isnt there the possibility that this loop can be stuck for significant
> amounts of time? If you're receiving lots of notifications through
> signals.
>
If you're getting that many signals, then sele
On Tue, Apr 29, 2008 at 06:44:29PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti wrote:
> >Why? If you leave data in the pipe the next select() won't block.
> >
> >Isnt there the possibility that this loop can be stuck for significant
> >amounts of time? If you're receiving lots of notifications
Marcelo Tosatti wrote:
> True.
>
> Either way, this starvation due to signals can't happen with the current
> scheme because signals are blocked. It seems a significant drawback.
>
Practically speaking, I don't see signal starving being a problem. Part
of the benefit of this approach is that
Glauber Costa wrote:
> Avi Kivity wrote:
>
>> Glauber Costa wrote:
>>
>>> Hi. This is a proposal for reducing the impact of kvm functions in
>>> core qemu
>>> code. This is by all means not ready, but I felt like posting it, so a
>>> discussion
>>> on it could follow.
>>>
>>> The idea in
On Tue, Apr 29, 2008 at 07:22:53PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti wrote:
> >True.
> >
> >Either way, this starvation due to signals can't happen with the current
> >scheme because signals are blocked. It seems a significant drawback.
> >
>
> Practically speaking, I don't see sig
Marcelo Tosatti wrote:
>>> Moving the signal handling + pipe write to a separate thread should get
>>> rid of it.
>>>
>>>
>> Yeah, but then you just introduce buffering problems since if you're
>> getting that many signals, the pipe will get full.
>>
>
> It is OK to lose signals if y
Bugs item #1953353, was opened at 2008-04-28 07:50
Message generated for change (Comment added) made by mtosatti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1953353&group_id=180599
Please note that this message will contain a full copy of the comment
On Tue, Apr 29, 2008 at 07:47:54PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti wrote:
> >>>Moving the signal handling + pipe write to a separate thread should get
> >>>rid of it.
> >>>
> >>>
> >>Yeah, but then you just introduce buffering problems since if you're
> >>getting that many s
Anthony Liguori wrote:
> Glauber Costa wrote:
>> Avi Kivity wrote:
>>
>>> Glauber Costa wrote:
>>>
Hi. This is a proposal for reducing the impact of kvm functions in
core qemu
code. This is by all means not ready, but I felt like posting it, so
a discussion
on it co
From: Avi Kivity <[EMAIL PROTECTED]>
Date: Wed, 30 Apr 2008 00:46:13 +0300
> I sent an email a couple of days ago to [EMAIL PROTECTED]:
>
> > Hi, please create the following lists for kvm:
> >
> > kvm (x86 and general discussion)
> > kvm-ppc (powerpc, managed by Hollis Blanchard)
> > kvm-ia64
Another tidbit for you guys as I make my way through various permutations:
I installed the RHEL3 hugemem kernel and the guest behavior is *much* better.
System time still has some regular hiccups that are higher than xen and esx
(e.g., 1 minute samples out of 5 show system time between 10 and 15%),
On Wed, Apr 30, 2008 at 01:48:38AM +0300, Avi Kivity wrote:
> Amit Shah wrote:
>>
+ if (is_error_page(host_page)) {
+ printk(KERN_INFO "%s: gfn %p not valid\n",
+ __func__, (void *)page_gfn);
+ r = -1;
>>> r = -1 is not really infor
On Tue, Apr 29, 2008 at 02:09:20PM -0500, Anthony Liguori wrote:
> This patch allows VMA's that contain no backing page to be used for guest
> memory. This is a drop-in replacement for Ben-Ami's first page in his direct
> mmio series. Here, we continue to allow mmio pages to be represented in the
On Tue, Apr 29, 2008 at 01:37:29PM +0300, Amit Shah wrote:
> dma_alloc_coherent() doesn't call dma_ops->alloc_coherent in case no
> IOMMU translations are necessary.
I always thought this was a huge wart in the x86-64 DMA ops. Would
there be strong resistance to fixing it so that alloc_coherent
m
78 matches
Mail list logo
