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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> Sent: 23 September 2014 16:03
> To: Paul Durrant
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: New windows pv drivers question
> 
> Il 22/09/2014 11:30, Fabio Fantoni ha scritto:
> > Il 19/09/2014 11:22, Paul Durrant ha scritto:
> >> Moving xen-devel to bcc and adding win-pv-devel...
> >>
> >>> -----Original Message-----
> >>> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> >>> Sent: 19 September 2014 09:55
> >>> To: xen-devel; Paul Durrant
> >>> Subject: New windows pv drivers question
> >>>
> >>> Hi, I saw the "new" pvdriver drivers in xen's git repository and the
> >>> new
> >>> wiki pages about.
> >>> I want start to try them if possible (for example to seems if occasion
> >>> windows domUs network crash  I had with xen 4.4-stable and xen-
> unstable
> >>> is ejbpv driver or xen problem), I saw that there are 3 repository in
> >>> xenserver's github still missed here but seems with a fast look that
> >>> all
> >>> essential drivers repositories are in xen's git now.
> >> Fabio,
> >>
> >> That's right. I have a blog to introduce the new Xen Project Windows
> >> PV Drivers sub-project ready to go but it's run into some technical
> >> difficulties; hopefully I'll get it out early next week.
> >> Not all the code that is relevant to XenServer is necessarily
> >> relevant to the wider Xen community; e.g. the guest agent and
> >> installer are very much XenServer-specific and therefore they do not
> >> form part of the sub-project. All the driver code is available on
> >> xenbits (under the pvdrivers/win directory) though and it has been
> >> stripped of XenServer branding. (The branding is now parameterized
> >> and applied at build time, so anyone can build their own branded
> >> binaries should they wish to).
> >>> Is possible start basic tests of them or there are still other
> >>> important
> >>> changes and/or fixes to do?
> >>> If is possible start test them there is a testing build available or or
> >>> should I do it?
> >>>
> >> I am setting up some build infrastructure as part of the sub-project
> >> - in fact I just got it going for the first time yesterday - and I
> >> hope to have un-branded binary packages available for the community
> >> in the very near future.
> >> In the meantime, there are build instructions available on the wiki
> >> at http://wiki.xenproject.org/wiki/Windows_PV_Drivers/Building which
> >> are fairly straightforward, so you should be able to build your own.
> >> Happily Microsoft made building drivers free again the with Windows
> >> 8.1 WDK as you can now use the Visual Studio 2013 Express (i.e. free)
> >> edition compiler. Note that you don't have to use the Visual Studio
> >> IDE; there are python scripts in the driver repositories which wrap
> >> the msbuild utility so you can drive it all from the command line :-)
> >>
> >> AFAIK the drivers should work in pretty much any host environment: I
> >> have been testing them myself on a recent build of xen-unstable using
> >> my own 3.14-ish dom0 kernel and upstream QEMU. Just make sure you
> >> enable test-signing in your VMs.
> >>
> >>> Thanks for any reply and sorry for my bad english.
> >> No problem. Please get back to me (cc-ing win-pv-devel) if you do run
> >> into difficulties.
> >>
> >> Cheers,
> >>
> >>      Paul
> >
> > Thanks for your reply.
> > Soon as I finish downloading everything needed I'll try to do a build.
> > I have other 2 questions:
> >
> > I saw that the xen's repositories are forked by xenserver's github
> > ones but the changes after are merged in both, will remain different
> > projects? One project compatible for all cases I think will be better
> > quality and less waste of time.
> >
> > About repositories missed now in xen there is win-xenguestagent that
> > contain some features very useful, in particolar shutdown (already
> > present in gplpv I use in production now) and resetting system time
> > following resume-from-suspend and migration (now missed in gplpv but
> > will solves login problem after restore in domUs that are in windows
> > domain). Will be adapted for xen also that?
> >
> > Thanks for any reply.
> 
> I installed in one windows 8.1 enterprise 64 bit domU (all updated) WDK
> 8.1, visual studio 2013.3 express, latest python 3.
> I tried to build xenbus following the README and launching build.py free.
> After some minutes of compile it fails with this error:
> > 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).
> > PrepareForBuild:
> >   Creazione directory "..\xen\Windows7Release\x64\".
> >   Creazione directory "..\Windows7Release\x64\".
> >   Creazione directory "..\xen\Windows7Release\x64\xen.tlog\".
> > InitializeBuildStatus:
> >   Creazione di
> > "..\xen\Windows7Release\x64\xen.tlog\unsuccessfulbuild". Ô stato
> > specificato "AlwaysCreate".
> > _MASM:
> >   Assembling ..\..\src\xen\amd64\hypercall_thunk.asm...
> >   cmd.exe /C
> > "C:\Users\Emilio\AppData\Local\Temp\tmp8eb6acdfb5f4436ea3385f199faf
> > ad19.cmd"
> >   ml64.exe /c /nologo /Zi
> > /Fo"..\xen\Windows7Release\x64\hypercall_thunk.obj" /W
> > 3 /errorReport:prompt  /Ta..\..\src\xen\amd64\hypercall_thunk.asm
> > _MASM:
> > 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 did something wrong or there is a bug or unexpected case?
> Thanks for any reply.

Not seen anything like that before. I can only assume it's to do with language 
support. It seems like msbuild is emitting characters that the shell is not 
handling correctly. I suspect you'll be ok if you use an English character set 
but I'll try to figure out what the script is/isn't doing.

  Paul


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