Avi Kivity wrote:
On 06/15/2009 06:25 PM, Michael Tokarev wrote:
Avi Kivity wrote:
On 06/15/2009 05:15 PM, Erik Jacobson wrote:
[]
So if I understand what you're saying: best not to use kvm guests for build
servers with pre-Nehalem processors.
pre-Nehalem / pre-Barcelona, > 4 vcpus, yes.
The shutdown test logs into a VM and sends a shutdown command.
It serves two purposes:
- Test KVM's ability to shut down.
- Clean up after the other tests:
Currently VMs of the last test remain alive when Autotest finishes running.
When one guest finishes testing and another begins, the VM is autom
The shutdown test should always be last -- new tests will be added above it.
If the user chooses to run all tests on a guest, the guest will be shut down
by the final shutdown test. If the user selects a specific subset of the tests,
the guest will shut down if the shutdown test is included in th
On 06/16/2009 10:03 AM, Michael Tokarev wrote:
So if I understand what you're saying: best not to use kvm guests
for build
servers with pre-Nehalem processors.
pre-Nehalem / pre-Barcelona, > 4 vcpus, yes.
How about 2 vcpus, and how about AMD processors ?
2 vcpus (or 4) should be fine. AMD
On 06/15/2009 09:44 PM, Blue Swirl wrote:
pc-qemu-0.10?
pc-2009.06? Or given the hardware, should that be pc-1997?
pc-qemu-0.10 has the obvious benefit of allowing people to immediately
know what's the oldest version of qemu that supports it.
--
error compiling committee.c: too
On 06/15/2009 11:33 PM, Anthony Liguori wrote:
The basic issue is that:
migrate_fd_put_ready():bdrv_flush_all();
Does:
block.c:
foreach block driver:
drv->flush(bs);
Which in the case of raw, is just fsync(s->fd).
Any submitted request is not queued or flushed which will lead to the
On 06/16/2009 12:10 PM, Avi Kivity wrote:
Does anyone have a clever idea how to fix this without just waiting
for all IO requests to complete?
What's wrong with waiting for requests to complete? It should take a
few tens of milliseconds.
We could start throttling requests late in the live s
On Fri, Jun 12, 2009 at 03:56:04PM +0200, Jes Sorensen wrote:
> Hi,
>
> I figured out why Windows wasn't booting with the previous version
> of the patch. It seems it didn't like the forward declaration of the
> _PR.PRSC method.
>
> Instead I found that it does seem to work if I add the calling met
On 06/16/2009 11:50 AM, Gleb Natapov wrote:
Works for me with windows XP/7, but can you add a comment in DSDT where
_GRE.L02 should be why it is missing and where to find it.
Sure, here's an updated version with the comment. Thanks for testing it.
Cheers,
Jes
Move _PR block from the DSDT to a
Michael I don't fully understand why shutdown test is needed; Shutdown is
tested during reboot, where GuestOS must de-init itself.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
This is intended to save disk space. Requires ImageMagick (uses mogrify).
To enable:
convert_ppm_files_to_png = yes
To enable only for failed tests:
convert_ppm_files_to_png_on_error = yes
Reminder: by default PPM files are removed after the test (and after the
conversion, if requested). To ke
By default, always remove PPM files, and keep PNG files only for failed tests.
This shouldn't do much harm, because while PPMs can be incorporated directly
into step files, PNGs can be converted back to PPMs easily, and take less disk
space.
(PNG is a lossless compression format.)
The 'keep_ppm_fi
- "Alexey Eromenko" wrote:
> Michael I don't fully understand why shutdown test is needed; Shutdown
> is tested during reboot, where GuestOS must de-init itself.
The main motivation for a shutdown test is that it allows us to choose
whether VMs should be kept alive after the last test. Inc
Do not allow invalid MTRR/PAT values in set_msr_mtrr.
Please review carefully.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/x86.c
===
--- kvm.orig/arch/x86/kvm/x86.c
+++ kvm/arch/x86/kvm/x86.c
@@ -722,11 +722,53 @@ stat
On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > So long as the restrictions would be known to the management app via
> > some "what slots are available" mechanism in qemu, that sounds fine.
> >
>
> I'm not sure a "what slots are available" mechanism is as
On 06/16/2009 03:14 PM, Mark McLoughlin wrote:
On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
Mark McLoughlin wrote:
So long as the restrictions would be known to the management app via
some "what slots are available" mechanism in qemu, that sounds fine.
I'm not s
On Tue, 2009-06-16 at 15:28 +0300, Avi Kivity wrote:
> On 06/16/2009 03:14 PM, Mark McLoughlin wrote:
> > On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> So long as the restrictions would be known to the management app via
> >>> some "w
On Mon, Jun 15, 2009 at 04:03:10PM -0400, Steven Rostedt wrote:
>
> On Mon, 15 Jun 2009, Marcelo Tosatti wrote:
>
> > This allows use of the powerful ftrace infrastructure.
> >
> > See Documentation/trace/ for usage information.
> >
> > Signed-off-by: Marcelo Tosatti
> >
> > Index: kvm/arch/x
Avi Kivity wrote:
Does anyone have a clever idea how to fix this without just waiting
for all IO requests to complete?
What's wrong with waiting for requests to complete? It should take a
few tens of milliseconds.
An alternative would be to attempt to cancel the requests. This incurs
no n
On 06/16/2009 03:39 PM, Mark McLoughlin wrote:
Worst case we hardcode those numbers (gasp, faint).
Maybe we can just add the open slots to the -help output. That'd be nice
and clean.
Yeah, there's precedent too.
Or:
$ readlink /usr/share/qemu/machine-types/pc.dt
That w
On 06/16/2009 03:50 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Does anyone have a clever idea how to fix this without just waiting
for all IO requests to complete?
What's wrong with waiting for requests to complete? It should take a
few tens of milliseconds.
An alternative would be to at
Avi Kivity wrote:
Yes, that's even better (though without linux-aio, it's equivalent).
Not absolutely equivalent. There many be queued requests that haven't
yet been dispatched to the thread pool, but yeah, I understand what you
mean.
The tricky bit is that this has to happen at the devi
On 06/16/2009 03:57 PM, Anthony Liguori wrote:
The tricky bit is that this has to happen at the device layer
because the opaques cannot be saved in a meaningful way.
Do you mean the device has to record all cancelled requests and
replay them? I think we can do it at the block layer (thoug
sysenter/sysexit are not supported on AMD's 32bit compat mode, whereas
syscall is not supported on Intel's 32bit compat mode. To allow cross
vendor migration we emulate the missing instructions by setting up the
processor state accordingly.
The sysenter code was originally sketched by Amit Shah, it
handle_powerpc_dcr_read() and handle_powerpc_dcr_write() are two
powerpc specific functions that are called via libkvm callbacks.
However, grepping the source code finds simply no use of them. This
is probably due to the fact that powerpc now relies on a totally
qemu upstream implementation of kvm,
On Tue, 16 Jun 2009, Marcelo Tosatti wrote:
> >
> >
> > One suggestion. Instead of putting in arch specific trace points into
> > generic code, you can put these into arch/x86/kvm/trace.h ?
> >
> > Then you can in the Makefile add:
> >
> > CFLAGS_x86.o := -I.
> > CFLAGS_svm.o := -I.
> > CFLAG
(Applies to kvm.git/master:c27b64a0)
This is v7 of the series. For more details, please see the header to
patch 2/2.
This series has been tested against the kvm-eventfd unit test, and
appears to be functioning properly. You can download this test here:
ftp://ftp.novell.com/dev/ghaskins/kvm-eve
Today kvm_io_bus_regsiter_dev() returns void and will internally BUG_ON if it
fails. We want to create dynamic MMIO/PIO entries driven from userspace later
in the series, so we need to enhance the code to be more robust with the
following changes:
1) Add a return value to the registration func
iosignalfd is a mechanism to register PIO/MMIO regions to trigger an eventfd
signal when written to by a guest. Host userspace can register any arbitrary
IO address with a corresponding eventfd and then pass the eventfd to a
specific end-point of interest for handling.
Normal IO requires a blocki
On 06/15/2009 04:21 PM, Alexander Graf wrote:
Now that we have nested SVM in place, let's make use of it and virtualize
something non-kvm.
The first interesting target that came to my mind here was Hyper-V.
This patchset makes Windows Server 2008 boot with Hyper-V, which runs
the "dom0" in virtu
On 06/15/2009 02:30 PM, Alexander Graf wrote:
X86 CPUs need to have some magic happening to enable the virtualization
extensions on them. This magic can result in unpleasant results for
users, like blocking other VMMs from working (vmx) or using invalid TLB
entries (svm).
Currently KVM activates
On 06/15/2009 03:17 PM, Christoph Hellwig wrote:
On Mon, Jun 15, 2009 at 01:30:05PM +0200, Alexander Graf wrote:
X86 CPUs need to have some magic happening to enable the virtualization
extensions on them. This magic can result in unpleasant results for
users, like blocking other VMMs from wo
On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
> irqfd and its underlying implementation, eventfd, currently utilize
> the embedded wait-queue in eventfd for signal notification. The nice thing
> about this design decision is that it re-uses the existing
> eventfd/wait-queue code
Avi Kivity wrote:
> On 06/15/2009 02:30 PM, Alexander Graf wrote:
>> X86 CPUs need to have some magic happening to enable the virtualization
>> extensions on them. This magic can result in unpleasant results for
>> users, like blocking other VMMs from working (vmx) or using invalid TLB
>> entries (
Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>
>> irqfd and its underlying implementation, eventfd, currently utilize
>> the embedded wait-queue in eventfd for signal notification. The nice thing
>> about this design decision is that it re-uses th
Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>
>> irqfd and its underlying implementation, eventfd, currently utilize
>> the embedded wait-queue in eventfd for signal notification. The nice thing
>> about this design decision is that it re-uses th
[Adding Ingo]
Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
>
>> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>>
>>
>>> irqfd and its underlying implementation, eventfd, currently utilize
>>> the embedded wait-queue in eventfd for signal notification. The nice
Felix Leimbach wrote:
It's exactly the same CPU I have.
Interesting: Since two months I'm running on 2 Shanghai Quad-Cores
instead and the problem is definitely gone.
The rest of the hardware as well as the whole software-stack remained
unchanged.
That should confirm what we assumed already.
On x86 mp_state is initialized by kvm_arch_vcpu_init. Right
now kvm_vcpu_is_bsp returns false because kvm->bsp_vcpu has
not been initialized, so vcpu_id == 0 ends up with mp_state ==
KVM_MP_STATE_UNINITIALIZED.
Gleb do you see a better way to fix this?
Signed-off-by: Marcelo Tosatti
diff --g
On Tue, Jun 16, 2009 at 10:11:08AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
> >
> >> irqfd and its underlying implementation, eventfd, currently utilize
> >> the embedded wait-queue in eventfd for signal notifi
Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>
>> irqfd and its underlying implementation, eventfd, currently utilize
>> the embedded wait-queue in eventfd for signal notification. The nice thing
>> about this design decision is that it re-uses th
On Tue, Jun 16, 2009 at 10:40:55AM -0400, Gregory Haskins wrote:
> > This is ugly, isn't it? With CONFIG_PREEMPT=no preemptible() is always
> > false.
> >
> > Further, to do useful things it might not be enough that you can sleep:
> > with iofd you also want to access current task with e.g. copy f
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 10:11:08AM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>>>
>>>
irqfd and its underlying implementation, eventfd, currently utilize
Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
>
>> On Tue, Jun 16, 2009 at 10:11:08AM -0400, Gregory Haskins wrote:
>>
>>
>>> Michael S. Tsirkin wrote:
>>>
>>>
On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
> i
On Tue, 2009-06-16 at 09:34 -0400, Glauber Costa wrote:
> handle_powerpc_dcr_read() and handle_powerpc_dcr_write() are two
> powerpc specific functions that are called via libkvm callbacks.
> However, grepping the source code finds simply no use of them. This
> is probably due to the fact that powe
On Tue, Jun 16, 2009 at 10:48:27AM -0400, Gregory Haskins wrote:
> +static void _eventfd_notify(struct eventfd_ctx *ctx)
> +{
> +struct eventfd_notifier *en;
> +int idx;
> +
> +idx = srcu_read_lock(&ctx->srcu);
> +
> +/*
>
On 06/15/2009 10:45 PM, Michael Goldish wrote:
Currently parameters for barrier_2() are extracted from 'params' in the main
run_steps() test routine, and then passed to barrier_2().
Instead, let barrier_2() extract parameters from 'params' as it sees fit.
This will make adding new parameters slig
On 06/16/2009 05:08 PM, Alexander Graf wrote:
Please tell me you tested suspend/resume with/without VMs and cpu
hotunplug/hotplug.
I tested cpu hotplugging. On the last round I tested suspend/resume, but
this time I couldn't because my machine can't do suspend :-(.
So I'll try hard and fi
On Tue, Jun 16, 2009 at 10:54:28AM -0400, Gregory Haskins wrote:
> > +static void _eventfd_notify(struct eventfd_ctx *ctx)
> > +{
> > + struct eventfd_notifier *en;
> > + int idx;
> > +
> > + idx = srcu_read_lock(&ctx->srcu);
> > +
> > + /*
>
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 10:48:27AM -0400, Gregory Haskins wrote:
>
>> +static void _eventfd_notify(struct eventfd_ctx *ctx)
>> +{
>> +struct eventfd_notifier *en;
>> +int idx;
>> +
>> +idx = srcu_read_lock(&ctx->srcu);
>
On Tue, Jun 16, 2009 at 11:20:18AM -0400, Gregory Haskins wrote:
> >>> eventfd can't detect this state. But the callers know in what context
> >>> they are.
> >>> So the *caller* of eventfd_signal_task makes sure of this: if you are in
> >>> a task,
> >>> you can call eventfd_signal_task() if not
- "Uri Lublin" wrote:
> On 06/15/2009 10:45 PM, Michael Goldish wrote:
> > Currently parameters for barrier_2() are extracted from 'params' in
> the main
> > run_steps() test routine, and then passed to barrier_2().
> > Instead, let barrier_2() extract parameters from 'params' as it sees
> f
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 11:20:18AM -0400, Gregory Haskins wrote:
>
> eventfd can't detect this state. But the callers know in what context
> they are.
> So the *caller* of eventfd_signal_task makes sure of this: if you are in
> a task,
> you can
On Tue, 16 Jun 2009, Gregory Haskins wrote:
> Does this all make sense?
This conversation has been *really* long, and I haven't had time to look
at the patch yet. But looking at the amount of changes, and the amount of
even more changes talked in this thread, there's a very slim chance that
I'
I'm working on make PCI slots configurable in QEMU. While testing the
feature for virtio-blk-pci, I ran into a task hang with Fedora kernel
2.6.27.5-117.fc10. Marcelo tested it with a newer kernel, and will
follow up with details.
Instead of the full QEMU patch I'm working on, the appended littl
Davide Libenzi wrote:
> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>
>
>> Does this all make sense?
>>
>
> This conversation has been *really* long, and I haven't had time to look
> at the patch yet. But looking at the amount of changes, and the amount of
> even more changes talked in th
On Tue, Jun 16, 2009 at 06:47:45PM +0200, Markus Armbruster wrote:
> I'm working on make PCI slots configurable in QEMU. While testing the
> feature for virtio-blk-pci, I ran into a task hang with Fedora kernel
> 2.6.27.5-117.fc10. Marcelo tested it with a newer kernel, and will
> follow up with
On Tue, Jun 16, 2009 at 12:17:22PM -0400, Gregory Haskins wrote:
> > Maybe I misunderstand what iosignalfd is - isn't it true that you get
> > eventfd
> > and kvm will signal that when guest performs io write to a specific
> > address, and then drivers can get eventfd and poll it to detect
> > the
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 12:17:22PM -0400, Gregory Haskins wrote:
>
>>> Maybe I misunderstand what iosignalfd is - isn't it true that you get
>>> eventfd
>>> and kvm will signal that when guest performs io write to a specific
>>> address, and then drivers can get even
Hi,
Since I installed the latest version of qemu-kvm (0.10.5), the
following 3 lines are flooding my system log (dmesg). I have no idea
where this is coming from.
[433019.047800] arch/x86/kvm/x86.c kvm_write_guest_time
[433019.047802] Write (vcpu->hv_clock.system_time): 433019047801180
[4
Avi Kivity wrote:
> Another issue is enumeration. Guests will present their devices in the
> order they find them on the pci bus (of course enumeration is guest
> specific). So if I have 2 virtio controllers the only way I can
> distinguish between them is using their pci slots.
virtio contro
Mark McLoughlin wrote:
> > After libvirt has done -drive file=foo... it should dump the machine
> > config and use that from then on.
>
> Right - libvirt then wouldn't be able to avoid the complexity of merging
> any future changes into the dumped machine config.
As long as qemu can accept a mac
Mark McLoughlin wrote:
> > Worst case we hardcode those numbers (gasp, faint).
>
> Maybe we can just add the open slots to the -help output. That'd be nice
> and clean.
Make them part of the machine configuration.
After all, they are part of the machine configuration, and ACPI, BIOS
etc. need to
Hello Charles,
> Otherwise -- at the monitor, migrate "exec:cat >somefile.out"
I tried that, saving seems to work OK,
but if I restore the domain, kvm always seems to be stuck, I'm not able to swith
to monitor to do anything. running strace on the kvm process show that
following is repeating:
cl
Michael S. Tsirkin wrote:
Change much of hw/pci to use symbolic constants and a table-driven
design: add a mask table with writable bits set and readonly bits unset.
Detect change by comparing original and new registers.
This makes it easy to support capabilities where read-only/writeable
bit la
Grettings all,
The Linux-iSCSI.org Target v3.0 HOWTO using the new configfs enabled
generic target subsystem python CLI has been released and is up and
running on v2.6.30 of the Linux Kernel in x86_64 KVM (Debian), x86_64
bare-metal (SLES) and PPC64 (Fedora PS3) hosts! The HOWTO entry can be
foun
Adding iperf network performance test. Basically it tests
networking functionality, stability and performance of guest OSes.
This test is cross-platform -- i.e. it works on both Linux and
Windows VMs.
Signed-off-by: Alexey Eromenko
---
client/tests/kvm/kvm.py |1 +
client/tests
On Tue, 2009-06-16 at 18:29 -0300, Lucas Meneghel Rodrigues wrote:
> Adding iperf network performance test. Basically it tests
> networking functionality, stability and performance of guest OSes.
> This test is cross-platform -- i.e. it works on both Linux and
> Windows VMs.
Ok, now that I had reb
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Return EOPNOTSUPP for KVM_TRACE_ENABLE/PAUSE/DISABLE ioctls.
Signed-off-by: Marcelo Tosatti
Index: kvm/virt/kvm/kvm_main.c
===
--- kvm.orig/virt/kvm/kvm_main.c
+++ kvm/virt/kvm/kvm_main.c
@@ -2367,7 +2367,7 @@ static long kvm_dev_i
This allows use of the powerful ftrace infrastructure.
See Documentation/trace/ for usage information.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/lapic.c
===
--- kvm.orig/arch/x86/kvm/lapic.c
+++ kvm/arch/x86/kvm/lapic.
On Tue, Jun 16, 2009 at 2:22 PM, Simon Marchi wrote:
> Hi,
>
> Since I installed the latest version of qemu-kvm (0.10.5), the
> following 3 lines are flooding my system log (dmesg). I have no idea
> where this is coming from.
>
> [433019.047800] arch/x86/kvm/x86.c kvm_write_guest_time
> [433019.047
On Tue, 2009-06-16 at 18:40 -0300, Lucas Meneghel Rodrigues wrote:
> * Autotest iperf test usually runs with 2 machines, one in 'server'
> role and other in 'client' mode. I would like to pursue the same model,
> 2 vms, one running as a server and another as a client.
Nevermind this comment, I've
Make the current migration test handle remote migration. In order to
use remote migration, the following four parameters should be added
to the existing migration test:
remote = dst
hostip =
remoteip =
remuser = root
rempassword =
The field remote=dst indicat
On Tue, 2009-06-16 at 21:46 -0300, Lucas Meneghel Rodrigues wrote:
> Make the current migration test handle remote migration. In order to
> use remote migration, the following four parameters should be added
> to the existing migration test:
I went trough the discussion about this patch and I also
Hello Michael:
The shutdown case is useful but the patch does really similar work to
vm.destroy(). Maybe we could simple let the preprocess progress to
shutdown all the vms just like:
- shutdown: install setup
vms = ''
Michael Goldish 写道:
> The shutdown test logs into a VM and s
Hi Andre,
On (Tue) Jun 16 2009 [15:25:13], Andre Przywara wrote:
> sysenter/sysexit are not supported on AMD's 32bit compat mode, whereas
> syscall is not supported on Intel's 32bit compat mode. To allow cross
> vendor migration we emulate the missing instructions by setting up the
> processor sta
All the patches on the first patch queue e-mail were examined and worked
out. This is a report of the patches that weren't applied yet. Some of
them might not make it into the kvm test, but all of them got follow
ups. Here's the latest report of the patches available:
Patch queue:
---
- "jason wang" wrote:
> Hello Michael:
>
> The shutdown case is useful but the patch does really similar work to
> vm.destroy(). Maybe we could simple let the preprocess progress to
> shutdown all the vms just like:
>
> - shutdown: install setup
> vms = ''
That will shut
On 06/16/2009 09:32 PM, Jamie Lokier wrote:
Avi Kivity wrote:
Another issue is enumeration. Guests will present their devices in the
order they find them on the pci bus (of course enumeration is guest
specific). So if I have 2 virtio controllers the only way I can
distinguish between them
80 matches
Mail list logo
