Hi,
On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
>On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
>
> Hi,
> On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
>
>On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
>
>
On Mon, Jan 20, 2020 at 09:36:27AM +0100, Jan Beulich wrote:
> On 19.01.2020 11:39, Pasi Kärkkäinen wrote:
> > On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
> >> On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote:
> >>> I have a multi-function P
Hi,
On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
> On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote:
> > I have a multi-function PCI device, behind a PCI bridge, that normally
> > I assign to a single domain. But now it fails with:
> >
> > (XEN) [VT-D]d14: :04:00.0
On Thu, Jan 02, 2020 at 06:04:33PM +, Ian Jackson wrote:
> This affects only x86 and only the branches that aren't linux-*, since
> obviously the latter use whatever version they are using.
>
> I compared the most recent linux-4.19 results with the most recent
> linux-4.14 ones, and there was
Hello Stanislav,
On Fri, Sep 13, 2019 at 11:28:20PM +0800, Chao Gao wrote:
> On Fri, Sep 13, 2019 at 10:02:24AM +, Spassov, Stanislav wrote:
> >On Thu, Dec 13, 2018 at 07:54, Chao Gao wrote:
> >>On Thu, Dec 13, 2018 at 12:54:52AM -0700, Jan Beulich wrote:
> >> On 13.12.18 at 04:46,
Hi Chao,
On Fri, Aug 09, 2019 at 04:38:33PM +0800, Chao Gao wrote:
> Hi everyone,
>
> I have a device which only supports secondary bus reset. After being
> assigned to a VM, it would be placed under host bridge. For devices
> under host bridge, secondary bus reset is not applicable. Thus, a VM
Hi,
On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
> On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
> > On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
> >> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
> >>> On
Hi,
On Fri, Jul 19, 2019 at 02:23:44PM +, Jan Beulich wrote:
> All,
>
> the release is due in early August. Please point out backports you
> find missing from the respective staging branch, but which you
> consider relevant. The one commit I've queued already on top of
> what was just pushed
Hello,
On Wed, Jul 10, 2019 at 07:44:08PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] libxl: fix pci device
> re-assigning after domain reboot"):
> > On Wed, Jun 26, 2019 at 03:37:26PM +0200, Juergen Gross wrote:
> > > Signed-off-by: Juergen Gross
> > >
On Sat, Apr 20, 2019 at 07:27:55PM -0400, Daniel P. Smith wrote:
> On 4/18/19 9:11 AM, George Dunlap wrote:
> > On 4/18/19 2:52 AM, Daniel P. Smith wrote:
> >> This deals with two casting issues for compiling under go 1.11:
> >> - explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
> >>
On Wed, Mar 20, 2019 at 08:22:03PM +, Igor Druzhinin wrote:
> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
> before calling acpi_parse_dmar()") PCI segment 0 is now known early
> which made the sanity check on DRHD definition structure to work.
> This, in turn, caused a
Hello,
On Tue, Feb 05, 2019 at 11:44:09AM +, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] preparations for 4.10.3 and 4.9.4"):
> > On 01.02.19 at 12:23, wrote:
> > > For 4.10.3:
> > >
> > > https://lists.xen.org/archives/html/xen-devel/2019-01/msg01451.html
> >
> > Ian, this
On Thu, Nov 08, 2018 at 07:29:17PM +0200, Pasi Kärkkäinen wrote:
> Hello Ian,
>
> On Tue, Oct 09, 2018 at 03:04:52AM -0600, Jan Beulich wrote:
> > >>> On 09.10.18 at 10:38, wrote:
> > > On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
> > >&
Hello Ian,
On Tue, Oct 09, 2018 at 03:04:52AM -0600, Jan Beulich wrote:
> >>> On 09.10.18 at 10:38, wrote:
> > On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
> >> All,
> >>
> >> both releases are due in about a month's time. Please point out
> >> backports you find missing from
Hello Ian,
On Mon, Oct 29, 2018 at 08:55:09PM +, Paraschiv, Andra-Irina wrote:
>
>
> On Mon, Oct 29, 2018 at 04:58:22PM +0200, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> > > Andra Paras
On Mon, Oct 29, 2018 at 08:55:09PM +, Paraschiv, Andra-Irina wrote:
>
>
> On Mon, Oct 29, 2018 at 04:58:22PM +0200, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> > > Andra Paraschiv writes ("[
Hi,
On Tue, Oct 23, 2018 at 08:40:29PM +0200, Håkon Alstadheim wrote:
>
>
> Den 08. okt. 2018 16:32, skrev Boris Ostrovsky:
> >
> > Are these two patches still needed? ISTR they were written originally
> > to deal with guest trying to use device that was previously assigned to
> > another
Hi,
On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> Andra Paraschiv writes ("[PATCH RESEND qemu-xen-traditional] xen/pt: allow
> QEMU to request MSI unmasking at bind time"):
> > When a MSI interrupt is bound to a guest using
> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq)
On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
> All,
>
> both releases are due in about a month's time. Please point out
> backports you find missing from their respective staging branches,
> but which you consider relevant. On top of what I've just pushed
> there I have
>
>
On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
> > On 9/18/18 5:32 AM, George Dunlap wrote:
> > >
> > >> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
> > >>
>
Hi,
On Thu, Sep 20, 2018 at 12:40:25PM +0200, Roger Pau Monne wrote:
> Fill the from_xenstore libxl_device_type hook for PCI devices so that
> libxl_retrieve_domain_configuration can properly retrieve PCI devices
> from xenstore.
>
> This fixes disappearing pci devices across domain reboots.
>
Hi,
On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
> On 9/16/18 7:43 AM, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
> >> On 12/18/2017 02:36 AM, Jan Beulich wrote:
> &g
Hi,
On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
> On 12/18/2017 02:36 AM, Jan Beulich wrote:
> On 15.12.17 at 20:52, wrote:
> > +static int pcistub_device_reset(struct pci_dev *dev)
> > +{
> > + struct xen_pcibk_dev_data *dev_data;
> > + bool
Hi,
On Sun, Sep 09, 2018 at 10:33:02PM -0400, Sinan Kaya wrote:
> On 9/9/2018 2:59 PM, Pasi Kärkkäinen wrote:
> >I noticed pcie_has_flr() has been recently exported in upstream Linux:
> >https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
On Mon, Dec 18, 2017 at 04:26:30AM -0800, Christoph Hellwig wrote:
> On Fri, Dec 15, 2017 at 12:18:02PM -0600, Bjorn Helgaas wrote:
> > I think Christoph volunteered to do some restructuring, but I don't
> > know his timeframe. If you can, I would probably wait for that
> > because there's so
On Wed, Nov 29, 2017 at 11:25:09AM -0600, Govinda Tatti wrote:
>
> >>>Furthermore, contrary to what you claim in
> >>>your reply to Pasi, I can't see where you try an actual FLR first -
> >>>you go straight to pci_probe_reset_{slot,bus}(). If you actually
> >>>tried FLR first, only falling back
26 matches
Mail list logo
