Re: [win-pv-devel] [PATCH 2/2] Added a function called from DriverEntry where...

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Owen Smith
> Sent: 28 June 2017 16:48
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; win-pv-
> devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Eric Mackay <mackayem@xxxxxxxxxx>; Paul Durrant
> <Paul.Durrant@xxxxxxxxxx>
> Subject: RE: [win-pv-devel] [PATCH 2/2] Added a function called from
> DriverEntry where...
> 
> 
> > -----Original Message-----
> > From: win-pv-devel [mailto:win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx]
> On
> > Behalf Of Paul Durrant
> > Sent: 28 June 2017 16:39
> > To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> > Cc: Eric Mackay <mackayem@xxxxxxxxxx>; Paul Durrant
> > <Paul.Durrant@xxxxxxxxxx>
> > Subject: [win-pv-devel] [PATCH 2/2] Added a function called from
> > DriverEntry where...
> >
> > From: Eric Mackay <mackayem@xxxxxxxxxx>
> >
> > we can safely read registry keys and convert strings at PASSIVE_LEVEL
> >
> > The MSDN documentation for various registry key access and string
> > conversion functions requires the caller to be at PASSIVE_LEVEL.
> > One of the reasons for this is that the string conversion tables used by
> > functions such as RtlAnsiStringToUnicodeString are stored in paged pool
> > memory. Both the page fault handler and the process scheduler run at
> > DISPATCH_LEVEL, therefore you must not touch memory at
> DISPATCH_LEVEL
> > that could be paged out. A process running at DISPATCH_LEVEL cannot be
> > preempted for the page fault handler to run.
> >
> > To aid Static Driver Verifier code analysis and inform developers, I have
> > added SAL annotations that indicate PASSIVE_LEVEL is required on certain
> > registry access functions.
> >
> > Signed-off-by: Eric Mackay <mackayem@xxxxxxxxxx>
> >
> > Re-based onto master and adjusted for style. Note this involved fixing
> > whitespace issues in frontend.c.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > ---
> >  src/xenvbd/driver.c   |  96 ++++++++++++++++--
> >  src/xenvbd/driver.h   |  31 ++++++
> >  src/xenvbd/frontend.c | 269 ++++++++++++++++++++++++++++++++----
> --
> > ------------
> >  src/xenvbd/registry.c |  26 +++++
> >  src/xenvbd/registry.h |  25 ++++-
> >  5 files changed, 342 insertions(+), 105 deletions(-)
> >
> > diff --git a/src/xenvbd/driver.c b/src/xenvbd/driver.c index
> 62c3cbb..f8d5e82
> > 100644
> > --- a/src/xenvbd/driver.c
> > +++ b/src/xenvbd/driver.c
> > @@ -47,12 +47,21 @@
> >  #include "debug.h"
> >  #include "assert.h"
> >
> > +// Feature Overrides From Registry Values typedef struct
> > +_XENVBD_FEATURE_OVERRIDE {
> > +    PCHAR                       Name;
> > +    ULONG                       Value;
> > +    BOOLEAN                     Present;
> > +} XENVBD_FEATURE_OVERRIDE, *PXENVBD_FEATURE_OVERRIDE;
> > +
> >  typedef struct _XENVBD_DRIVER {
> > -    PXENVBD_ADAPTER     Adapter;
> > -    HANDLE              ParametersKey;
> > -    PDRIVER_DISPATCH    StorPortDispatchPnp;
> > -    PDRIVER_DISPATCH    StorPortDispatchPower;
> > -    PDRIVER_UNLOAD      StorPortDriverUnload;
> > +    PXENVBD_ADAPTER             Adapter;
> > +    HANDLE                      ParametersKey;
> > +    PDRIVER_DISPATCH            StorPortDispatchPnp;
> > +    PDRIVER_DISPATCH            StorPortDispatchPower;
> > +    PDRIVER_UNLOAD              StorPortDriverUnload;
> > +    const CHAR                  *FeatureName[NumberOfFeatures];
> 
> FeatureName here is not initialised or used. Struct entry can be removed.
> 

Indeed it is not. I'll get rid of it in v2.

Cheers,

  Paul

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