From: Stefan Bader <stefan.bader@canonical.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Stefano@rly59j.srv.mailcontrol.com
Subject: Re: Re: Still struggling with HVM: tx timeouts on emulated nics
Date: Wed, 21 Sep 2011 17:34:40 +0200 [thread overview]
Message-ID: <4E7A0410.7050405@canonical.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1109211422180.8700@kaball-desktop>
On 21.09.2011 15:31, Stefano Stabellini wrote:
> On Wed, 21 Sep 2011, Stefan Bader wrote:
>> This is on 3.0.4 based dom0 and domU with 4.1.1 hypervisor. I tried using the
>> default 8139cp and ne2k_pci emulated nic. The 8139cp one at least comes up and
>> gets configured via dhcp. And initial pings also get routed and done correctly.
>> But slightly higher traffic (like checking for updates) hangs. And after a while
>> there are messages about tx timeouts.
>> The ne2k_pci type nic almost immediately has those issues and never comes up
>> correctly.
>>
>> I am attaching the dmesg of the guest with apic=debug enabled. I am not sure how
>> this should be but both nics get configured with level,low IRQs. Disk emulation
>> seems to be ok but that seem to use IO-APIC-edge. And any other IRQs seem to be
>> at least not level.
>
> Does the e1000 emulated card work correctly?
Yes, that one seems to work ok.
> What happens if you disable interrupt remapping (see patch below)?
8139cp seems to work correctly now (much higher irq stats as well) and e1000
still works. Both then using IOAPIC-fasteoi.
>
>
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 1017c7b..472a58b 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -354,8 +354,7 @@ int __init pci_xen_init(void)
>
> int __init pci_xen_hvm_init(void)
> {
> - if (!xen_feature(XENFEAT_hvm_pirqs))
> - return 0;
> + return 0;
>
> #ifdef CONFIG_ACPI
> /*
>
>
>> Btw, what exactly is the difference between xen-pirq-ioapic and IO-APIC?
>
> xen-pirq-ioapic interrupts are interrupts that have been remapped onto
> event channels
Ah ok, thanks.
>
>
>> Another problem came up recently though that may just be me doing the wrong
>> thing. Normally I boot with xen_emul_unplug=unnecessary as I want the emulated
>> devices. xen-blkfront is a module in my case and I thought I once had been able
>> to use that by removing the unplug arg and making the blkfront driver load. But
>> when I recently tried the module loaded but no disks appeared... Again, not sure
>> I just forgot how to do that right or that was different when using a 4.1.0
>> hypervisor still...
>
> xen_emul_unplug=unnecessary allows the kernel to use PV interfaces on
> older hypervisors that didn't support the unplug protocol and had other
> ways to cope with multiple drivers accessing the same devices.
> You can use xen_emul_unplug=never to prevent any unplug but you won't
> get any PV interfaces.
Hm, odd. Somehow I thought that I had been using pv interfaces that way when the
interrupts for the emulated ide was broken.
A bit suboptimal atm, because without any option and a kernel compiled with the
platform pci and pv drivers (as modules) booting in HVM mode the kernel decides
that having both is no use and unplugs the emulated devices. Which then leaves
you with ... none.
-Stefan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-09-21 15:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 13:03 Still struggling with HVM: tx timeouts on emulated nics Stefan Bader
2011-09-21 13:31 ` Stefano Stabellini
2011-09-21 15:34 ` Stefan Bader [this message]
2011-09-22 10:30 ` Stefano Stabellini
2011-09-22 11:58 ` Stefan Bader
2011-09-22 14:32 ` Stefan Bader
[not found] <4E7B4768.8060103@canonical.com>
2011-09-22 17:44 ` Stefano Stabellini
2011-09-30 9:13 ` Stefan Bader
2011-09-30 14:09 ` Stefano Stabellini
2011-09-30 16:06 ` Stefan Bader
2011-09-30 17:59 ` Stefan Bader
2011-10-03 17:24 ` Stefano Stabellini
2011-10-03 18:13 ` Stefano Stabellini
2011-10-04 10:07 ` Andrew Cooper
2011-10-04 14:13 ` Stefano Stabellini
2011-10-05 16:10 ` Stefan Bader
2011-10-06 10:12 ` Stefano Stabellini
2011-10-06 12:16 ` Stefan Bader
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=4E7A0410.7050405@canonical.com \
--to=stefan.bader@canonical.com \
--cc=Stefano@rly59j.srv.mailcontrol.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.