Am 16.01.2015 um 00:09 schrieb Michael Ellerman:
On Thu, 2015-01-15 at 09:58 +0100, Christian Borntraeger wrote:
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates)
On 15.01.15 09:58, Christian Borntraeger wrote:
Folks,
fyi, this is my current patch queue for the next merge window. It
does contain a patch that will disallow ACCESS_ONCE on non-scalar
types.
The tree is part of linux-next and can be found at
Hello, please see the answer below blue:
From: Radim Krčmář rkrc...@redhat.com
To: Li Kaihang li.kaih...@zte.com.cn,
Cc: g...@kernel.org, pbonz...@redhat.com, t...@linutronix.de,
mi...@redhat.com, h...@zytor.com, x...@kernel.org, kvm@vger.kernel.org,
linux-ker...@vger.kernel.org
On 01/15/2015 02:47 PM, Eric Auger wrote:
On arm/arm64 the VGIC is dynamically instantiated and it is useful
to expose its state, especially for irqfd setup.
This patch defines __KVM_HAVE_ARCH_INTC_INITIALIZED and
implements kvm_arch_intc_initialized.
Signed-off-by: Eric Auger
Hi Eric,
On 01/15/2015 02:47 PM, Eric Auger wrote:
Introduce __KVM_HAVE_ARCH_INTC_INITIALIZED define and
associated kvm_arch_intc_initialized function. This latter
allows to test whether the virtual interrupt controller is initialized
and ready to accept virtual IRQ injection. On some
On 01/15/2015 02:47 PM, Eric Auger wrote:
CONFIG_HAVE_KVM_IRQCHIP is needed to support IRQ routing (along
with irq_comm.c and irqchip.c usage). This is not the case for
arm/arm64 currently.
This patch unsets the flag for both arm and arm64.
Signed-off-by: Eric Auger eric.au...@linaro.org
Am 16.01.2015 um 00:09 schrieb Michael Ellerman:
On Thu, 2015-01-15 at 09:58 +0100, Christian Borntraeger wrote:
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates)
Hi Eric,
On 01/15/2015 02:47 PM, Eric Auger wrote:
This patch enables irqfd on arm/arm64.
Both irqfd and resamplefd are supported. Injection is implemented
in vgic.c without routing.
This patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD.
KVM_CAP_IRQFD is now advertised.
On Fri, Jan 16, 2015 at 12:14:17PM +0800, Yidao Liu wrote:
Hi, I want to use a dedicated guest VM to handle I/O request just as
I/O service domain used in xen.
Specifically, using network I/O as an example, I should directly
assign the NIC to one guest VM (using pci-assign option), after
From: Suzuki K. Poulose suzuki.poul...@arm.com
If an open at the 9p server(host) fails with EMFILE (Too many open files for
the process), we should return ENFILE(too many open files in the system) to
the guest to indicate the actual status within the guest.
This was uncovered during LTP, where
On 15.01.15 09:58, Christian Borntraeger wrote:
Folks,
fyi, this is my current patch queue for the next merge window. It
does contain a patch that will disallow ACCESS_ONCE on non-scalar
types.
The tree is part of linux-next and can be found at
2015-01-16 19:00 GMT+08:00 Stefan Hajnoczi stefa...@gmail.com:
On Fri, Jan 16, 2015 at 12:14:17PM +0800, Yidao Liu wrote:
Hi, I want to use a dedicated guest VM to handle I/O request just as
I/O service domain used in xen.
Specifically, using network I/O as an example, I should directly
On Fri, Jan 16, 2015 at 11:30:10AM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
If an open at the 9p server(host) fails with EMFILE (Too many open files for
the process), we should return ENFILE(too many open files in the system) to
the guest to indicate the
On Fri, 16 Jan 2015 11:48:46 -0500
Steven Rostedt rost...@goodmis.org wrote:
static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc)
{
- DEFINE_WAIT(wait);
+ DEFINE_SWAITER(wait);
- prepare_to_wait(vc-wq, wait, TASK_INTERRUPTIBLE);
+ swait_prepare(vc-wq, wait,
On Fri, 16 Jan 2015 11:40:45 -0500
Marcelo Tosatti mtosa...@redhat.com wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context
2015-01-16 16:07+0800, Li Kaihang:
GuestOS is running and handling some interrupt with RFLAGS.IF = 0 while a
external interrupt coming,
then can lead to a vm exit,in this case,we must avoid inject this external
interrupt or it will generate
a processor hardware exception causing
Linus, I suspect you'll either like or hate this series. Or maybe
you'll think it's crazy but you'll like it anyway. I'm curious
which of those is the case. :)
The syscall exit asm is a big mess. There's a really fast path, some
kind of fast path code (with a hard-coded optimization for
The int_ret_from_sys_call and syscall tracing code disagrees with
the sysret path as to the value of RCX.
The Intel SDM, the AMD APM, and my laptop all agree that sysret
returns with RCX == RIP. The syscall tracing code does not respect
this property.
For example, this program:
int main()
{
The x86_64 entry code currently jumps through complex and
inconsistent hoops to try to minimize the impact of syscall exit
work. For a true fast-path syscall, almost nothing needs to be
done, so returning is just a check for exit work and sysret. For a
full slow-path return from a syscall, the C
We used to optimize rescheduling and audit on syscall exit. Now
that the full slow path is reasonably fast, remove these
optimizations. Syscall exit auditing is now handled exclusively by
syscall_trace_leave.
This adds something like 10ns to the previously optimized paths on
my computer,
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
I notice everywhere you have a swait_wake_interruptible() but here. Is
there a reason why?
IIRC, Peter wants to make swait wakeup usage homogenous. That is, you
either sleep in an interruptible state, or you don't. You can't mix
21 matches
Mail list logo
