Do not start MAC address with 00: 01: or FF:
Those are illegal addresses.
Try 50: or 52: or something
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's stil
Bugs item #1949429, was opened at 2008-04-23 10:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1949429&group_id=180599
Please note that this message will contain a full copy
David S. Ahern wrote:
> kvm_stat -1 is practically impossible to time correctly to get a good snippet.
>
>
I've added a --log option to get vmstat-like output. I've also added
--fields to select which fields are of interest, to avoid the need for
280-column displays. That's now pushed to kv
David S. Ahern wrote:
> I added tracers to kvm_mmu_page_fault() that include collecting tsc cycles:
>
> 1. before vcpu->arch.mmu.page_fault()
> 2. after vcpu->arch.mmu.page_fault()
> 3. after mmu_topup_memory_caches()
> 4. after emulate_instruction()
>
> So the delta in the trace reports show:
> -
Anthony Liguori wrote:
> Jerone Young wrote:
>
>> What I am asking is do I have all the proper options in my kernel config
>> set to use it?
>>
>>
>
> Yes. You just need CONFIG_VIRTIO_NET and CONFIG_VIRTIO_PCI. The
> remaining options will be automatically selected.
>
>
We should
Hi,
I installed a fresh hardy rc guest image (from
ubuntu-8.04-rc-alternate-i386.iso) yesterday and after entering my
password the guest crashes.
It may be useful to know that the guest already successfully used the
sound system at that point to indicate a successful boot.
This does not happen
Hi,
I'm trying libvirt-0.4.2, it should support initiating guest shutdown for
KVM domains. But for some reason it doesn't work for me, I'm using linux
guests with external kernel, if I run poweroff from within the domain, it
shutdowns correctly, but trying to shutdown the domain from host using
On Wed, Apr 23, 2008 at 10:40 AM, <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm trying libvirt-0.4.2, it should support initiating guest shutdown for
> KVM domains. But for some reason it doesn't work for me, I'm using linux
> guests with external kernel, if I run poweroff from within the domain, it
>
Сложные вопросы признания "прочих" расходов
25 апpеля 2008, г. Москва
Программа семинара
1. Расходы на командировки, в том числе - новое в 2008 г:
- понятие командировки и служебной поездки, разъезды
- максимальная продолжительность командировки
- направление работников в командировку и оформл
On Wed, 23 Apr 2008, Luca Tettamanti wrote:
> libvirt sends "system_powerdown" to the monitor; is ACPI is enabled
> then the guest sees the event but it's free to ignore it (it's the
> same as pressing the power button on a real machine: the OS sees the
> event and may start the shutdown, ask
[EMAIL PROTECTED] wrote:
>
>
> On Wed, 23 Apr 2008, Luca Tettamanti wrote:
>
>
>> libvirt sends "system_powerdown" to the monitor; is ACPI is enabled
>> then the guest sees the event but it's free to ignore it (it's the
>> same as pressing the power button on a real machine: the OS sees the
>> e
Avi Kivity wrote:
> Stuart Sheldon wrote:
>> 2) When I started writing the management scripts to start and stop the
>> guests from the command line, I was using KVM-63 which allowed me to
>> send a "system_powerdown" to the console, this would send a PWR to the
>> guest's acpid that would bring the
[EMAIL PROTECTED] wrote:
> Hi Avi,
> thanks for info. Can You tell me which commit has caused the problem
> so I can revert it in my testing sources? I don't see any reverts in
> git (yet).
6bb0805aeabd5c6ef5408f57c7da5ca6385dd0f5.
--
Do not meddle in the internals of kernels, for they are su
Hi Avi,
thanks for info. Can You tell me which commit has caused the problem so I
can revert it in my testing sources? I don't see any reverts in git (yet).
thanks!
n.
On Wed, 23 Apr 2008, Avi Kivity wrote:
> [EMAIL PROTECTED] wrote:
>>
>>
>> On Wed, 23 Apr 2008, Luca Tettamanti wrote:
>>
Am Dienstag, 22. April 2008 schrieb Rusty Russell:
[...]
> diff -r a098f19a6da5 include/linux/virtio_config.h
> --- a/include/linux/virtio_config.h Sun Apr 20 14:41:02 2008 +1000
> +++ b/include/linux/virtio_config.h Sun Apr 20 15:07:45 2008 +1000
> @@ -16,7 +16,7 @@
> #define VIRTIO_CONFIG_S_
Rusty,
is there a reason why we dont export the virtio headers for
9p, balloon, console, pci, and virtio_ring? kvm uses make sync,
but I think it is still useful to heave these headers exported
as they might be useful for other userspace tools.
I dont export virtio.h, because it does not seem to
My fault, of course I couldn't find, I was looking into kvm.git and not
kvm-userspace.git :-/
but anyways, it works properly now, thanks a lot!
n.
On Wed, 23 Apr 2008, Avi Kivity wrote:
> [EMAIL PROTECTED] wrote:
>> Hi Avi,
>> thanks for info. Can You tell me which commit has caused the problem
Christian Borntraeger wrote:
> Am Dienstag, 22. April 2008 schrieb Rusty Russell:
> [...]
>
>> diff -r a098f19a6da5 include/linux/virtio_config.h
>> --- a/include/linux/virtio_config.h Sun Apr 20 14:41:02 2008 +1000
>> +++ b/include/linux/virtio_config.h Sun Apr 20 15:07:45 2008 +1000
>> @@ -1
Am Mittwoch, 23. April 2008 schrieb Avi Kivity:
> >> #define VIRTIO_CONFIG_S_FAILED0x80
> >>
> >> #ifdef __KERNEL__
> >> -struct virtio_device;
> >> +#include
> >>
> >
> > I just realized, that this breaks make headers_check as we dont export
> > virtio.h (and we dont want to e
This patch is userspace part of the "batch writes to MMIO" patch.
When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids too have to many context switches on operations
that can wait.
Signed-off-by: Lau
These two patches allow to batch writes to MMIO.
When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids to have too many context switches on operations
that can wait.
WARNING: this breaks compatibility
This patch is the kernel part of the "batch writes to MMIO" patch.
When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids to have too many context switches on operations
that can wait.
WARNING: this bre
On Tue, Apr 22, 2008 at 01:30:53PM -0700, Christoph Lameter wrote:
> One solution would be to separate the invalidate_page() callout into a
> patch at the very end that can be omitted. AFACIT There is no compelling
> reason to have this callback and it complicates the API for the device
> driver
On 4/22/08, Alexander Graf <[EMAIL PROTECTED]> wrote:
> I believe that's the way to go. If you have spare time on your hands, feel
> free to integrate my multiboot patches as well.
>
OK, that looks straightforward enough.
Thanks,
Q
>
> On Apr 22, 2008, at 11:07 AM, Nguyen Anh Quynh wrote:
>
>
>
On 4/22/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Nguyen Anh Quynh wrote:
>
> > Hi,
> >
> > This should be submitted to upstream (but not to kvm-devel list), but
> > this is only the test code that I want to quickly send out for
> > comments. In case it looks OK, I will send it to upstream l
On Tue, Apr 22, 2008 at 04:14:26PM -0700, Christoph Lameter wrote:
> We want a full solution and this kind of patching makes the patches
> difficuilt to review because later patches revert earlier ones.
I know you rather want to see KVM development stalled for more months
than to get a partial so
On Tue, Apr 22, 2008 at 06:07:27PM -0500, Robin Holt wrote:
> > The only other change I did has been to move mmu_notifier_unregister
> > at the end of the patchset after getting more questions about its
> > reliability and I documented a bit the rmmod requirements for
> > ->release. we'll think lat
On 4/23/08, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Nguyen Anh Quynh wrote:
>
> > Hi,
> >
> > I am thinking about comibing this ROM with the extboot. Both two ROM
> > are about "booting", so I think that is reasonable. So we will have
> > only 1 ROM that supports both external boot and Linux bo
The preliminary KVM Forum 2008 agenda is now online at
http://kforum.qumranet.com/KVMForum/agenda.php
If you haven't done so already, please register! There is a big
"Register Now" button on the page. Early bird registration ends May 1.
Note we have a few more sessions in the pipeline; the
Laurent Vivier wrote:
> These two patches allow to batch writes to MMIO.
>
> When kernel has to send MMIO writes to userspace, it stores them
> in memory until it has to pass the hand to userspace for another
> reason. This avoids to have too many context switches on operations
> that can wait.
>
>
Le mercredi 23 avril 2008 à 17:05 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > These two patches allow to batch writes to MMIO.
> >
> > When kernel has to send MMIO writes to userspace, it stores them
> > in memory until it has to pass the hand to userspace for another
> > reason. This
Laurent Vivier wrote:
> This patch is the kernel part of the "batch writes to MMIO" patch.
>
> When kernel has to send MMIO writes to userspace, it stores them
> in memory until it has to pass the hand to userspace for another
> reason. This avoids to have too many context switches on operations
>
Laurent Vivier wrote:
> Le mercredi 23 avril 2008 à 17:05 +0300, Avi Kivity a écrit :
>
>> Laurent Vivier wrote:
>>
>>> These two patches allow to batch writes to MMIO.
>>>
>>> When kernel has to send MMIO writes to userspace, it stores them
>>> in memory until it has to pass the hand to us
On Wed, Apr 23, 2008 at 03:36:19PM +0200, Andrea Arcangeli wrote:
> On Tue, Apr 22, 2008 at 06:07:27PM -0500, Robin Holt wrote:
> > > The only other change I did has been to move mmu_notifier_unregister
> > > at the end of the patchset after getting more questions about its
> > > reliability and I
Le mercredi 23 avril 2008 à 17:31 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > This patch is the kernel part of the "batch writes to MMIO" patch.
> >
> > When kernel has to send MMIO writes to userspace, it stores them
> > in memory until it has to pass the hand to userspace for another
Laurent Vivier wrote:
>>>
>>>
>> This breaks ordering on smp guests. batch_data needs to be a kvm thing,
>> not a vcpu thing, and locked, of course.
>>
>
> - is ordering between vcpu important when we already delay operations ?
>
Yes. Ordering is very different from delaying.
Avi Kivity wrote:
> Laurent Vivier wrote:
>
> That's the lovely animation. You can time XP startup, or look at system
> time in 'top' once it stabilizes. Also compare total host_state_reloads
> to boot in kvm_stat (each costs 5 usec, after discount).
>
Win2k's boot up animation (the movin
Anthony Liguori wrote:
>
> The ne2k is pretty mmio heavy. You should be able to observe a boost
> with something like iperf (guest=>host) I would think if this is a
> real savings.
>
If we're just improving ne2k, the complexity isn't worth it. We have
two better nics which are widely supporte
>> Avi Kivity wrote:
>>
>>> David S. Ahern wrote:
>>>
I added the traces and captured data over another apparent lockup of
the guest.
This seems to be representative of the sequence (pid/vcpu removed).
(+4776) VMEXIT [ exitcode = 0x, rip = 0x
c
On Wed, Apr 23, 2008 at 03:44:27PM +0200, Andrea Arcangeli wrote:
> On Tue, Apr 22, 2008 at 04:14:26PM -0700, Christoph Lameter wrote:
> > We want a full solution and this kind of patching makes the patches
> > difficuilt to review because later patches revert earlier ones.
>
> I know you rather
Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> The ne2k is pretty mmio heavy. You should be able to observe a boost
>> with something like iperf (guest=>host) I would think if this is a
>> real savings.
>>
>
> If we're just improving ne2k, the complexity isn't worth it. We have
> two better
On Wednesday 23 April 2008 20:55:50 Christian Borntraeger wrote:
> Am Dienstag, 22. April 2008 schrieb Rusty Russell:
> [...]
>
> > diff -r a098f19a6da5 include/linux/virtio_config.h
> > --- a/include/linux/virtio_config.h Sun Apr 20 14:41:02 2008 +1000
> > +++ b/include/linux/virtio_config.h Sun A
On Wed, Apr 23, 2008 at 09:47:47AM -0500, Robin Holt wrote:
> It also makes the API consistent. What you are proposing is equivalent
> to having a file you can open but never close.
That's not entirely true, you can close the file just fine it by
killing the tasks leading to an mmput. From an use
David S. Ahern wrote:
> I've continued drilling down with the tracers to answer that question. I have
> done runs with tracers in paging64_page_fault and it showed the overhead is
> with
> the fetch() function. On my last run the tracers are in paging64_fetch() as
> follows:
>
> 1. after is_prese
On Wed, Apr 23, 2008 at 10:45:36AM -0500, Robin Holt wrote:
> XPMEM has passed all regression tests using your version 12 notifiers.
That's great news, thanks! I'd greatly appreciate if you could test
#v13 too as I posted it. It already passed GRU and KVM regressions
tests and it should work fine
Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
[...]
> The ne2k is pretty mmio heavy. You should be able to observe a boost
> with something like iperf (guest=>host) I would think if this is a real
> savings.
I like your advices :-D
I use iperf with e1000 emulation and a sl
On Tue, Apr 22, 2008 at 04:20:35PM -0700, Christoph Lameter wrote:
> I guess I have to prepare another patchset then?
If you want to embarrass yourself three time in a row go ahead ;). I
thought two failed takeovers was enough.
-
Laurent Vivier wrote:
> Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
> [...]
>
>> The ne2k is pretty mmio heavy. You should be able to observe a boost
>> with something like iperf (guest=>host) I would think if this is a real
>> savings.
>>
>
> I like your advices :
On Tue, Apr 22, 2008 at 07:28:49PM -0500, Jack Steiner wrote:
> The GRU driver unregisters the notifier when all GRU mappings
> are unmapped. I could make it work either way - either with or without
> an unregister function. However, unregister is the most logical
> action to take when all mappings
Avi Kivity wrote:
>
> Ah! The flood detector is not seeing the access through the
> kmap_atomic() pte, because that access has gone through the emulator.
> last_updated_pte_accessed(vcpu) will never return true.
>
> Can you verify that last_updated_pte_accessed(vcpu) indeed always
> returns f
Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
> > [...]
> >
> >> The ne2k is pretty mmio heavy. You should be able to observe a boost
> >> with something like iperf (guest=>host) I w
Laurent Vivier wrote:
> Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
>
>> Laurent Vivier wrote:
>>
>>> Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
>>> [...]
>>>
>>>
The ne2k is pretty mmio heavy. You should be able to observe a boost
Laurent Vivier wrote:
> This patch is the kernel part of the "batch writes to MMIO" patch.
>
> When kernel has to send MMIO writes to userspace, it stores them
> in memory until it has to pass the hand to userspace for another
> reason. This avoids to have too many context switches on operations
>
Anthony Liguori wrote:
>>
>> How can I check that ? How can I measure latency ?
>>
>
> ping (from guest to host)
>
The guest will halt anyway, flushing its mmio queue.
Perhaps a ping while a background process spins, consuming all cpu.
--
Do not meddle in the internals of kernels, for they a
You may have spotted this already. If so, just ignore this.
It looks like there is a bug in copy_page_range() around line 667.
It's possible to do a mmu_notifier_invalidate_range_start(), then
return -ENOMEM w/o doing a corresponding mmu_notifier_invalidate_range_end().
--- jack
-
On Tuesday 22 April 2008 11:49:12 pm Avi Kivity wrote:
> Marcelo Tosatti wrote:
> > http://article.gmane.org/gmane.comp.emulators.qemu/24192
> >
> > BTW, Avi, this patch should be included in kvm-userspace.
>
> I've tried this out about a week ago and didn't get very good
> results.
I've tried tha
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> The ne2k is pretty mmio heavy. You should be able to observe a boost
>>> with something like iperf (guest=>host) I would think if this is a
>>> real savings.
>>>
>>>
>> If we're just improving ne2k, the
On Wed, Apr 23, 2008 at 06:26:29PM +0200, Andrea Arcangeli wrote:
> On Tue, Apr 22, 2008 at 04:20:35PM -0700, Christoph Lameter wrote:
> > I guess I have to prepare another patchset then?
Apologies for my previous not too polite comment in answer to the
above, but I thought this double patchset wa
On Wed, Apr 23, 2008 at 12:09:09PM -0500, Jack Steiner wrote:
>
> You may have spotted this already. If so, just ignore this.
>
> It looks like there is a bug in copy_page_range() around line 667.
> It's possible to do a mmu_notifier_invalidate_range_start(), then
> return -ENOMEM w/o doing a cor
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> I know you rather want to see KVM development stalled for more months
> than to get a partial solution now that already covers KVM and GRU
> with the same API that XPMEM will also use later. It's very unfair on
> your side to pretend to stall other pe
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> Implement unregister but it's not reliable, only ->release is reliable.
Why is there still the hlist stuff being used for the mmu notifier list?
And why is this still unsafe?
There are cases in which you do not take the reverse map locks or mmap_se
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> On Tue, Apr 22, 2008 at 04:20:35PM -0700, Christoph Lameter wrote:
> > I guess I have to prepare another patchset then?
>
> If you want to embarrass yourself three time in a row go ahead ;). I
> thought two failed takeovers was enough.
Takeover? I'd
On Wed, Apr 23, 2008 at 11:02:18AM -0700, Christoph Lameter wrote:
> We have had this workaround effort done years ago and have been
> suffering the ill effects of pinning for years. Had to deal with
Yes. In addition to the pinning, there's lot of additional tlb
flushing work to do in kvm withou
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> The only way to avoid failing because of vmalloc space shortage or
> oom, would be to provide a O(N*N) fallback. But one that can't be
> interrupted by sigkill! sigkill interruption was ok in #v12 because we
> didn't rely on mmu_notifier_unregister to
On Wed, Apr 23, 2008 at 11:09:35AM -0700, Christoph Lameter wrote:
> Why is there still the hlist stuff being used for the mmu notifier list?
> And why is this still unsafe?
What's the problem with hlist, it saves 8 bytes for each mm_struct,
you should be using it too instead of list.
> There ar
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> will go in -mm in time for 2.6.26. Let's put it this way, if I fail to
> merge mmu-notifier-core into 2.6.26 I'll voluntarily give up my entire
> patchset and leave maintainership to you so you move 1/N to N/N and
> remove mm_lock-sem patch (everythin
Avi, Joerg,
While trying to boot a RHEL-4 guest on latest KVM tip on an AMD machine, I
found that the guest would consistently crash when trying to setup the NMI
watchdog. I traced it down to the following commit:
51ef1ac7b23ee32bfcc61c229d634fdc1c68b38a
It seems that in that commit, the K7
On Wed, Apr 23, 2008 at 11:19:26AM -0700, Christoph Lameter wrote:
> If unregister fails then the driver should not detach from the address
> space immediately but wait until -->release is called. That may be
> a possible solution. It will be rare that the unregister fails.
This is the current ide
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> On Wed, Apr 23, 2008 at 11:09:35AM -0700, Christoph Lameter wrote:
> > Why is there still the hlist stuff being used for the mmu notifier list?
> > And why is this still unsafe?
>
> What's the problem with hlist, it saves 8 bytes for each mm_struct,
On Wed, Apr 23, 2008 at 11:21:49AM -0700, Christoph Lameter wrote:
> No I really want you to do this. I have no interest in a takeover in the
Ok if you want me to do this, I definitely prefer the core to go in
now. It's so much easier to concentrate on two problems at different
times then to atta
On Wed, Apr 23, 2008 at 11:27:21AM -0700, Christoph Lameter wrote:
> There is a potential issue in move_ptes where you call
> invalidate_range_end after dropping i_mmap_sem whereas my patches did the
> opposite. Mmap_sem saves you there?
Yes, there's really no risk of races in this area after in
On Wed, 23 Apr 2008, Andrea Arcangeli wrote:
> Yes, there's really no risk of races in this area after introducing
> mm_lock, any place that mangles over ptes and doesn't hold any of the
> three locks is buggy anyway. I appreciate the audit work (I also did
> it and couldn't find bugs but the more
On Wednesday 23 April 2008 01:05:50 am Alexey Eremenko wrote:
> Do not start MAC address with 00: 01: or FF:
> Those are illegal addresses.
>
> Try 50: or 52: or something
Thanks for the tip. I tried those but the same problem persisted. As I
played around with several MAC addresses (even t
Le mercredi 23 avril 2008 à 11:48 -0500, Anthony Liguori a écrit :
> Laurent Vivier wrote:
> > Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
> >
> >> Laurent Vivier wrote:
> >>
> >>> Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
> >>> [...]
> >>>
> >
I think 00 is pretty much the standard starting byte for MAC addresses.
I've seen the same problem - for KVM 61-65, with a 2.6.23 host kernel.
Fedora8, Windows 2008 see the MAC address correctly with an e1000
interface.
But in Windows 2003 with e1000, the last four bytes of the MAC address
are a
Avi Kivity wrote:
> David Abrahams wrote:
>>> Versions of kvm producing this sort of output are common in
>>> archaeological digs. Please try a more recent release.
>>>
>>
>> Well, I'll try Hardy Heron soon enough, I suppose. It's due out in 2
>> weeks.
>>
>> I'm sure you under
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks to both of you for answering my questions. And thank you Avi for
fixing the bug. I did not report it because of some of the conversation
I saw in the mailing list regarding that feature, and thought it might
have been removed.
Thanks again...
On Wed, Apr 23, 2008 at 06:15:45PM +0200, Andrea Arcangeli wrote:
> Once I get confirmation that everyone is ok with #v13 I'll push a #v14
> before Saturday with that cosmetical error cleaned up and
> mmu_notifier_unregister moved at the end (XPMEM will have unregister
> don't worry). I expect the
> > It sounds reasonable to expect so. ACPI has objects for devices, not
> > functions (IIRC).
>
> So what I dislike about multifunction devices is the fact that a single
> slot shares an IRQ, and that special code is required in the QEMU
> drivers (virtio guest capability might not always be pr
David Abrahams wrote:
Unless you have a recent Intel processor, the combination of SMP and
Windows XP will give noticeably lower performance. I recommend sticking
with uniprocessor in such cases.
>>> I have a Core Duo; isn't that recent enough?
>>>
>>>
Robin Holt wrote:
>> an hurry like we are, we can't progress without this. Infact we can
>>
>
> SGI is under an equally strict timeline. We really needed the sleeping
> version into 2.6.26. We may still be able to get this accepted by
> vendor distros if we make 2.6.27.
>
The difference
Stuart Sheldon wrote:
> Thanks to both of you for answering my questions. And thank you Avi for
> fixing the bug. I did not report it because of some of the conversation
> I saw in the mailing list regarding that feature, and thought it might
> have been removed.
If you see us removing a feature y
On Wednesday 23 April 2008 01:09:25 pm Michael Lilie (mlilie) wrote:
> Fedora8, Windows 2008 see the MAC address correctly with an e1000
> interface.
>
> But in Windows 2003 with e1000, the last four bytes of the MAC
> address are always FF:FF:FF:FF.
> The first two bytes can be either what I set o
On Wed, Apr 23, 2008 at 06:37:13PM +0200, Andrea Arcangeli wrote:
> I'm afraid if you don't want to worst-case unregister with ->release
> you need to have a better idea than my mm_lock and personally I can't
> see any other way than mm_lock to ensure not to miss range_begin...
But wait, mmu_notif
while investigating the revert of "fix sci irq set when acpi timer" I
discovered the reason. Please also re-revert the original patch.
Thanks,
Dor
-
[PATCH] Don't quit IO thread before all lvcpus stopped
Call pause_all_threads() before exiting the i/o thread
main loop.
This scenario h
1 file changed, 36 insertions(+), 20 deletions(-)
kernel/Makefile | 56 +++
- This adapts perviously sent patch to new changes to kernel/Makefile
This patch add the ability for make sync in the kernel directory to work for
mulitiple a
> diff --git a/kernel/Makefile b/kernel/Makefile
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -1,5 +1,10 @@ include ../config.mak
> include ../config.mak
>
> +ARCH_DIR=$(ARCH)
> +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
> + ARCH_DIR=x86
> +endif
> +
>
This sets ARCH_DIR to
On Wednesday 23 April 2008 20:57:00 Christian Borntraeger wrote:
> Rusty,
>
> is there a reason why we dont export the virtio headers for
> 9p, balloon, console, pci, and virtio_ring? kvm uses make sync,
> but I think it is still useful to heave these headers exported
> as they might be useful for
My current patched kernel is 2.6.25-rc9:
CONFIG_HAVE_KVM=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
and then while compiling kvm-66:
/root/download/kvm/kvm-66>./configure --disable-gcc-check
--prefix=/usr/local/kvm --with-patched-kernel
make[1]: Entering directory `/mnt/sdc2/download/kv
On Wed, 2008-04-23 at 18:02 -0500, Anthony Liguori wrote:
> > diff --git a/kernel/Makefile b/kernel/Makefile
> > --- a/kernel/Makefile
> > +++ b/kernel/Makefile
> > @@ -1,5 +1,10 @@ include ../config.mak
> > include ../config.mak
> >
> > +ARCH_DIR=$(ARCH)
> > +ifneq '$(filter $(ARCH_DIR), x86_64
1 file changed, 37 insertions(+), 21 deletions(-)
kernel/Makefile | 58 +++
- This adapts perviously sent patch to new changes to kernel/Makefile
- Fixes improper check in conditional
This patch add the ability for make sync in
2 files changed, 6 insertions(+), 1 deletion(-)
configure |6 ++
libkvm/Makefile |1 -
This is a relic of the big userspace refactoring, but today libkvm does should
not include settings from the test suite. This patch resolves this and removes
the overwriting of setting from th
On Thu, Apr 24, 2008 at 12:19:28AM +0200, Andrea Arcangeli wrote:
> /dev/kvm closure. Given this can be a considered a bugfix to
> mmu_notifier_unregister I'll apply it to 1/N and I'll release a new
I'm not sure anymore this can be considered a bugfix given how large
change this resulted in the lo
On Tuesday 22 April 2008 18:16:41 Avi Kivity wrote:
> Yang, Sheng wrote:
> > From 73c33765f3d879001818cd0719038c78a0c65561 Mon Sep 17 00:00:00 2001
> > From: Sheng Yang <[EMAIL PROTECTED]>
> > Date: Fri, 18 Apr 2008 17:15:39 +0800
> > Subject: [PATCH] kvm: qemu: Enable EPT support for real mode
> >
94 matches
Mail list logo
