Monday, June 1, 2015, 5:43:53 PM, you wrote:
> On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
>>> When doing passthrough of a PCI device for an HVM guest, don't insert
>>> the device into xenstore, otherwise pciback attempts
Thursday, June 11, 2015, 9:47:47 AM, you wrote:
On 10.06.15 at 22:53, wrote:
>> --- a/hw/xen/xen_pt.c
>> +++ b/hw/xen/xen_pt.c
>> @@ -785,7 +785,9 @@ out:
>> xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
>>pci_get_word(d->config + PCI_COMMAND)
Tuesday, June 16, 2015, 4:41:52 PM, you wrote:
> On 06/16/2015 02:37 PM, Ian Jackson wrote:
>> George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
>>> Remember that the path you gave in your previous e-mail isn't the path
>>> for the *usb device*, it's the path for the *
Friday, May 1, 2015, 12:37:54 PM, you wrote:
> On 30/04/15 20:08, Boris Ostrovsky wrote:
>> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
>> attribute issue") makes AMD processors set SS to __KERNEL_DS in
>> __switch_to() to deal with cases when SS is NULL.
>>
>> This b
Hello Sander,
Monday, April 27, 2015, 5:48:00 PM, you wrote:
> Hi David / Konrad,
> Here the other problem i found, which is introduced somewhere in the
> 4.1 mergewindow:
> on 4.1.0-rc1 (with the one revert to get things booting) i get this in
> the PV Guest console:
> [0.517392] crc32c_
Monday, May 11, 2015, 10:59:27 AM, you wrote:
> On Sun, 10 May 2015, big strong wrote:
>> Just as the subject title: does libxl provides python interface? And where
>> can I find the detailed API document of
>> libxl? Thanks in advance
> Please send emails to xen-de...@lists.xenproject.org.
>
Tuesday, May 12, 2015, 5:45:06 PM, you wrote:
> On Tuesday, May 12, 2015 02:59:57 AM Rafael J. Wysocki wrote:
>> On Monday, May 11, 2015 11:20:29 AM Konrad Rzeszutek Wilk wrote:
>> > On Tue, May 05, 2015 at 12:18:49AM +0200, Sander Eikelenboom wrote:
>> > > Hello
Tuesday, May 12, 2015, 5:45:06 PM, you wrote:
> On Tuesday, May 12, 2015 02:59:57 AM Rafael J. Wysocki wrote:
>> On Monday, May 11, 2015 11:20:29 AM Konrad Rzeszutek Wilk wrote:
>> > On Tue, May 05, 2015 at 12:18:49AM +0200, Sander Eikelenboom wrote:
>> > > Hello
Thursday, May 14, 2015, 2:53:17 PM, you wrote:
> On 14/05/2015 14:45, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 14/05/2015 14:02, Markus Armbruster wrote:
It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
commonly don't have an FDC (depends
Sorry for the resend, i messed up the to's en from's.
Hi Konrad / David,
One big snip on this thread, got some more debug info, hopefully this will
lead to something:
On a working kernel (with the two seemingly non related patches reverted) i get:
[0.717796] pcifront pci-0: Allocated pdev
Hello Sander,
Friday, May 15, 2015, 12:47:27 AM, you wrote:
> Sorry for the resend, i messed up the to's en from's.
> Hi Konrad / David,
> One big snip on this thread, got some more debug info, hopefully this will
> lead to something:
> On a working kernel (with the two seemingly non related
Saturday, May 23, 2015, 3:53:37 AM, you wrote:
> On 05/22/2015 04:11 AM, Sander Eikelenboom wrote:
>> Hello Sander,
>>
>> Friday, May 15, 2015, 12:47:27 AM, you wrote:
>>
>>> Sorry for the resend, i messed up the to's en from's.
>>
>>&g
May 22, 2015 09:53:37 PM Boris Ostrovsky wrote:
>> > > > On 05/22/2015 04:11 AM, Sander Eikelenboom wrote:
>> > > > > Hello Sander,
>> > > > >
>> >
>> > [cut]
>> >
>> > > > (+Rafael again)
>> > >
Hi Jan / Andrew,
I'm having some trouble with a xhci controller passed through with
pci-passthrough to one of my HVM guests.
It uses MSI-X for interrupts, a bisection turned up the following commit:
ad28e42bd1d28d746988ed71654e8aa670629753 is the first bad commit
commit ad28e42bd1d28d746988ed71
Thursday, June 25, 2015, 10:48:40 AM, you wrote:
On 24.06.15 at 21:38, wrote:
>> I'm having some trouble with a xhci controller passed through with
>> pci-passthrough to one of my HVM guests.
>> It uses MSI-X for interrupts, a bisection turned up the following commit:
>>
>> x86/MSI: t
Thursday, June 25, 2015, 1:29:39 PM, you wrote:
On 25.06.15 at 12:51, wrote:
>> Attached is the xl-dmesg output of:
>>
>> - debug-keys M and i before guest boot
>> - guest boot
>> - debug-keys M and i after lsusb in the guest that hangs.
> Interesting:
> (XEN) [2015-06-25 10:46:31.820]
Thursday, June 25, 2015, 2:40:18 PM, you wrote:
On 25.06.15 at 14:02, wrote:
>> Thursday, June 25, 2015, 1:29:39 PM, you wrote:
>>> I'd be curious what the guest view of the MSI-X table entries is at
>>> that point. Can you still use the console inside the guest? If so,
>>> sufficiently ver
Tuesday, July 7, 2015, 6:08:25 PM, you wrote:
On 26.06.15 at 17:48, wrote:
>> On 2015-06-26 17:22, Jan Beulich wrote:
>>> I have an idea: In
>>>
>>> static unsigned int startup_msi_irq(struct irq_desc *desc)
>>> {
>>> bool_t guest_masked = (desc->status & IRQ_GUEST) &&
>>>
Monday, July 6, 2015, 11:33:09 AM, you wrote:
On 26.06.15 at 17:57, wrote:
>> On 2015-06-26 17:51, Jan Beulich wrote:
>> On 26.06.15 at 17:41, wrote:
from 3.16 to 3.19 we gained a lot of these, if i remember correctly
related to
perf being enabled in the kernel:
>>
Wednesday, July 8, 2015, 10:58:02 AM, you wrote:
> On 08/07/2015 09:45, Sander Eikelenboom wrote:
>> Monday, July 6, 2015, 11:33:09 AM, you wrote:
>>
>>>>>> On 26.06.15 at 17:57, wrote:
>>>> On 2015-06-26 17:51, Jan Beulich wrote:
>>>>&g
Hi,
When running under Xen, ACPI powerbutton events don't work anymore,
there is no reaction when pressing the powerbutton.
On baremetal everything works fine, acpid gets the event and the
machine powers down perfectly. The machine is an Intel NUC.
Bisection has lead to:
b81975eade8c6495f3c4
nd i can report that it fixes my issue.
(i don't know if the xen-folks / Thomas have any comment on the way it is fixed.
But when this is final, it should probably be CC'd for -stable since it's broken
in both 3.17 and 3.18 afaik)
Thanks again,
--
Sander
> On 2014/12/19 21:16
Tuesday, December 23, 2014, 4:10:12 PM, you wrote:
> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
>> On Fri, Dec 19, 2014 at 03:19:44PM +, Andrew Cooper wrote:
>>>
>>> There will be another full nightly test happening tonight (based on c/s
>>> 7e88c23 "libxl: Tell qemu to use raw format
Monday, January 5, 2015, 9:08:32 PM, you wrote:
> Xen 4.5-rc4 was out on Monday (Dec 15th). The GA
> General Release is on Jan 7th^H^H^14th!
> There are some outstanding patches on which we need to figure
> out whether we will commit them in or not.
> When we commit a patch in, the OSSTest take
c 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
>> > > > Hi Konrad,
>> > > >
>> > > > This doesn't seem to be applied yet, nor does it seem to have a
>> > > > release-(N)ACK
>> > > > from you ?
>> > >
Tuesday, January 6, 2015, 6:17:12 PM, you wrote:
> Expand the README file to give a brief view of what went in
> Xen 4.5.0. Also change the Makefile to not use the '-rc'
> postfix.
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> README | 40 +++-
> xen/
Tuesday, January 6, 2015, 7:21:58 PM, you wrote:
> On Tue, Jan 06, 2015 at 06:06:23PM +, Ian Jackson wrote:
>> Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH] README, xen/Makefile:
>> Update to Xen 4.5.0"):
>> > -The 4.3 release offers a number of improvements, including NUMA
>> > -schedu
_to_irq() fails at the very beginning.
> Enhance xen_smp_prepare_cpus() to call setup_IO_APIC() to initialize
> irqdomain for IOAPICs.
> Signed-off-by: Jiang Liu
> Reported-and-tested-by: Sander Eikelenboom
> Cc: Konrad Rzeszutek Wilk
> ---
> Hi all,
> This
irq_for
> to check for 'STATE_RUN' bit being set and not schedule the
> dpci until that bit has been cleared.
> Reported-by: Sander Eikelenboom
> Reported-by: Malcolm Crossley
> Signed-off-by: Konrad Rzeszutek Wilk
Thanks again for the quick fix Konrad !
Tested it for
Monday, January 12, 2015, 5:49:44 PM, you wrote:
> Hey,
> Two folks (Malcom, Sander) have reported issues with the dpci softirq code and
> while I've an fix that fixes it, and this stage I am uncomfortable putting
> it in Xen 4.5. As such I am going to revert from Xen 4.5 tree
> (only) these pat
Monday, January 12, 2015, 6:29:01 PM, you wrote:
> Monday, January 12, 2015, 5:49:44 PM, you wrote:
>> Hey,
>> Two folks (Malcom, Sander) have reported issues with the dpci softirq code
>> and
>> while I've an fix that fixes it, and this stage I am uncomfortable putting
>> it in Xen 4.5. As s
Monday, January 12, 2015, 4:01:00 PM, you wrote:
> On 12/01/15 13:39, Jiang Liu wrote:
>> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
>> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
>> setup_IO_APIC(), so no irqdomains created for IOAPICs and
>>
Hi Gerry / David / Konrad,
Some more testing uncovered another issue under Xen, this time with
PCI-passthrough.
I have bisected it to the following commit:
cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 "x86, irq: Keep balance of IOAPIC pin
reference count"
It causes these symptoms:
- On Intel
-
Commit 2e5738ff "libxl: Add none to vga parameter" introduced the "none"
option for the Xen "vga=" config option but only appends the needed parameter
for the qemu-traditional case. This patch fixes the qemu-xen case by
appending the same "-vga none&quo
shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 1 needs to be cleaned up: destroying the domain
Done. Exiting now
Signed-off-by: Sander Eikelenboom
---
tools/libxl/libxl_dm.c |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_d
Friday, January 23, 2015, 10:06:04 AM, you wrote:
> Il 22/01/2015 18:21, Sander Eikelenboom ha scritto:
>> Commit 2e5738ff "libxl: Add none to vga parameter" introduced the "none"
>> option for the Xen "vga=" config option but only appends the need
Friday, January 23, 2015, 1:42:04 PM, you wrote:
> On Mon, 1 Dec 2014, Stefano Stabellini wrote:
>> xc_physdev_unmap_pirq might revoke the permission to map the irq from
>> the domain causing the following xc_domain_irq_permission call to fail
>> and return error (domain_pirq_to_irq returns 0).
>
Monday, January 26, 2015, 1:12:16 PM, you wrote:
> On Thu, 22 Jan 2015, Sander Eikelenboom wrote:
>> While this fixes the race and error on shutdown of a HVM guest with
>> pci-passthrough,
>> i don't know if this could give problems in other areas (migration ?),
&g
Thursday, February 5, 2015, 3:22:49 PM, you wrote:
> Hey David,
> after just being in that pain, I thought I might as well give a summary to
> you/the list. Maybe helpful to not forget which piece should go to which
> stable...
> So:
> v3.16...v3.17.8: Somewhen in between those, the acpi irq s
Monday, February 9, 2015, 9:35:33 AM, you wrote:
> Hello Steven,
> upgrades from Xen 4.4 to 4.5 are supposed to work out of the box.
> Please post more details and we'll try to help you figure out what's
> wrong.
> Cheers,
> Stefano
> On Sun, 8 Feb 2015, Steven Haigh wrote:
>> Hi all,
>>
>>
Monday, February 9, 2015, 10:31:15 AM, you wrote:
> On 05.02.2015 15:47, Sander Eikelenboom wrote:
>>
>> Thursday, February 5, 2015, 3:22:49 PM, you wrote:
>>
>>> Hey David,
>>
>>> after just being in that pain, I thought I might as well give a
Hi Jan / David / Konrad,
I was just testing a 3.19 kernel on my intel machine and again
ran into the sporadically appearing "irq nobody cared" on the dom0 kernel.
This occurs now for quite some kernel versions (running xen-unstable now,
but it also appeared in the past with builds that are now xen
Monday, February 9, 2015, 4:18:15 PM, you wrote:
> On 09/02/15 15:03, Sander Eikelenboom wrote:
>> Hi Jan / David / Konrad,
>>
>> I was just testing a 3.19 kernel on my intel machine and again
>> ran into the sporadically appearing "irq nobody cared" on th
Monday, February 9, 2015, 5:36:28 PM, you wrote:
>>>> On 09.02.15 at 16:18, wrote:
>> On 09/02/15 15:03, Sander Eikelenboom wrote:
>>> Hi Jan / David / Konrad,
>>>
>>> I was just testing a 3.19 kernel on my intel machine and again
>>> ran
Tuesday, February 10, 2015, 9:48:09 AM, you wrote:
On 09.02.15 at 18:13, wrote:
>> Yes the device that tries to handle the interrupt seems to change ..
>> however that device is always not actively used.
>> This time it was an unused IDE controller with driver loaded in dom0
>> and a mini-
Tuesday, February 10, 2015, 10:35:36 AM, you wrote:
On 10.02.15 at 10:19, wrote:
>>> Coming back to the /proc/interrupts output you posted earlier:
>>
>>> /proc/interrupts shows the high count:
>>
>>>CPU0 CPU1 CPU2 CPU3
>>> 8: 0 0
Tuesday, February 10, 2015, 11:36:48 AM, you wrote:
On 10.02.15 at 11:03, wrote:
>> Tuesday, February 10, 2015, 10:35:36 AM, you wrote:
>>> I suppose that's because there's no handler installed by pciback, yet
>>> IRQs generated by the passed through device also arrive in Dom0,
>>> and the
Tuesday, February 10, 2015, 10:35:36 AM, you wrote:
On 10.02.15 at 10:19, wrote:
>>> Coming back to the /proc/interrupts output you posted earlier:
>>
>>> /proc/interrupts shows the high count:
>>
>>>CPU0 CPU1 CPU2 CPU3
>>> 8: 0 0
Tuesday, February 10, 2015, 2:26:43 PM, you wrote:
On 10.02.15 at 14:07, wrote:
>> Tuesday, February 10, 2015, 10:35:36 AM, you wrote:
>> On 10.02.15 at 10:19, wrote:
> I would have thought that xen-pciback would install an interrupt
> handler here too when a device using IRQ 1
Tuesday, February 10, 2015, 5:22:16 PM, you wrote:
>>>> Sander Eikelenboom 02/10/15 5:01 PM >>>
>>Tuesday, February 10, 2015, 2:26:43 PM, you wrote:
>>>>> On 10.02.15 at 14:07, wrote:
>>> I don't really know how this code is supposed to
Tuesday, February 10, 2015, 6:47:46 PM, you wrote:
>>>> Sander Eikelenboom 02/10/15 6:30 PM >>>
>>Tuesday, February 10, 2015, 5:22:16 PM, you wrote:
>>>>>> Sander Eikelenboom 02/10/15 5:01 PM >>>
>>>>I haven't checked the
Hi,
With a 3.19 kernel + xen-devel tree pulled on top i run into this splat below.
It's on a Xen PV-guest running a postgres database and doing a pg_dump at that
moment in time, after running for a while (within 2 days or so).
--
Sander
[139595.736073] [ cut here ]
[13959
Thursday, February 12, 2015, 12:28:35 PM, you wrote:
> Hello,
> El 12/02/15 a les 9.54, Sander Eikelenboom ha escrit:
>> Hi,
>>
>> With a 3.19 kernel + xen-devel tree pulled on top i run into this splat
>> below.
>> It's on a Xen PV-guest running a
Thursday, February 19, 2015, 3:30:52 PM, you wrote:
> On Thu, 2015-02-19 at 13:59 +, Jan Beulich wrote:
>> All,
>>
>> in the context of someone seeing "The kernel doesn't support reset
>> from sysfs for PCI device", is my understanding correct that the lack
>> of error checking in any caller
Hi,
While shutting down all guests to go for a host reboot i encountered the splat
below.
This was running on Xen with:
xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
--
Sander
(XEN) [2015-02-23 09:16:26.292] Assertion 'cpu < nr_cpu_ids' failed at
.../src/new/xen-unstable/xen/
Monday, February 23, 2015, 11:06:25 AM, you wrote:
On 23.02.15 at 10:27, wrote:
>> While shutting down all guests to go for a host reboot i encountered the
>> splat below.
>> This was running on Xen with:
>> xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
> "-dirty" meanin
Monday, February 23, 2015, 12:06:00 PM, you wrote:
> I have no idea how I came to use __cpumask_set_cpu() there, the
> conversion should have been set_bit() -> __set_bit(). The wrong
> construct results in problems on systems with relatively few CPUs.
> Reported-by: Sander Eikele
Tuesday, February 24, 2015, 5:41:40 PM, you wrote:
> On Tue, 2015-02-03 at 14:01 +, Simon Rowe wrote:
>> The current Python interface to Xenstore is just a thin binding to the
>> C libxenstore library. This means that it is architecture-specific and
>> makes it awkward to use in platform-inde
Hi Konrad / Jan,
One of these commits:
- aeeea485bcfe2a517ed9bcb3ba1c3be0f6824e07 dpci: move from an hvm_irq_dpci (and
struct domain) to an hvm_dirq_dpci model
- f6dd295381f4b6a66acddacf46bca8940586c8d8 pci: replace tasklet with softirq
gives (running under 5 minutes of host boot, on AMD hardwar
Friday, November 14, 2014, 2:57:38 PM, you wrote:
On 14.11.14 at 14:11, wrote:
>> (XEN) [2014-11-14 13:00:06.810] [ Xen-4.5.0-rc x86_64 debug=y Not
>> tainted ]
>> (XEN) [2014-11-14 13:00:06.810] CPU:3
>> (XEN) [2014-11-14 13:00:06.810] RIP:e008:[]
>> dpci_softirq+0x9c/
Friday, November 14, 2014, 4:09:53 PM, you wrote:
On 14.11.14 at 15:34, wrote:
>> # addr2line -e ./xen-syms 82d080148f14
>> /usr/src/new/xen-unstable/xen/include/xen/list.h:175
>>
>> Which turns out to be this assert:
>> /**
>> * list_del - deletes entry from list.
>> * @entry: the e
Friday, November 14, 2014, 4:43:58 PM, you wrote:
On 14.11.14 at 16:20, wrote:
>> If it still helps i could try Andrews suggestion and try out with only
>> commit aeeea485 ..
> Yes, even if it's pretty certain it's the second of the commits, verifying
> this would be helpful (or if the as
Friday, November 14, 2014, 5:31:03 PM, you wrote:
> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the
> device before tearing it down"):
>> (Now with Reply-all, sorry)
> Likewise.
>> On 11/14/2014 11:01 AM, Ian Jackson wrote:
>> > What call to xc_physdev_unmap_pirq ?
Friday, November 14, 2014, 7:07:46 PM, you wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until
> QEMU removed the device before tearing it down"):
>> 1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.
> Yes, but I thin
Friday, November 14, 2014, 6:05:28 PM, you wrote:
> On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>>
>> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>>
>> >>>> On 14.11.14 at 16:20, wrote:
>> >> If it still helps i
Friday, November 14, 2014, 10:09:04 PM, you wrote:
> On 11/14/2014 02:24 PM, Sander Eikelenboom wrote:
>> Friday, November 14, 2014, 7:07:46 PM, you wrote:
>>
>>> Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Wait until
>>> QEMU rem
Friday, November 14, 2014, 10:38:11 PM, you wrote:
> On 11/14/2014 04:20 PM, Sander Eikelenboom wrote:
>> Friday, November 14, 2014, 10:09:04 PM, you wrote:
>>
>>
>>> I don't know about detach but I apparently can't even properly attach a
>>> se
Friday, November 14, 2014, 9:25:13 PM, you wrote:
> On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>>
>> Friday, November 14, 2014, 4:43:58 PM, you wrote:
>>
>> >>>> On 14.11.14 at 16:20, wrote:
>> >> If it still helps i
Monday, November 17, 2014, 5:34:16 PM, you wrote:
> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>>
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>>
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> &g
Monday, November 17, 2014, 5:34:16 PM, you wrote:
> On Fri, Nov 14, 2014 at 11:09:58PM +0100, Sander Eikelenboom wrote:
>>
>> Friday, November 14, 2014, 9:25:13 PM, you wrote:
>>
>> > On Fri, Nov 14, 2014 at 05:59:23PM +0100, Sander Eikelenboom wrote:
>> &g
Monday, November 17, 2014, 9:43:47 PM, you wrote:
> . snip..
>> > # cat /proc/interrupts |grep eth
>> > 36: 384183 0 xen-pirq-ioapic-level eth0
>> > 63: 1 0 xen-pirq-msi-x eth1
>> > 64: 24 661961 xen-pirq-msi-x eth1-rx-0
>> > 65:2
Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>
>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>>
>> > . snip..
>> >> > # cat /proc/interrupts |grep eth
>> >
Tuesday, November 18, 2014, 4:09:25 PM, you wrote:
> Tuesday, November 18, 2014, 12:07:41 PM, you wrote:
>> Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
>>> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>>>
>>>> Monday
Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
>> Without #define DIFF_LIST 1:
>> 1) The guest still crashes (xl-dmesg-not-defined.txt)
> AHA!
> --MARK--
> 0: 8305085ffd28 [p:83054ef27e88, n:83054ef27e88]
> 1: 8305085ffd28 [p:0200200200200200, n:0100100100100100]
> The
Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
> On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>>
>> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
>>
>> >>
>> >> Uhmm i thought i had these switched off (d
Wednesday, November 19, 2014, 4:04:59 PM, you wrote:
> On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>>
>> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>>
>> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>
Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
> Hey,
> This patch should fix the issue that Sander had seen. The full details
> are in the patch itself. Sander, if you could - please test origin/staging
> with this patch to make sure it does fix the issue.
> xen/drivers/passthrough/io.
Thursday, November 20, 2014, 8:51:33 PM, you wrote:
> Ah crud.
> So a simple fix could be to seperate the 'state' to only deal with the
> raise_softirq and softirq_dpci. And then add a new (old) 'masked' to
> deal between hvm_dirq_assist, pt_irq_guest_eoi and hvm_do_IRQ_dpci.
> From 94a98e20a8
Friday, November 21, 2014, 12:50:16 PM, you wrote:
> On November 21, 2014 2:51:33 AM EST, Jan Beulich wrote:
> On 20.11.14 at 20:51, wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>> ASSERT(d->arch.hvm_domain.irq.dpci);
Monday, November 24, 2014, 9:58:05 AM, you wrote:
On 21.11.14 at 17:45, wrote:
>> From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
>> From: Konrad Rzeszutek Wilk
>> Date: Thu, 20 Nov 2014 14:28:11 -0500
>> Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_as
Hi,
While testing a patch for Konrad i was wondering why "libxl_pci.c:
libxl__device_pci_reset()"
doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci
passthrough.
xl didn't show any problems on the commandline so i never drawed much attention
to it, but /var/log/xen/xl-guest
Thursday, November 27, 2014, 11:23:24 AM, you wrote:
> On Nov 24, 1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
>> Hello,
> Hi, hope the week is going well for everyone.
>> > >> As I was walking out the door I remembered I had been delinquent
>> > >> with information. The dom0 kernel i
bellini wrote:
>> > > > create ^
>> > > > title it QMP connection problems prevent libxl from calling
>> > > > libxl__device_pci_reset on domain shutdown
>> > > > thanks
>> > > >
>> > > > On Wed, 26 Nov 20
Monday, December 1, 2014, 2:42:11 PM, you wrote:
> On Mon, Dec 01, Olaf Hering wrote:
>> > # xl pci-attach domU :01:10.0
> "xl pci-attach -h" mentions [Virtual Slot], but the code does not seem
> to handle an additional parameter, pciattach() ignores *vs.
> What is the "Virtual Slot", why
Monday, December 1, 2014, 3:34:09 PM, you wrote:
> On Mon, Dec 01, Sander Eikelenboom wrote:
>> Hmm the wiki also still mentions it:
>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough
>>
>> It was the ability with xend + qemu-trad to be able to specify the slot to
Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>
>> On Dec 4, 2014 6:30 AM, David Vrabel wrote:
>>>
>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
Instead of doing all this complex dance, we depend on the toolstack
doi
Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>
>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>
>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>
>>>> On Dec 4, 2014 6:30
Hello Sander,
Thursday, December 4, 2014, 3:09:09 PM, you wrote:
> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>
>>>>
Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> On 04/12/14 14:09, Sander Eikelenboom wrote:
>>
>> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>>
>>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, December 4,
Thursday, December 4, 2014, 4:39:06 PM, you wrote:
> On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
>> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
>>
>> > On 04/12/14 14:09, Sander Eikelenboom wrote:
>> >>
>> >> T
Tuesday, December 9, 2014, 6:29:08 PM, you wrote:
On 09.12.14 at 17:24, wrote:
>> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not
>> doing
>> reset due to qmp race, switching order of xc_domain_irq_permission and
>> xc_physdev_unmap_pirq)
>> and with a kernel w
Tuesday, December 9, 2014, 7:05:32 PM, you wrote:
> Tuesday, December 9, 2014, 6:29:08 PM, you wrote:
> On 09.12.14 at 17:24, wrote:
>>> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not
>>> doing
>>> reset due to qmp race, switching order of xc_domain_irq_permis
Hi Konrad,
This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK
from you ?
--
Sander
Friday, November 28, 2014, 5:53:09 PM, you wrote:
> On do_pci_remove when QEMU returns error, we just bail out early without
> resetting the device. On domain shutdown we are racing
Thursday, December 18, 2014, 9:13:18 AM, you wrote:
>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>>> On Jul09 15:48, Sander Eikelenboom wrote:
>>> > Just wondering, why should this be done in the drivers ?
>>> > Couldn't this also be
Monday, February 23, 2015, 12:06:00 PM, you wrote:
> I have no idea how I came to use __cpumask_set_cpu() there, the
> conversion should have been set_bit() -> __set_bit(). The wrong
> construct results in problems on systems with relatively few CPUs.
> Reported-by: Sander Eikele
Hi Wei / Ian,
I'm getting this error on a "make clean" on a freshly
cloned xen-unstable staging tree. It's probably because the make script
can't handle a make clean on a tree which hasn't cloned the mini-os tree
at least once as part of a build.
make[2]: Entering directory `/usr/src/new/xen-un
Hi Ian,
My PV-guest configs were still using the old "root=" option,
but these guests don't boot anymore since:
commit 49ab17a3a615e1ab4ccc46d6942f925cf841df4b,
"tools: xl: handle unspecified extra= when dealing with root="
These pv guests don't boot anymore since the "root=" part isn't
prepended
Introduced in:
commit bd5920cb92e6799bfd64957284a9e2cfe7699039
"mini-os: sort objects in binary archives"
Signed-off-by: Sander Eikelenboom
---
Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 3e5d95e..2cb5e51 100644
--- a/Make
Thursday, March 12, 2015, 6:59:06 PM, you wrote:
> On Thu, 2015-03-12 at 18:48 +0100, Sander Eikelenboom wrote:
>> Hi Ian,
>>
>> My PV-guest configs were still using the old "root=" option,
>> but these guests don't boot anymore since:
>>
Tuesday, March 17, 2015, 9:18:32 AM, you wrote:
On 16.03.15 at 18:59, wrote:
>> Hence was wondering if it would just be easier to put
>> this patch in (see above) - with the benfit that folks have
>> an faster interrupt passthrough experience and then I work on another
>> variant of this wi
1 - 100 of 234 matches
Mail list logo
