All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gordan Bobic <gordan@bobich.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Steven Haigh <netwiz@crc.id.au>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andreas Falck <falck.andreas.lists@gmail.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH] fix XSA-46 regression with xend/xm
Date: Wed, 22 May 2013 21:51:07 +0100	[thread overview]
Message-ID: <519D2FBB.7000309@bobich.net> (raw)
In-Reply-To: <1369126587.21246.32.camel@zakaz.uk.xensource.com>

On 05/21/2013 09:56 AM, Ian Campbell wrote:
> On Tue, 2013-05-21 at 09:40 +0100, Jan Beulich wrote:
>> The hypervisor side changes for XSA-46 require the tool stack to now
>> always map the guest pIRQ before granting access permission to the
>> underlying host IRQ (GSI). This in particular requires that pciif.py
>> no longer can skip this step (assuming qemu would do it) for HVM
>> guests.
>>
>> This in turn exposes, however, an inconsistency between xend and qemu:
>> The former wants to always establish 1:1 mappings between pIRQ and host
>> IRQ (for non-MSI only of course), while the latter always wants to
>> allocate an arbitrary mapping. Since the whole tool stack obviously
>> should always agree on the mapping model, make libxc enforce the 1:1
>> mapping as the more natural one (as well as being the one that allows
>> for easier debugging, since there no need to find out the extra
>> mapping). Users of libxc that want to establish a particular (rather
>> than an allocated) mapping are still free to do so, as well as tool
>> stacks not based on libxc wanting to implement an allocation based
>> model (which is why it's not the hypervisor that's being changed to
>> enforce either model).
>>
>> Since libxl, like xend, already uses a 1:1 model, it's unaffected by
>> the libxc change (and it being unaffected by the original hypervisor
>> side changes is - afaict - simply due to qemu getting spawned at a
>> later point in time compared to the xend event flow).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Andreas Falck <falck.andreas.lists@gmail.com> (on 4.1)
>> Tested-by: Gordan Bobic <gordan@bobich.net> (on 4.2)
>
> In both cases tested with xend rather than xl or both?

I can confirm that my VMs start fine with xl with this patch applied.

Gordan

  parent reply	other threads:[~2013-05-22 20:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21  8:40 [PATCH] fix XSA-46 regression with xend/xm Jan Beulich
2013-05-21  8:56 ` Ian Campbell
2013-05-21  8:59   ` Gordan Bobic
2013-05-21  9:01   ` Jan Beulich
2013-05-22 20:51   ` Gordan Bobic [this message]
2013-05-24 11:19     ` George Dunlap
2013-05-24 11:41       ` Gordan Bobic
2013-05-24 12:26         ` George Dunlap
2013-05-21  9:00 ` Andrew Cooper
2013-05-21  9:44 ` George Dunlap
2013-05-21  9:56   ` Jan Beulich
2013-05-21 10:06     ` George Dunlap
2013-05-21 10:17       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519D2FBB.7000309@bobich.net \
    --to=gordan@bobich.net \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=falck.andreas.lists@gmail.com \
    --cc=netwiz@crc.id.au \
    --cc=stefano.stabellini@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.