xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Json config and stubdomain
@ 2016-09-24 10:42 Marek Marczykowski-Górecki
  2016-09-26 11:01 ` Wei Liu
  0 siblings, 1 reply; 3+ messages in thread
From: Marek Marczykowski-Górecki @ 2016-09-24 10:42 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]

Hi,

Debugging stubdomain continuation...
When stubdomain is started, it has no json config created. This results
in multiple problems:
 - impossible to dynamically attach additional devices
 - starting a domain with more than one PCI device fails

The second one is especially interesting because it look so much
inconsistent: libxl__device_pci_add_xenstore when called for the first
device, it immediately calls libxl__create_pci_backend and do not touch
json config at all. But when called for the next device, it loads json
config, adds the device there and save it. So it looks like the first
PCI device will never be saved into json config (when added
dynamically).
In case of stubdomain, libxl__device_pci_add_xenstore is called during
stubdomain startup, so defining two or more PCI devices means domain
startup fail.

So, the question is, whether json config should be created and properly
maintained for stubdomain, or not created at all (assuming all the
configuration is already handled in the target domain json config)?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Json config and stubdomain
  2016-09-24 10:42 Json config and stubdomain Marek Marczykowski-Górecki
@ 2016-09-26 11:01 ` Wei Liu
  2016-09-26 11:40   ` Marek Marczykowski-Górecki
  0 siblings, 1 reply; 3+ messages in thread
From: Wei Liu @ 2016-09-26 11:01 UTC (permalink / raw)
  To: Marek Marczykowski-Górecki; +Cc: Wei Liu, xen-devel

On Sat, Sep 24, 2016 at 12:42:45PM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> Debugging stubdomain continuation...
> When stubdomain is started, it has no json config created. This results
> in multiple problems:
>  - impossible to dynamically attach additional devices
>  - starting a domain with more than one PCI device fails
> 
> The second one is especially interesting because it look so much
> inconsistent: libxl__device_pci_add_xenstore when called for the first
> device, it immediately calls libxl__create_pci_backend and do not touch
> json config at all. But when called for the next device, it loads json
> config, adds the device there and save it. So it looks like the first
> PCI device will never be saved into json config (when added
> dynamically).
> In case of stubdomain, libxl__device_pci_add_xenstore is called during
> stubdomain startup, so defining two or more PCI devices means domain
> startup fail.

Please see  libxl_internal.h, around line 2564. The same logic is used
across all devices.

I think there could be bugs in pci device handling code. I didn't get to
test that because my test box was not capable and the code for pci
device was (and still is) rather irregular compared to other devices.

> 
> So, the question is, whether json config should be created and properly
> maintained for stubdomain, or not created at all (assuming all the
> configuration is already handled in the target domain json config)?

Stubdom configuration should be derived. It is considered internal
details.

Wei.

> 
> -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Json config and stubdomain
  2016-09-26 11:01 ` Wei Liu
@ 2016-09-26 11:40   ` Marek Marczykowski-Górecki
  0 siblings, 0 replies; 3+ messages in thread
From: Marek Marczykowski-Górecki @ 2016-09-26 11:40 UTC (permalink / raw)
  To: Wei Liu; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 676 bytes --]

On Mon, Sep 26, 2016 at 12:01:01PM +0100, Wei Liu wrote:
> On Sat, Sep 24, 2016 at 12:42:45PM +0200, Marek Marczykowski-Górecki wrote:
> > So, the question is, whether json config should be created and properly
> > maintained for stubdomain, or not created at all (assuming all the
> > configuration is already handled in the target domain json config)?
> 
> Stubdom configuration should be derived. It is considered internal
> details.

Ok, I'll adjust PCI handling accordingly.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-09-26 11:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-24 10:42 Json config and stubdomain Marek Marczykowski-Górecki
2016-09-26 11:01 ` Wei Liu
2016-09-26 11:40   ` Marek Marczykowski-Górecki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).