On 12/17/2010 4:29 PM, Erik Brakkee wrote:
Hi,
For a backup of data from a VM to a USB mounted disk I want to
circumvent the USB 1.1 limitations on the guest and instead copy the
data over to the host using scp/ssh. I have setup a network using
virtio and NAT like this:
function='0x0
Hi,
For a backup of data from a VM to a USB mounted disk I want to
circumvent the USB 1.1 limitations on the guest and instead copy the
data over to the host using scp/ssh. I have setup a network using virtio
and NAT like this:
When I now create a 1GB file using dd and copy it over
On Fri, 2010-12-17 at 17:09 +0200, Avi Kivity wrote:
> On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> > > Surely that makes it a reasonable idea to call yield, and
> > > get one of the other tasks on the current CPU running for
> > > a bit?
> >
> > There's nothing wrong with trying to give up t
On Fri, 17 Dec 2010 17:32:37 +1100 Stephen Rothwell wrote:
> Hi all,
>
> [The mirroring on kernel.org is running slowly]
>
> Changes since 20101216:
on i386 builds, I'm seeing this build error:
arch/x86/kvm/vmx.c:488: Error:bad register name `%sil'
but I don't see what is causing it...
ker
On 12/15/2010 10:16 AM, Julien Desfossez wrote:
Hi,
I'm currently working with the kvm clocksource and I'm wondering if we
could implement the vread function for this clock source when we are
running on a host with constant_tsc.
If I understand correctly the hv_clock structure is per_cpu becau
From: Eduardo Habkost
We want to follow inheritance when getting the latest build, like 'brew
latest-pkg' does.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/kvm_utils.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm_utils.py b/client/test
On Fri, 17 Dec 2010, Jan Kiszka wrote:
> Am 17.12.2010 16:25, Thomas Gleixner wrote:
> > Your aproach with disable_irq_nosync() is completely flawed, simply
> > because you try to pretend that your interrupt handler is done, while
> > it is not done at all. The threaded interrupt handler is done wh
2010/12/17 Yoshiaki Tamura :
> 2010/12/16 Michael S. Tsirkin :
>> On Thu, Dec 16, 2010 at 11:28:46PM +0900, Yoshiaki Tamura wrote:
>>> 2010/12/16 Michael S. Tsirkin :
>>> > On Thu, Dec 16, 2010 at 04:36:16PM +0900, Yoshiaki Tamura wrote:
>>> >> 2010/12/3 Yoshiaki Tamura :
>>> >> > 2010/12/2 Michael
2010/12/17 Stefan Hajnoczi :
> On Thu, Dec 16, 2010 at 9:50 AM, Yoshiaki Tamura
> wrote:
>> 2010/12/16 Michael S. Tsirkin :
>>> On Thu, Dec 16, 2010 at 04:37:41PM +0900, Yoshiaki Tamura wrote:
2010/11/28 Yoshiaki Tamura :
> 2010/11/28 Michael S. Tsirkin :
>> On Thu, Nov 25, 2010 at
Am 17.12.2010 16:25, Thomas Gleixner wrote:
> On Fri, 17 Dec 2010, Jan Kiszka wrote:
>
>> Am 17.12.2010 11:41, Thomas Gleixner wrote:
>>> On Fri, 17 Dec 2010, Jan Kiszka wrote:
Am 17.12.2010 11:23, Thomas Gleixner wrote:
> OTOH, if we have to disable anyway, then we could simply keep it
>
On Fri, 17 Dec 2010, Jan Kiszka wrote:
> Am 17.12.2010 11:41, Thomas Gleixner wrote:
> > On Fri, 17 Dec 2010, Jan Kiszka wrote:
> >> Am 17.12.2010 11:23, Thomas Gleixner wrote:
> >>> OTOH, if we have to disable anyway, then we could simply keep it
> >>> disabled across the installation of a new ha
On 12/17/2010 01:22 PM, Luiz Capitulino wrote:
>
> I think Avi's suggest is better, and I will use
> "inject-nmi" (without cpu-index argument) to send NMI to all cpus,
> like physical GUI. If some one want to send NMI to a set of cpus,
> he can use "inject-nmi" multiple times.
His suggestion
On 12/17/2010 12:14 AM, Lok Kwong Yan wrote:
Thanks for the reply and it makes a lot of sense.
I am not seeing any EPT tables being zapped after the guest has fully started
up although the value of EPTP continuously changes as the guest is running.
Really strange, this is likely a bug.
--
I
Linus, please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.37
to get a few KVM fixes for 2.6.37-rc6. Two of the fixes are for forward
compatibility with Bulldozer processors, one is a live migration fix,
and one an ordinary preemption counter leak fix.
Andre Prz
On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> Surely that makes it a reasonable idea to call yield, and
> get one of the other tasks on the current CPU running for
> a bit?
There's nothing wrong with trying to give up the cpu. It's the concept
of a cross cpu yield_to() that I find mighty s
Am 15.12.2010 um 00:02 schrieb Alexander Graf:
On 14.12.2010, at 21:31, Benjamin Herrenschmidt wrote:
The only working system emulation we have are Macs (G3 beige, G4,
G5),
so we can't just ignore Apple.
Alex even made me stick to their odd 0x41 rtas-version property. ;)
Hah :-) Nothing
On Fri, 17 Dec 2010 14:20:15 +0800
Lai Jiangshan wrote:
> On 12/16/2010 09:17 PM, Luiz Capitulino wrote:
> > On Thu, 16 Dec 2010 15:11:50 +0200
> > Avi Kivity wrote:
> >>
> >> Why have an argument at all? Always nmi to all cpus.
> >
>
> I think Avi's suggest is better, and I will use
> "injec
Am 17.12.2010 11:41, Thomas Gleixner wrote:
> On Fri, 17 Dec 2010, Jan Kiszka wrote:
>> Am 17.12.2010 11:23, Thomas Gleixner wrote:
>>> OTOH, if we have to disable anyway, then we could simply keep it
>>> disabled across the installation of a new handler. That would make the
>>> notification busine
On Fri, 17 Dec 2010, Jan Kiszka wrote:
> Am 17.12.2010 11:23, Thomas Gleixner wrote:
> > OTOH, if we have to disable anyway, then we could simply keep it
> > disabled across the installation of a new handler. That would make the
> > notification business go away, wouldn't it ?
>
> No, the notifica
Am 17.12.2010 11:23, Thomas Gleixner wrote:
> On Fri, 17 Dec 2010, Jan Kiszka wrote:
>> Am 16.12.2010 21:26, Jan Kiszka wrote:
>>> Am 16.12.2010 14:13, Thomas Gleixner wrote:
On Mon, 13 Dec 2010, Jan Kiszka wrote:
> + if (old_action && (old_action->flags & IRQF_ADAPTIVE) &&
> + !(d
On Fri, 17 Dec 2010, Jan Kiszka wrote:
> Am 16.12.2010 21:26, Jan Kiszka wrote:
> > Am 16.12.2010 14:13, Thomas Gleixner wrote:
> >> On Mon, 13 Dec 2010, Jan Kiszka wrote:
> >>> + if (old_action && (old_action->flags & IRQF_ADAPTIVE) &&
> >>> + !(desc->irq_data.drv_status & IRQS_SHARED)) {
> >>
Am 16.12.2010 21:26, Jan Kiszka wrote:
> Am 16.12.2010 14:13, Thomas Gleixner wrote:
>> On Mon, 13 Dec 2010, Jan Kiszka wrote:
>>> + if (old_action && (old_action->flags & IRQF_ADAPTIVE) &&
>>> + !(desc->irq_data.drv_status & IRQS_SHARED)) {
>>> + /*
>>> +* Signal the
22 matches
Mail list logo
