Hi Christoffer. I've got another comment on the text, this time about the
format of the ESP:
On Wed, 26 Feb 2014 10:34:54 -0800, Christoffer Dall
wrote:
[...]
> Image format
>
> The image format, as presented to the VM, needs to be well-defined in
> order for prepared disk images t
On Thu, 27 Feb 2014 15:00:44 +0100, Arnd Bergmann wrote:
> On Thursday 27 February 2014 12:31:55 Stefano Stabellini wrote:
> > On Wed, 26 Feb 2014, Leif Lindholm wrote:
> > > > > no FDT. In this case, the VM implementation must provide ACPI, and
> > > > > the OS must be able to locate the ACP
On Thu, 27 Feb 2014 08:12:35 -0500, Christopher Covington
wrote:
> Hi Christoffer,
>
> On 02/26/2014 02:51 PM, Christoffer Dall wrote:
> > On Wed, Feb 26, 2014 at 02:27:40PM -0500, Christopher Covington wrote:
>
> >>> Image format
> >>>
> >>> The image format, as presented to the V
On Thu, 27 Feb 2014 12:27:58 +, Stefano Stabellini
wrote:
> On Wed, 26 Feb 2014, Grant Likely wrote:
> > > VM Platform
> > > ---
> > > The specification does not mandate any specific memory map. Â The guest
> > > OS must be able to enumerate all processing elements, devices, and
> > >
On Wed, 26 Feb 2014 14:21:47 -0800, Christoffer Dall
wrote:
> On Wed, Feb 26, 2014 at 03:56:02PM -0600, Rob Herring wrote:
> > On Wed, Feb 26, 2014 at 2:22 PM, Arnd Bergmann wrote:
> > > On Wednesday 26 February 2014 12:05:37 Christoffer Dall wrote:
> > >> On Wed, Feb 26, 2014 at 08:55:58PM +010
On Wed, 26 Feb 2014 14:25:53 -0800, Christoffer Dall
wrote:
> On Wed, Feb 26, 2014 at 09:48:43PM +, Leif Lindholm wrote:
> > On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
> > > > ARM VM System Specification
On 1 March 2014 19:54, Grant Likely wrote:
> Allow me to elaborate. I'm not trying to punish Xen here, but I'm
> deliberately pushing back against "either/or" options in the spec. In
> this case the spec says the VM must implement one of pl011 *or* virtio
> *or* xenpv. That gives lots of implement
On Thu, Feb 27, 2014 at 11:06:17PM -0500, Gabriel L. Somlo wrote:
> Both QEMU and KVM have already accumulated a significant number of
> optimizations based on the hard-coded assumption that ioapic polarity
> will always use the ActiveHigh convention, where the logical and
> physical states of leve
On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
> Hi Christoffer. I've got another comment on the text, this time about the
> format of the ESP:
>
> On Wed, 26 Feb 2014 10:34:54 -0800, Christoffer Dall
> wrote:
> [...]
> > Image format
> >
> > The image format, as pre
Hi, All
I found some discussion about VM live-snapshot, but haven't seen any progress.
https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg02125.html
http://markmail.org/thread/shneezha7kmtosvb#query:+page:1+mid:shneezha7kmtosvb+state:results
Here I have another proposal, based on the live-m
Hello
How
are you? hope fine, I Want to
introduce my self to you before I go
further, My Name is Hassana. I will like to have a good
relationship with you, if you wouldn't mind, I will like to hear from
you soon through this email address because, I
have something very important I will like to tell
According PCI local bus specification, the register of Message
Control for MSI (offset: 2, length: 2) has bit#0 to enable or
disable MSI logic and it shouldn't be part contributing to the
calculation of MSI interrupt count.
The patch fixes above issue. Also, the patch renames local variable
"flags
The macro offsetofend() introduces unnecessary temporary variable
"tmp". The patch avoids that and saves a bit memory in stack.
Signed-off-by: Gavin Shan
---
include/linux/vfio.h |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/vfio.h b/include/linux/vfio
The problem is specific to the case of BIST issued applied to IPR
adapter on the guest side. After BIST reset, we lose everything
in MSIx table and we never have chance update MSIx messages for
those enabled interrupts to MSIx table.
The patch fixes it by writing MSIx message to MSIx table before
On Mon, 2014-03-03 at 11:24 +0800, Gavin Shan wrote:
> The problem is specific to the case of BIST issued applied to IPR
> adapter on the guest side. After BIST reset, we lose everything
> in MSIx table and we never have chance update MSIx messages for
> those enabled interrupts to MSIx table.
>
>
On Mon, 2014-03-03 at 11:24 +0800, Gavin Shan wrote:
> According PCI local bus specification, the register of Message
> Control for MSI (offset: 2, length: 2) has bit#0 to enable or
> disable MSI logic and it shouldn't be part contributing to the
> calculation of MSI interrupt count.
>
> The patch
On 03/03/2014 02:51 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-03 at 11:24 +0800, Gavin Shan wrote:
>> The problem is specific to the case of BIST issued applied to IPR
>> adapter on the guest side. After BIST reset, we lose everything
>> in MSIx table and we never have chance update MSIx
On Mon, 2014-03-03 at 14:51 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-03 at 11:24 +0800, Gavin Shan wrote:
> > The problem is specific to the case of BIST issued applied to IPR
> > adapter on the guest side. After BIST reset, we lose everything
> > in MSIx table and we never have chanc
On Mon, 2014-03-03 at 15:43 +1100, Alexey Kardashevskiy wrote:
> While it works for our particular problem and seems correct, it has one
> flaw - hw/pci/msix.c will not generate this backtrace if masking bit does
> not change which can happen in general:
> ===
> static void msix_handle_mask_update(
On Sun, 2014-03-02 at 21:49 -0700, Alex Williamson wrote:
> I understand from talking to Alexey that the BARs are reset by this
> BIST, but what about the MSIX capability? If that gets reset to be
> disabled, where does it get re-enabled?
The guest will do pci_save/restore_state iirc which will
>From 3a7783cd9a0556787809d3d5ecb5f2b85dd9fc02 Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Mon, 3 Mar 2014 18:56:39 +0800
Subject: [PATCH] target-i386: bugfix of Intel MPX
The correct size of cpuid 0x0d sub-leaf 4 is 0x40, not 0x10.
This is confirmed by Anvin H Peter and Mallick Asit K.
Sig
21 matches
Mail list logo
