Hi MST & Paolo,
So I'm currently working on vhost-scsi support for ANY_LAYOUT, and
wanted to verify some assumptions based upon your earlier emails..
*) When ANY_LAYOUT is negotiated by vhost-scsi, it's expected that
virtio-scsi request + response headers will (always..?) be within a
single iovec
We switch to unlock variant with memory barriers in the error path
and also in code path where we had implicit dependency on previous
functions calling lwsync/ptesync. In most of the cases we don't really
need an explicit barrier, but using the variant make sure we don't make
mistakes later with co
This patch adds helper routine for lock and unlock hpte and use
the same for rest of the code. We don't change any locking rules in this
patch. In the next patch we switch some of the unlock usage to use
the api with barrier and also document the usage without barriers.
Signed-off-by: Aneesh Kumar
On Fri, 01/23 17:21, Stefan Hajnoczi wrote:
> Dear libvirt, KVM, and QEMU contributors,
> The Google Summer of Code season begins soon and it's time to collect
> our thoughts for mentoring students this summer working full-time on
> libvirt, KVM, and QEMU.
>
> What is GSoC?
> Google Summer of Code
From: "Luis R. Rodriguez"
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT preemption won't happen, without preemption
a system can become pretty us
From: "Luis R. Rodriguez"
This v5 nukes tracing as David said it was useless, it also
only adds support for 64-bit as its the only thing I can test,
and slightly modifies the documentation in code as to why we
want this. The no krobe thing is left in place as I haven't
heard confirmation its kosh
From: "Luis R. Rodriguez"
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in kernel
context (multicalls). Such operations can trigger soft lockup
detection.
We want to address a way
On Thu, Jan 22, 2015 at 05:40:45PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 22, 2015 at 4:29 PM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > On kernels with voluntary or no preemption we can run
> > into situations where a hypercall issued through userspace
> > will linger
On Wed, Jan 21, 2015 at 06:39:46PM +, Marc Zyngier wrote:
> Trying to emulate the behaviour of set/way cache ops is fairly
> pointless, as there are too many ways we can end-up missing stuff.
> Also, there is some system caches out there that simply ignore
> set/way operations.
>
> So instead
On Wed, Jan 21, 2015 at 06:39:45PM +, Marc Zyngier wrote:
> This small series fixes a number of issues that Christoffer and I have
> been trying to nail down for a while, having to do with the host dying
> under load (swapping), and also with the way we deal with caches in
> general (and with s
On Mon, 2015-01-26 at 16:46 +0800, Xuekun Hu wrote:
> Hi, All
>
> Is there a limit for number of PCI pass-through devices in KVM? For
> Legacy PCI device assignement or VFIO pass-through method?
There's no enforced limit, but the usable limit is related to the number
of KVM memory slots available
From: Gonglei
In order to support to assign a boot order for
vhost-scsi device, we should get the tpgt for
user level (such as Qemu). and at present, we
only support the minimum tpgt can boot.
Signed-off-by: Gonglei
Signed-off-by: Bo Su
---
drivers/vhost/scsi.c | 41
On 2015-01-26 19:29:03, Paolo Bonzini wrote:
>
> On 26/01/2015 12:13, Zhang Haoyu wrote:
> > Thanks, Paolo,
> > but too many internal snapshots were saved by customers,
>> switching to external snapshot mechanism has significant impaction
> > on subsequent upgrade.
>
> In that case, patches are w
On 26/01/15 11:26, Will Deacon wrote:
> On Fri, Jan 23, 2015 at 04:35:02PM +, Andre Przywara wrote:
>> From: Marc Zyngier
>>
>> As of 3.14, KVM/arm supports the creation/configuration of the GIC through
>> a more generic device API, which is now the preferred way to do so.
>>
>> Plumb the new
On 26/01/15 11:43, Andre Przywara wrote:
> Hi Will,
>
> On 26/01/15 11:30, Will Deacon wrote:
>> On Fri, Jan 23, 2015 at 04:35:10PM +, Andre Przywara wrote:
>>> Add the command line parameter "--gicv3" to request GICv3 emulation
>>> in the kernel. Connect that to the already existing GICv3 cod
Hi Will,
On 26/01/15 11:30, Will Deacon wrote:
> On Fri, Jan 23, 2015 at 04:35:10PM +, Andre Przywara wrote:
>> Add the command line parameter "--gicv3" to request GICv3 emulation
>> in the kernel. Connect that to the already existing GICv3 code.
>>
>> Signed-off-by: Andre Przywara
>> ---
>>
On Fri, Jan 23, 2015 at 04:35:10PM +, Andre Przywara wrote:
> Add the command line parameter "--gicv3" to request GICv3 emulation
> in the kernel. Connect that to the already existing GICv3 code.
>
> Signed-off-by: Andre Przywara
> ---
> tools/kvm/arm/aarch64/arm-cpu.c|
On 26/01/2015 12:13, Zhang Haoyu wrote:
> Thanks, Paolo,
> but too many internal snapshots were saved by customers,
> switching to external snapshot mechanism has significant impaction
> on subsequent upgrade.
In that case, patches are welcome. :)
> Another problem:
> drive_backup just implemen
On Fri, Jan 23, 2015 at 04:35:02PM +, Andre Przywara wrote:
> From: Marc Zyngier
>
> As of 3.14, KVM/arm supports the creation/configuration of the GIC through
> a more generic device API, which is now the preferred way to do so.
>
> Plumb the new API in, and allow the old code to be used as
On 26/01/2015 08:32, Nadav Amit wrote:
> Sorry for sending patches at the last minute. There is nothing critical in
> this
> patch-set. Yet, if you may want to incorporate something in 3.20 -
> specifically 5 (small define mistakes) or 7 (which is somewhat affected by
> recent changes).
>
> Th
On 2015-01-26 17:29:43, Paolo Bonzini wrote:
>
> On 26/01/2015 02:07, Zhang Haoyu wrote:
> > Hi, Kashyap
> > I've tried ‘drive_backup’ via QMP,
>> but the snapshots were missed to backup to destination,
> > I think the reason is that backup_run() only copy the
> > guest data regarding qcow2 image.
On 23/01/15 18:58, Luis R. Rodriguez wrote:
>
> Its not just hypercalls though, this is all about the interactions
> with multicalls no?
No. This applies to any preemptible hypercall and the toolstack doesn't
use multicalls for most of its work.
David
--
To unsubscribe from this list: send the
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + * CONFIG_PREEMP
On Thu, Jan 22, 2015 at 03:29:10PM +0200, Elazar Leibovich wrote:
> When perf runs on a regular linux, it can collect the current
> stacktraces (kernel or user) for each sample. This is a very important
> feature, and is utilized by some visualization tools (see, e.g.,
> Brendan's post[0]).
>
> As
On 26/01/2015 02:07, Zhang Haoyu wrote:
> Hi, Kashyap
> I've tried ‘drive_backup’ via QMP,
> but the snapshots were missed to backup to destination,
> I think the reason is that backup_run() only copy the
> guest data regarding qcow2 image.
Yes, that's the case.
QEMU cannot still access interna
Hi, All
Is there a limit for number of PCI pass-through devices in KVM? For
Legacy PCI device assignement or VFIO pass-through method?
Many thanks.
Thx, Xuekun
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo in
26 matches
Mail list logo
