On Sat, Apr 26, 2008 at 08:54:23PM -0500, Anthony Liguori wrote:
> Avi can correct me if I'm wrong, but I don't think the consensus of that
> discussion was that we're going to avoid putting mmio pages in the rmap.
My first impression on that discussion was that pci-passthrough mmio
can't be sw
Andrea Arcangeli wrote:
> On Sat, Apr 26, 2008 at 01:59:23PM -0500, Anthony Liguori wrote:
>
>>> +static void kvm_unmap_spte(struct kvm *kvm, u64 *spte)
>>> +{
>>> + struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >>
>>> PAGE_SHIFT);
>>> + get_page(page);
>>>
>>>
>>
On Sat, Apr 26, 2008 at 01:59:23PM -0500, Anthony Liguori wrote:
>> +static void kvm_unmap_spte(struct kvm *kvm, u64 *spte)
>> +{
>> +struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >>
>> PAGE_SHIFT);
>> +get_page(page);
>>
>
> You should not assume a struct page exists fo
Mohammed Gamal wrote:
>> Why do that unconditionally, instead of only when in a big-real-mode state?
>>
>
> Is big-real-mode the only state where we have problems?
>
In general, we need to emulate whenever we are in a VT-unfriendly state,
where that is defined as guest state that fails t
Andrea Arcangeli wrote:
> Hello everyone,
>
> here it is the mmu notifier #v14.
>
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.25/mmu-notifier-v14/
>
> Please everyone involved review and (hopefully ;) ack that this is
> safe to go in 2.6.26, the most important i
Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ryan Harper wrote:
>
>> @@ -388,9 +395,10 @@ static void kvm_add_signal(struct qemu_kvm_signal_table
>> *sigtab, int signum)
>>
>> void kvm_init_new_ap(int cpu, CPUState *env)
>> {
>> +pthread_mutex_lock(&vcpu_m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Harper wrote:
> @@ -388,9 +395,10 @@ static void kvm_add_signal(struct qemu_kvm_signal_table
> *sigtab, int signum)
>
> void kvm_init_new_ap(int cpu, CPUState *env)
> {
> +pthread_mutex_lock(&vcpu_mutex);
> pthread_create(&vcpu_info[
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Harper wrote:
> +/* block until cond_wait occurs */
> +pthread_mutex_lock(&vcpu_mutex);
> +/* now we can signal */
> +pthread_cond_signal(&qemu_vcpuup_cond);
> +pthread_mutex_unlock(&vcpu_mutex);
It is not necessary to take th
I resend this, because It's could be helpful for another users.
>From David Mair <[EMAIL PROTECTED]>:
I saw your message on the kvm-devel list and I think I can advise you.
I don't yet have a functioning subscription to the list so replying
there is not simple for me. If this works out for you pl
Hello everyone,
here it is the mmu notifier #v14.
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.25/mmu-notifier-v14/
Please everyone involved review and (hopefully ;) ack that this is
safe to go in 2.6.26, the most important is to verify that this is a
noop when
Avi Kivity wrote:
> Anthony Liguori wrote:
>> The second stage is to use a loop of x86_emulate() to run all 16-bit
>> code (instead of using vm86 mode). This will allow us to support
>> guests that use big real mode.
>>
>>
>
> Why do that unconditionally, instead of only when in a big-real-mo
Hi Glauber, sorry for late reply.
well, I'm no longer able to reproduce the problem in the same way (with
backtraces etc) as before, but anyways enabling paravirt_clock with or
without Your patches on SMP guest still causes troubles:
on my phenom machine, the kernel hangs after printing
"PCI-GART
Hello,
after updating kvm-userland.git, kvm.git and linux-2.6-hg, and after
make distclean and rebuild with slightly reduced .config, I can't
compile the external module anymore. Looking into it with V=1, $(src)
defines to "" and including /external-module-compat.h clearly fails. I
fixed it like b
On Sat, Apr 26, 2008 at 08:17:34AM -0500, Robin Holt wrote:
> Since this include and the one for mm_types.h both are build breakages
> for ia64, I think you need to apply your ia64_cpumask and the following
> (possibly as a single patch) first or in your patch 1. Without that,
> ia64 doing a git-b
On Thu, Apr 24, 2008 at 07:41:45PM +0200, Andrea Arcangeli wrote:
> A full new update will some become visible here:
>
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.25/mmu-notifier-v14-pre3/
I grabbed these and built them. Only change needed was another include
Hello
It is some solution, how to set up public IP address directly to guest
system? I my test case, now I use only situation, when host system
have all public addresses and I set up NAT to guests. Some
applications, like VOIP, is difficult to run behind NAT. Then, the
problem is running this kind
My doctor cannot help asking me how I grew so big http://www.islound.com/
-
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 priori
Hi,
I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in 64bit
mode while starting up WinXP:
kvm: emulating exchange as write
Unable to handle kernel NULL pointer dereference at RIP:
[] :kvm:x86_emulate_insn+0x3fa/0x4240
PGD 7658d067 PUD 242a6067 PMD 0
Oops: 0002 [1]
On Sat, Apr 26, 2008 at 9:49 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Anthony Liguori wrote:
>
> > The second stage is to use a loop of x86_emulate() to run all 16-bit code
> (instead of using vm86 mode). This will allow us to support guests that use
> big real mode.
> >
> >
> >
>
> Why do tha
Marcelo Tosatti wrote:
> On Wed, Apr 23, 2008 at 09:30:06AM +0300, Avi Kivity wrote:
>
>>> as I got no reply, I guess it is a bad setup on my part. If that might
>>> help, this happenned while I was doing a "make -j" on webkit svn tree
>>> (ie. heavy c++ compilation workload) .
>>>
>>>
>>>
Ryan Harper wrote:
> There is a race between when the vcpu thread issues a create ioctl and when
> apic_reset() gets called resulting in getting a badfd error.
>
>
The problem is indeed there, but the fix is wrong:
> main threadvcpu thread
> diff --git a/qemu/qemu-kvm.c b/qemu/
21 matches
Mail list logo
