On 25/10/18 05:20PM, Sourabh Jain wrote:
>
> > <...snip...>
> > + switch (cmd) {
> > + case FADUMP_CMD_REGISTER:
> > + ret_val = do_fadump_register();
> > + if (ret_val != RTAS_OUT_SUCCESS) {
> > + rtas_st(rets, 0, ret_val);
> > + return;
> > + }
> > + break;
> > + case FADUMP_CMD_UNREGISTER:
> > + if (spapr->fadump_dump_active == 1) {
> > + rtas_st(rets, 0, RTAS_OUT_DUMP_ACTIVE);
> > + return;
> > + }
> > +
> > + spapr->fadump_registered = false;
> > + spapr->fadump_dump_active = false;
> > + memset(&spapr->registered_fdm, 0, sizeof(spapr->registered_fdm));
> > + break;
> > + case FADUMP_CMD_INVALIDATE:
> > + if (spapr->fadump_dump_active) {
> > + spapr->fadump_registered = false;
> > + spapr->fadump_dump_active = false;
> > + memset(&spapr->registered_fdm, 0,
> > sizeof(spapr->registered_fdm));
>
> I hope the above actions are good enough to make qemu ready for fadump
> registration.
I believe so. The various flags are set in do_fadump_register for
register command, maybe that's why that switch case might not look
enough, but I think the current one makes sense.
>
> > + } else {
> > + qemu_log_mask(LOG_GUEST_ERROR,
> > + "FADump: Nothing to invalidate, no dump active\n");
> > + }
>
> No error code if the kernel issues an invalidate and fadump_dump_active is
> false?
>
> As per the current kernel code, this situation should not occur, but to be
> on the safe side,
> QEMU should not return RTAS_OUT_SUCCESS.
Makes sense. PAPR doesn't say anything about this, but I guess we can
return PARAM_ERROR (for lack of any better error) in this case.
Will do.
Thanks,
- Aditya G
