>>> On 18.06.16 at 05:24, wrote:
> On Wed, Jun 15, 2016 at 9:14 AM, Jan Beulich wrote:
>> >>> On 15.06.16 at 12:45, wrote:
>> > In reply to -
>> > http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
>> >
>> > HI, I am working with Jurgen on the issue, as per Jan's request I tried
On Wed, Jun 15, 2016 at 9:14 AM, Jan Beulich wrote:
> >>> On 15.06.16 at 12:45, wrote:
> > In reply to -
> > http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
> >
> > HI, I am working with Jurgen on the issue, as per Jan's request I tried
> to
> > write explicitly only latency t
>>> On 15.06.16 at 12:45, wrote:
> In reply to -
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
>
> HI, I am working with Jurgen on the issue, as per Jan's request I tried to
> write explicitly only latency timer to be written -
> bool force_write = false;
> if ((dev_data->
In reply to -
http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
HI, I am working with Jurgen on the issue, as per Jan's request I tried to
write explicitly only latency timer to be written -
bool force_write = false;
if ((dev_data->permissive || xen_pcibk_permissive) &&
On 06/06/2016 10:21 AM, Jan Beulich wrote:
On 06.06.16 at 16:01, wrote:
>> On 06/06/2016 04:41 AM, Jan Beulich wrote:
- on the DomU - when I run that "test console" tool, the "lspci -xxx"
output is different from before/after
not much, though, only one register(?)
di
>>> On 06.06.16 at 16:01, wrote:
> On 06/06/2016 04:41 AM, Jan Beulich wrote:
>>
>>> - on the DomU - when I run that "test console" tool, the "lspci -xxx"
>>> output is different from before/after
>>> not much, though, only one register(?)
>>>
>>> diff lspci.before-testconsole lspci.after-testcon
On 06/06/2016 04:41 AM, Jan Beulich wrote:
>
>> - on the DomU - when I run that "test console" tool, the "lspci -xxx"
>> output is different from before/after
>> not much, though, only one register(?)
>>
>> diff lspci.before-testconsole lspci.after-testconsole
>> 2c2
>> < 00: cf 15 00 00 02 01 00
>>> On 06.06.16 at 11:09, wrote:
> [ 1466.964895 <0.23>] xen-pciback: :06:00.0: write request 4
> bytes at 0xc = 4000
> [ 1466.964897 <0.02>] xen-pciback: :06:00.0: read 1 bytes at
> 0xc
> [ 1466.964907 <0.10>] xen-pciback: :06:00.0: read 1 bytes at
> 0xc = 0
Hi Jan,
On 6 Jun 2016, at 10:41, Jan Beulich wrote:
On 04.06.16 at 17:15, wrote:
On 3 Jun 2016, at 15:26, Jan Beulich wrote:
I'll see to put together a patch for the recognizable problem,
but I'm still unclear about your actual one.
regarding the actual one: while it is still not working,
>>> On 04.06.16 at 17:15, wrote:
> On 3 Jun 2016, at 15:26, Jan Beulich wrote:
>> I'll see to put together a patch for the recognizable problem,
>> but I'm still unclear about your actual one.
>
> regarding the actual one: while it is still not working, I managed to
> dig deeper and found a few
>>> On 04.06.16 at 16:36, wrote:
> On 3 Jun 2016, at 16:20, Jan Beulich wrote:
>> Mind trying out the attached patch?
>
> Many thanks for your patch!! I did try it, and it is different now
> (details in files attached)
>
> "best of conf_space_header" see below.
>
> I cannot really make sense o
On 3 Jun 2016, at 15:26, Jan Beulich wrote:
I'll see to put together a patch for the recognizable problem,
but I'm still unclear about your actual one.
regarding the actual one: while it is still not working, I managed to
dig deeper and found a few observations
background: there is a drive
Hi Jan,
On 3 Jun 2016, at 16:20, Jan Beulich wrote:
On 03.06.16 at 15:26, wrote:
On 03.06.16 at 14:02, wrote:
or is this just some method the overwrite all registers with
"" first and then set the actual value?
[914572] xbk: 06:00.0: write request 4 bytes at 0x10 =
>>> On 03.06.16 at 15:26, wrote:
On 03.06.16 at 14:02, wrote:
>> or is this just some method the overwrite all registers with
>> "" first and then set the actual value?
>>
>>[914572] xbk: 06:00.0: write request 4 bytes at 0x10 =
>>[914574] xbk: 06:00.0: read 4
>>> On 03.06.16 at 14:02, wrote:
> One observation that struck me:
> - if the write request is a word (as opposed to a double word), the
> write always seems to succeed!
>
> [139971.914490] xen-pciback: :06:00.0: write request 2 bytes at 0x4
> = 100 < input value
> [
On 3 Jun 2016, at 13:52, Jan Beulich wrote:
On 02.06.16 at 21:59, wrote:
Temporary Fix
-
After checking the source[1] of the PCI configuration space
handling in xen-pciback, I found out that changing line 258
to read
if (handled && !err) {
instead of:
if (!handled &&
>>> On 02.06.16 at 21:59, wrote:
> Temporary Fix
> -
>
> After checking the source[1] of the PCI configuration space
> handling in xen-pciback, I found out that changing line 258
> to read
>
> if (handled && !err) {
>
> instead of:
>
> if (!handled && !err) {
>
> solves th
Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
=
Background
--
I am trying to passthrough an Industrial Ethernet Interface
(Hilscher GmbH CIFX 50E-DP(M/S)) on a HVM DomU running the
Xen 4.6 Hypervisor. The card is being pass-trou
On 02.06.16 at 21:59 Sylwester Sosnowski wrote:
> Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
> =
>
> Background
> --
>
> I am trying to passthrough an Industrial Ethernet Interface
> (Hilscher GmbH CIFX 50E-DP(M/S)) on a HVM Dom
On 02.06.16 um 22:06 Konrad Rzeszutek Wilk wrote:
>> did you try the permissive module parameter?
Yes, I have been using the permissive mode when
I was getting these results.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
On Thu, Jun 02, 2016 at 09:59:29PM +0200, Sylwester Sosnowski wrote:
>
> Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
> =
>
> Background
> --
>
> I am trying to passthrough an Industrial Ethernet Interface
> (Hilscher GmbH CIFX
Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
=
Background
--
I am trying to passthrough an Industrial Ethernet Interface
(Hilscher GmbH CIFX 50E-DP(M/S)) on a HVM DomU running the
Xen 4.6 Hypervisor. The card is being pass-trou
22 matches
Mail list logo
