Re: [win-pv-devel] New windows pv drivers question

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> Sent: 26 September 2014 10:40
> To: Paul Durrant
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: New windows pv drivers question
> 
> Il 25/09/2014 15:57, Paul Durrant ha scritto:
> >> -----Original Message-----
> > [snip]
> >>> Traceback (most recent call last):
> >>>    File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 365,
> >>> in <module
> >>>      build_sln(driver, release, 'x64', debug[sys.argv[1]], vs)
> >>>    File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 138,
> >>> in build_s
> >>> ln
> >>>      msbuild(platform, configuration, 'Build', name + '.sln', '', vs)
> >>>    File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 122,
> >>> in msbuild
> >>>
> >>>      status = shell([bin], dir)
> >>>    File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 100,
> >>> in shell
> >>>      print(line.rstrip())
> >>>    File "C:\Python34\lib\encodings\cp850.py", line 19, in encode
> >>>      return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> >>> UnicodeEncodeError: 'charmap' codec can't encode character '\u2026' in
> >>> position
> >>> 28: character maps to <undefined>
> > I believe I have figured this one out. I think it is the use of
> universal_newlines=True in the subprocess.Popen() call. Googling around, it
> appears  this is unsafe (for at least some versions of python) if the system
> default encoding is unicode. I think the problem can just be avoided by not
> setting universal_newlines, but I think the byte string coming back from
> Popen should also be decoded with the system default encoding before
> being displayed. I'll send a patch shortly.
> >
> >    Paul
> 
> I saw your new patch (Don't use universal_newlines=True in
> subprocess.Popen()), I tried the build on italian W8.1 the updated
> xenbus repository and this is the new error but always about encoding:
> > Compilazione di
> > "C:\Users\Emilio\Desktop\pvdrivers\xenbus\vs2013\xen\xen.vcxproj
> > " (2) dal progetto
> > "C:\Users\Emilio\Desktop\pvdrivers\xenbus\vs2013\xenbus.sln"
> > (1) sul nodo 1 (destinazioni predefinite).
> > InitializeBuildStatus:
> > Traceback (most recent call last):
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 360,
> > in <module
> > >
> >     build_sln(driver, release, 'x86', debug[sys.argv[1]], vs)
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 137,
> > in build_s
> > ln
> >     msbuild(platform, configuration, 'Build', name + '.sln', '', vs)
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 121,
> > in msbuild
> >
> >     status = shell([bin], dir)
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 99,
> > in shell
> >     print(line.decode(sys.getdefaultencoding()).rstrip())
> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd4 in position
> > 74: invalid
> >  continuation byte
> 
> I have also another questions:
> created debug build of drivers is very useful to take additional
> informations to solves the problem and I should always use it in testing
> environments?

I think that's sensible. Debug builds include trace debug prints, ASSERTs and 
turn off most function inlining, so analysing a stack trace is much easier.

> debug build decrease performance?

Yes. The lower level of optimization and the inclusion of ASSERTs and tracing 
are detrimental to performance.

> the debug build informations will be showed in qemu logs, in other logs
> and/or with particular tools/methods?

Use windbg for debugging. It's not too hard to set up. If the xenproject blog 
system ever comes back, I'll write an article about setting it up. If you just 
want to look at trace statements though, a debug build sends them to io port 
0xe9, which is echoed to Xen's console. So just set guest_loglvl to all and you 
should see them.

> I'll probably upload a pv driver build I did and I'll do for anyone want
> start to do fast tests with them before the official build will be
> ready, is ok?
> 

Yes. Feel free to do that if you wish. I do have infrastructure for doing 
public builds set up; I just have nowehere to host the build output as yet. I 
expect to have something soon.

  Paul

> Thanks for any reply and sorry for my bad english.

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel