search for: rflag

...ml | 4 ++++ generator/Python.ml | 2 ++ 6 files changed, 42 insertions(+), 15 deletions(-) diff --git a/generator/API.ml b/generator/API.ml index 962b787..bf6030f 100644 --- a/generator/API.ml +++ b/generator/API.ml @@ -66,6 +66,8 @@ and ret = | RCookie | RString | RUInt +| REnum of enum +| RFlags of flags and closure = { cbname : string; cbargs : cbarg list; @@ -442,7 +444,7 @@ test whether this is the case with L<nbd_supports_tls(3)>."; "get_tls", { default_call with - args = []; ret = RInt; + args = []; ret = REnum (tls_enum); may_set_error...

...= > | RString (** return a newly allocated string, > caller frees, NULL for error *) > | RUInt (** return a bitmask, no error possible *) > +| REnum of enum (** return an enum, no error possible *) > +| RFlags of flags (** return bitmask of flags, no error possible *) > and closure = { > cbname : string; (** name of callback function *) > cbargs : cbarg list; (** all closures return int for now *) > diff --git a/generator/C.ml b/generator/C.ml > index 6b65f6e.....

...ml code, I'm not sure what we should do if a newer libnbd ever returns a bit that an older NBD.mli was not expecting at the time the OCaml compiler ran (see below). I'm also not sure if there is a more efficient way to avoid outputting Val_FOO() converters for types not referenced in REnum/RFlags than my hack of __attribute__((unused)). Hence I'll wait for a review on these. Now, for the future compatibility lesson, promised above. nbd_get_handshake_flags is documented as potentially returning additional bits from a newer libnbd than what the current client code was compiled against....

...0 100644 --- a/generator/OCaml.ml +++ b/generator/OCaml.ml @@ -66,8 +66,8 @@ and ocaml_ret_to_string = function | RCookie -> "cookie" | RString -> "string" | RUInt -> "int" - | REnum _ -> "int" (* XXX return enum_prefix.t instead *) - | RFlags _ -> "int" (* XXX return flag_prefix.t list instead *) + | REnum { enum_prefix } -> enum_prefix ^ ".t" + | RFlags { flag_prefix } -> flag_prefix ^ ".t list" and ocaml_optarg_to_string = function | OClosure { cbname; cbargs } -> @@ -344,7 +344,34 @@...

...code_of_ret = > >> function > >> | RBool | RErr | RFd | RInt | RInt64 | RCookie -> Some "-1" > >> | RStaticString | RString -> Some "NULL" > >>- | RUInt -> None (* errors not possible *) > >>+ | RUInt | REnum (_) | RFlags (_) -> None (* errors not possible *) > >> > >> let type_of_ret = > >> function > >>- | RBool | RErr | RFd | RInt -> "int" > >>+ | RBool | RErr | RFd | RInt | REnum (_) -> "int" > > > >This is good because...

...l index 732b81f..aecd2d5 100644 --- a/generator/GoLang.ml +++ b/generator/GoLang.ml @@ -99,8 +99,8 @@ let go_ret_type = function * always nil unless h is closed *) | RUInt -> Some "uint" - | REnum (_) -> Some "uint" (* XXX return typed constant instead? *) - | RFlags (_) -> Some "uint" (* XXX return typed constant instead? *) + | REnum ({ enum_prefix}) -> Some (camel_case enum_prefix) + | RFlags ({ flag_prefix}) -> Some (camel_case flag_prefix) let go_ret_error = function | RErr -> None @@ -393,10 +393,10 @@ let print_binding (name...

...100644 --- a/generator/OCaml.ml +++ b/generator/OCaml.ml @@ -66,8 +66,8 @@ and ocaml_ret_to_string = function | RCookie -> "cookie" | RString -> "string" | RUInt -> "int" - | REnum (_) -> "int" (* XXX return enum_prefix.t instead *) - | RFlags (_) -> "int" (* XXX return flag_prefix.t list instead *) + | REnum ({ enum_prefix }) -> enum_prefix ^ ".t" + | RFlags ({ flag_prefix }) -> flag_prefix ^ ".t list" and ocaml_optarg_to_string = function | OClosure { cbname; cbargs } -> @@ -332,10 +332...

...15 +66,15 @@ let errcode_of_ret = >> function >> | RBool | RErr | RFd | RInt | RInt64 | RCookie -> Some "-1" >> | RStaticString | RString -> Some "NULL" >> - | RUInt -> None (* errors not possible *) >> + | RUInt | REnum (_) | RFlags (_) -> None (* errors not possible *) >> >> let type_of_ret = >> function >> - | RBool | RErr | RFd | RInt -> "int" >> + | RBool | RErr | RFd | RInt | REnum (_) -> "int" > > This is good because Enum is passed as int. >...

...andler. None of the bits in the event channel pending arrays are set. If I return via the iret call, the hypervisor immediately calls back into the handler. The user RIP never changes, so it is clearly not making forward progress. The stackframe should be correctly setup with the flags, rip, cs, rflags, rsp, and ss values and the currently installed LDT has slots for the code and data segments that the user will use. Am I not jumping into user space correctly? Is there something else that my code should do to make the transition? On a documentation question, is __HYPERVISOR_iret documented an...

...p/sftp-client.c --- openssh-3.7.1p2/sftp-client.c 2003-07-02 22:46:57.000000000 -0500 +++ openssh-3.7.1p2_sftp/sftp-client.c 2003-10-16 10:09:51.000000000 -0500 @@ -735,8 +735,13 @@ } int +#ifdef REGET +do_download(struct sftp_conn *conn, char *remote_path, char *local_path, + int pflag, int rflag) +#else do_download(struct sftp_conn *conn, char *remote_path, char *local_path, int pflag) +#endif { Attrib junk, *a; Buffer msg; @@ -798,8 +803,17 @@ return(-1); } - local_fd = open(local_path, O_WRONLY | O_CREAT | O_TRUNC, - mode | S_IWRITE); +#ifdef REGET + if (rflag) +...

Hi all, Does anyone have thoughts on extending v->arch.hvm_vcpu.single_step to support pre-MTF systems, in a way that would mimic the MTF? So far I''m emulating PUSHF/POPF to hide the hypervisor''s trap flag, and eventually I''ll multiplex it down to the guest, but I''m having issues. Right now, I''m enabling X86_EFLAGS_TF in vmx_intr_assist, just like

FYI, looks like support for Racoon is ending. Does anyone have any experience with the version in ipsec-tools ? ---Mike >Racoon users, > >This is the announcement that the kame project will quit providing >a key management daemon, the racoon, and that "ipsec-tools" will become >the formal team to release the racoon. >The final release of the racoon in the

...ed, all that was left was the OCaml changes. I'm a lot happier with how things turned out with an UNKNOWN constructor in the OCaml variants. Eric Blake (3): tests: Enhance coverage of enum/flag range checking ocaml: Support unknown values for Enum/Flags ocaml: Typesafe returns for REnum/RFlags generator/OCaml.ml | 123 +++++++++++++++--- python/t/120-set-non-defaults.py | 12 ++ ocaml/tests/test_110_defaults.ml | 5 +- ocaml/tests/test_120_set_non_defaults.ml | 19 ++- tests/errors.c | 32 +++...

...2ffae0 CPU: 0 COMMAND: "swapper" #0 [ffffffff8043ef20] crash_nmi_callback at ffffffff8007a3bf #1 [ffffffff8043ef40] do_nmi at ffffffff8006585a #2 [ffffffff8043ef50] nmi at ffffffff80064ebf [exception RIP: acpi_processor_idle+579] RIP: ffffffff8019765e RSP: ffffffff803f1f48 RFLAGS: 00000093 RAX: 000000000073111a RBX: 000000000073111a RCX: 0000000000000808 RDX: 0000000000000815 RSI: 0000000000000003 RDI: 0000000000000000 RBP: ffff81063e480100 R8: ffffffff803f0000 R9: ffffffff804b5e2c R10: 0000000000000046 R11: 0000000000000046 R12: 0000000000000000...

On Wed, Jan 13, 2016 at 06:25:21PM +0200, Michael S. Tsirkin wrote: > Which flag do you refer to, exactly? All the flags in rFLAGS which ADD modifies: OF,SF,ZF,AF,PF,CF -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

...48PM +0200, Michael S. Tsirkin wrote: > Oh, I think this means we need a "cc" clobber. Btw, does your microbenchmark do it too? Because, the "cc" clobber should cause additional handling of flags, depending on the context. It won't matter if the context doesn't need rFLAGS handling in the benchmark but if we start using LOCK; ADD in the kernel, I can imagine some places where mb() is used and rFLAGS are live, causing gcc to either reorder code or stash them away... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

On Wed, Jan 13, 2016 at 06:25:21PM +0200, Michael S. Tsirkin wrote: > Which flag do you refer to, exactly? All the flags in rFLAGS which ADD modifies: OF,SF,ZF,AF,PF,CF -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

...48PM +0200, Michael S. Tsirkin wrote: > Oh, I think this means we need a "cc" clobber. Btw, does your microbenchmark do it too? Because, the "cc" clobber should cause additional handling of flags, depending on the context. It won't matter if the context doesn't need rFLAGS handling in the benchmark but if we start using LOCK; ADD in the kernel, I can imagine some places where mb() is used and rFLAGS are live, causing gcc to either reorder code or stash them away... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

Patch 2/2 - Add flag to indicate that an exception event needs injecting, and to delay the ext interrupt injection. Remove unnecessary check of RFLAGS.IF for ExtInt injection. Applies cleanly to xen-unstable c/s 11831. Please apply to xen-unstable.hg. We would also want this patch to be in a 3.0.3-1 base whenever that is branched. Signed-off-by: Travis Betak <travis.betak@amd.com> Signed-off-by: Wei Huang <wei.huang2@amd.com> Sign...

...ffffff83437000 (XEN) TOTAL: ffffffff80000000->ffffffff83800000 (XEN) ENTRY ADDRESS: ffffffff81506200 (XEN) Dom0 has maximum 24 VCPUs (XEN) '0' pressed -> dumping Dom0's registers (XEN) *** Dumping Dom0 vcpu#0 state: *** (XEN) RIP: 0000:[<0000000000000000>] (XEN) RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) r9: 0000000000000...