Glauber Costa wrote:
Gerd Hoffmann wrote:
Jeremy Fitzhardinge wrote:
Xen could change the parameters in the instant after
get_time_values(). That change could be as a result of
suspend-resume, so the parameters
and the tsc could be wildly different.
Ah, ok, forgot the rdtsc in the picture.
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 guest down gracefully. This
Thomas Cataldo wrote:
On Mon, Apr 21, 2008 at 9:57 PM, Thomas Cataldo
[EMAIL PROTECTED] wrote:
Hi,
I am running kvm-66 on top of a debian sid host with 2.6.24 (intel 32bit
host).
Got the following in my logs today :
Apr 21 17:55:01 buffy kernel: WARNING: at
Ian Kirk wrote:
Avi Kivity wrote:
For mass storage, we should follow the SCSI model with a single device
serving multiple disks, similar to what you suggest. Not sure if the
device should have a single queue or one queue per disk.
Don't you just end up re-implementing SCSI then,
Anthony Liguori wrote:
BTW, I've never been that convinced that hotplugging devices is as
useful as people make it out to be. I also think that's particularly
true when it comes to hot adding/removing very large numbers of disks.
On the contrary, the more disks you have, the more
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
Logically speaking, virtio is a bus. virtio supports all of the features
of a bus (discover, hot add, hot remove).
Right now, we map virtio devices directly onto the PCI bus.
The problem we're trying to address is limitations of the PCI bus. We
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
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=detailatid=893831aid=1949429group_id=180599
Please note that this message will contain a full copy of
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
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:
- cycles
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 make
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
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 the
[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
event and may
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 guest
[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
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
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
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 so I
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
@@ -16,7 +16,7
Am Mittwoch, 23. April 2008 schrieb Avi Kivity:
#define VIRTIO_CONFIG_S_FAILED0x80
#ifdef __KERNEL__
-struct virtio_device;
+#include linux/virtio.h
I just realized, that this breaks make headers_check as we dont export
virtio.h (and we dont want to export it
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:
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
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
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:
Hi,
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 later.
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
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 later if it
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 boot.
Is that
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
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 avoids to
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
that
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 userspace for
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
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. Also, we will
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 supported in
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 want
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 user
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
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
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 :-D
I use
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 false?
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 would think if
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
with something like
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
that
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 are
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
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 complexity isn't worth
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 was
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
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
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_sem
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 be
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 without
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 are
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 (everything
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
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 idea,
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,
you
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
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
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
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 :
[...]
The ne2k is
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
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 understand that most people
-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 present).
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?
No, this feature is
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 is that
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 you
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,
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
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
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 x86
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 other
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
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 i386)' ''
+
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
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
90 matches
Mail list logo
