> I rechecked and I guarantee that the patches where Christoph isn't
> listed are developed by myself and he didn't write a single line on
> them. In any case I expect Christoph to review (he's CCed) and to
> point me to any attribution error. The only mistake I did once in that
> area was to
> No, the best interface is one where the driver doesn't even see
> inode or file. Of course that's not actually possible in a few
> nasty cases like the infiniband code, and for those it might be
> better to do the fd_isntall themselves.
Yeah, I've been thinking about this some more, and I t
> spin_lock(&kvm_lock);
> +if (--kvm->refcount) {
> +spin_lock(&kvm_lock);
obvious typo here...
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http
> If we let the caller call fd_install(), then it may be messed up WRT
> cleanup (fd, file, inode).
Yes, that is a tiny bit tricky (need to call put_unused_fd() if you
don't install the fd).
> How about removing the inode pointer handout altogether, and *doing*
> fd_install() inside anon_in
> http://git.kernel.org/?p=linux/kernel/git/viro/vfs-2.6.git;a=commit;h=49be4f8114e6ff0efdab10ebba2493fb67bc3034
Actually, looking closer at the kvm changes here, I think that
create_vcpu_fd() needs the same treatment as kvm_dev_ioctl_create_vm()
gets in the patch because of the race I mentioned
> http://git.kernel.org/?p=linux/kernel/git/viro/vfs-2.6.git;a=commit;h=49be4f8114e6ff0efdab10ebba2493fb67bc3034
>
> I'm fine with both approaches.
Both ways are OK with me too, although Al's change leaves the trap in
the anon_inode_getfd() in that all users have to keep in mind the race
again
> > The anonymous inodes interface anon_inode_getfd() calls fd_install()
> > for the newly created fd, which does not work for some use cases where
> > the caller must do futher initialization before exposing the file to
> > userspace. This is also probably not the safest interface, since the
face. The
signalfd and timerfd changes are untested but are trivial enough (just
adding an fd_install() call) that they are almost certainly OK.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
fs/anon_inodes.c| 20 +++-
fs/eventfd.c| 12 +++
It seems that we've come up with two reasonable cases where it makes
sense to use these notifiers for InfiniBand/RDMA:
First, the ability to safely to DMA to/from userspace memory with the
memory regions mlock()ed but the pages not pinned. In this case the
notifiers here would seem to suit us wel
> > Chelsio's T3 HW doesn't support this.
> Not so far I guess but it could be equipped with these features right?
I don't know anything about the T3 internals, but it's not clear that
you could do this without a new chip design in general. Lot's of RDMA
devices were designed expecting that w
[Adding [EMAIL PROTECTED] to get the IB/RDMA people involved]
This thread has patches that add support for notifying drivers when a
process's memory map changes. The hope is that this is useful for
letting RDMA devices handle registered memory without pinning the
underlying pages, by updating the
> I thought the adaptor can always remove the mapping by renegotiating
> with the remote side? Even if its dumb then a callback could notify the
> driver that it may be required to tear down the mapping. We then hold the
> pages until we get okay by the driver that the mapping has been remov
> We have done several rounds of discussion on linux-kernel about this so
> far and the IB folks have not shown up to join in. I have tried to make
> this as general as possible.
Sorry, this has been on my "things to look at" list for a while, but I
haven't gotten a chance to really understan
seems like we probably want this for 2.6.22... it fixes a panic that
I've seen actually reported by several users. Is there any risk to
merging it?
i guess getting it into 2.6.22.1 would be OK too.
-
This SF.net email is spo
I don't see any documented restrictions about preemption being
disabled when this function is called, but...
> +int on_one_cpu(int cpu, void (*func) (void *info), void *info,
> + int retry, int wait)
> +{
> +int ret;
> +int this_cpu;
> +
> +this_cpu = get_cpu();
what
> This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19
> with patches available.
> Subject: KVM: guest crash
> References : http://lkml.org/lkml/2007/1/8/163
> Submitter : Roland Dreier <[EMAIL PROTECTED]>
> Handled-By : Avi Kivity <
> if (is_writeble_pte(*shadow_ent))
> -return 0;
> +return 1;
With this patch, it looks like my guest is surviving the load that
triggered the oops before. So I think this fixes the issue I saw as well.
I assume you'll send this in for 2.6.20?
- R.
-
> I've managed to reproduce a bug with similar characteristics: a write
> fault into a present, writable kernel page. The attached patch should
> fix it.
Sorry for the delay in continuing this thread. Anyway, the oops seems
to be pretty reproducible by running the makewhatis and locate db
upd
I'm running a 64-bit Fedora 6 install as a guest on a host running
2.6.20-rc4 with the kvm-10 userspace release. The CPU is a Xeon 5160
and I have 6 GB of RAM. The guest is given 512 MB of memory. I left
the guest idle overnight, and the makewhatis cron job seems to have
triggered this:
Una
> Applied, thanks. Please add signed-off-by's in the future, even to
> trivial patches.
Will do. I wasn't aware you were tracking s-o-b lines, since I didn't
see any in your revision log.
- R.
-
Take Surveys. Earn Cash.
> I find it hard to believe, can you test qemu with user mode networking
> and see what happens?
If I remove "-net tap" from my qemu command line I don't get any of
the rtc messages.
- R.
-
Take Surveys. Earn Cash. Influe
Actually ... this does not seem to be a kvm issue at all!
I just rebooted my system to try again, and I started a qemu guest and
got the spew of rtc lost interrupt messages. But I also noticed:
Could not initialize KVM, will disable KVM support
and in fact I had forgotten to load the kvm module
I still see the
rtc: lost some interrupts at 1024Hz.
message with your patch applied.
One thing I noticed is that my serial console seems to be related to
the messages. I just booted my machine with the serial console
printing kernel messages, and I saw the lost interrupt messages when
starting
Here's a trivial patch that adds log levels to all printks. This
avoids ugly things like
Message from [EMAIL PROTECTED] at Wed Nov 29 14:01:01 2006 ...
roland-xeon-2 kernel: [81842.565619] msrs: 6
popping up in a console on my system when starting a guest.
---
--- kvm-5/kernel/vmx.c 2006-11-2
Thanks, I will give this a try today.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -
> You're using a Core (not 2) processor on a laptop, right?
No, a Xeon 5160 (Core 2 basically I believe). And I'm running a
64-bit kernel.
> Does your machine like Xen?
I've not tried to be honest...
-
Take Surveys. Earn
> Second, some of the time when starting a guest, I see a flood of
> messages like
By the way, just to be clear, the rest of the time everything works
fine. Although after booting the Fedora Core 6 x86_64 installer, I
did see the following kernel messages:
kvm: unhandled rdmsr: 417
inject_gene
Hi, I've just installed kvm release 5 on systems with Intel Xeon 5160
processors, running up-to-date git kernels (2.6.19-rc6).
First, since I built my kernel with a separate object directory
("O=xxx"), I needed the patch below to the kernel module Kbuild file
to get things to work (otherwise the b
> Either that or a bunch of ugly .byte macros.
After reading this thread, I have to say that this seems preferable to
relying on new-ish binutils. Someday in the future we can fix it up
but I think too many people are still using old gas versions now.
You can hide the .byte crap in one place wi
> That's gas 2.16.1. I assume it needs some super-new binutils.
>
> I'm not sure what to do about this. What's the minimum version?
According to http://kvm.sourceforge.net/howto.html :
A recent enough binutils (>= 2.16.91.0.2) for vmx instruction support
- R.
-
30 matches
Mail list logo
