tests/libqos/rtas.c | 105 +++++++++++++++++++++++++ tests/libqos/rtas.h | 5 ++ tests/rtas-test.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 328 insertions(+)
This series implements a few RTAS hypercalls in tests/libqos that, used together, implement the DRC state transition described in PAPR 2.7+, 13.4. This started as an attempt of implementing hot unplug qtests for the sPAPR machine but I've found a few issues that will require more time solving: - CPU hot unplug: for some reason the machine freezes after the callback is returned. - LMB hot unplug: not supported by the sPAPR machine if not set in CAS. I have a feeling that the CPU hot unplug issue might be related with the lack of CAS negotiation step as well, but only way to be sure is to further understanding how the CAS negotation interfere with the device hot unplug. If needed we'll have to implement the client architecture support hypercall as well in the future. Until then, I believe these hypercalls have a value of their own and are worth being pushed upstream. Daniel Henrique Barboza (3): tests: adding 'check_exception' RTAS implementation tests: adding 'set_indicator' RTAS call tests: ibm,configure-connector RTAS call implementation tests/libqos/rtas.c | 105 +++++++++++++++++++++++++ tests/libqos/rtas.h | 5 ++ tests/rtas-test.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 328 insertions(+) -- 2.13.6
On Thu, Oct 26, 2017 at 06:22:47PM -0200, Daniel Henrique Barboza wrote: > This series implements a few RTAS hypercalls in tests/libqos > that, used together, implement the DRC state transition described > in PAPR 2.7+, 13.4. > > This started as an attempt of implementing hot unplug qtests for the > sPAPR machine but I've found a few issues that will require more time > solving: > > - CPU hot unplug: for some reason the machine freezes after the > callback is returned. > > - LMB hot unplug: not supported by the sPAPR machine if not > set in CAS. > > I have a feeling that the CPU hot unplug issue might be related > with the lack of CAS negotiation step as well, but only way to be > sure is to further understanding how the CAS negotation interfere > with the device hot unplug. If needed we'll have to implement the > client architecture support hypercall as well in the future. > > Until then, I believe these hypercalls have a value of their own and > are worth being pushed upstream. Unfortunately, these changes break the Travis build on MacOS. > > > Daniel Henrique Barboza (3): > tests: adding 'check_exception' RTAS implementation > tests: adding 'set_indicator' RTAS call > tests: ibm,configure-connector RTAS call implementation > > tests/libqos/rtas.c | 105 +++++++++++++++++++++++++ > tests/libqos/rtas.h | 5 ++ > tests/rtas-test.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 328 insertions(+) > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On 10/30/2017 06:12 PM, David Gibson wrote: > On Thu, Oct 26, 2017 at 06:22:47PM -0200, Daniel Henrique Barboza wrote: >> This series implements a few RTAS hypercalls in tests/libqos >> that, used together, implement the DRC state transition described >> in PAPR 2.7+, 13.4. >> >> This started as an attempt of implementing hot unplug qtests for the >> sPAPR machine but I've found a few issues that will require more time >> solving: >> >> - CPU hot unplug: for some reason the machine freezes after the >> callback is returned. >> >> - LMB hot unplug: not supported by the sPAPR machine if not >> set in CAS. >> >> I have a feeling that the CPU hot unplug issue might be related >> with the lack of CAS negotiation step as well, but only way to be >> sure is to further understanding how the CAS negotation interfere >> with the device hot unplug. If needed we'll have to implement the >> client architecture support hypercall as well in the future. >> >> Until then, I believe these hypercalls have a value of their own and >> are worth being pushed upstream. > Unfortunately, these changes break the Travis build on MacOS. Hmpf .... how can I run this Travis build to see the errors? I've searched here and found out something about making a Github pull request and then https://travis-ci.org/qemu/qemu runs the Travis build in the request. Is this a valid way of running it? Thanks, Daniel >> >> Daniel Henrique Barboza (3): >> tests: adding 'check_exception' RTAS implementation >> tests: adding 'set_indicator' RTAS call >> tests: ibm,configure-connector RTAS call implementation >> >> tests/libqos/rtas.c | 105 +++++++++++++++++++++++++ >> tests/libqos/rtas.h | 5 ++ >> tests/rtas-test.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 328 insertions(+) >>
On 10/30/2017 06:29 PM, Daniel Henrique Barboza wrote: > > > On 10/30/2017 06:12 PM, David Gibson wrote: >> On Thu, Oct 26, 2017 at 06:22:47PM -0200, Daniel Henrique Barboza wrote: >>> This series implements a few RTAS hypercalls in tests/libqos >>> that, used together, implement the DRC state transition described >>> in PAPR 2.7+, 13.4. >>> >>> This started as an attempt of implementing hot unplug qtests for the >>> sPAPR machine but I've found a few issues that will require more time >>> solving: >>> >>> - CPU hot unplug: for some reason the machine freezes after the >>> callback is returned. >>> >>> - LMB hot unplug: not supported by the sPAPR machine if not >>> set in CAS. >>> >>> I have a feeling that the CPU hot unplug issue might be related >>> with the lack of CAS negotiation step as well, but only way to be >>> sure is to further understanding how the CAS negotation interfere >>> with the device hot unplug. If needed we'll have to implement the >>> client architecture support hypercall as well in the future. >>> >>> Until then, I believe these hypercalls have a value of their own and >>> are worth being pushed upstream. >> Unfortunately, these changes break the Travis build on MacOS. > > Hmpf .... how can I run this Travis build to see the errors? I've > searched > here and found out something about making a Github pull request and > then https://travis-ci.org/qemu/qemu runs the Travis build in the > request. > Is this a valid way of running it? > Just managed to run the build and saw the error. I'll fix it in v2. Daniel > > Thanks, > > Daniel > >>> >>> Daniel Henrique Barboza (3): >>> tests: adding 'check_exception' RTAS implementation >>> tests: adding 'set_indicator' RTAS call >>> tests: ibm,configure-connector RTAS call implementation >>> >>> tests/libqos/rtas.c | 105 +++++++++++++++++++++++++ >>> tests/libqos/rtas.h | 5 ++ >>> tests/rtas-test.c | 218 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> 3 files changed, 328 insertions(+) >>> > >
© 2016 - 2025 Red Hat, Inc.